[deeFive]

I see and I do understand but I don’t think that approach will work (I don’t believe that 1:1 texel ratios will be something that games use for a long, long time), I think that artist guided procedurals will be the way to go, so an artist would paint on to a model how dirt would build up on the object rather than painting dirt straight on to the model. I don’t think this is a new approach, I’m sure that uncharted uses a similar technique.

Also Its begining to slow here so im going to take some time to answer richard!

[Davros]

Originally Posted by deeFive

so an artist would paint on to a model how dirt would build up on the object rather than painting dirt straight on to the model.

I dont understand the above

[deeFive]

hmm, my bad i'll try again (was rushing inbetween cases and calls):

so classicly you would have a dirt texture (or textures) with would be painted by an artist then applied over the colour map/texture. what i am suggesting is a greyscale (or single channel, that said you could use more than one) texture which would describe how dirt settles on to an object.

does that make more sense?

[Laa-Yosh]

No games are using tech like that. 99% of current games are not using any procedural textures apart from maybe water surfaces (which need to be dynamic). Maybe BF3 and Trials 2 are using some level of proceduralism for the terrain but even that is based on bitmaps. This use of multiple layered textures is not uncommon, though, but these are based on bitmaps at nearly every layer.

[deeFive]

Sorry richard its been a long, busy day at work (i'm still here!!!)

it would be a new dx11.1 class engine (sorry I should of made that clear, also a full engine is so much more than this.). I think I would try to get this to work at 120fps @720p (I think that this will be the new standard for showing off( I’ll convert this(the120fps part) to nanoseconds later.).).

As for having multiple MTs, one MT is 16kx16kx8kx32bits is 2gb in paged memory and I’m not so confident that the next round of consoles will have more than this, so this one MT will need to hold all of the data for (in this example) one game environment (this may also need to include the other RT’s from other parts of the pipeline, i also need to define what a game environment is!).

As for having separate channels for colour and light, it should allow for more vivid experience with the colour of an object being separate to the light colour, which in-turn should help with the post-processing part of the pipeline.

I think your right about normal storage, normal mapping would be a fallback path with tessellation being the first choice (supported by another channel for a decal base damage system). I need to draft the layout of the MT and see how things will fit memory wise.

Also laa-Yosh i think your view of proceduralism is a little different to mine, i would want to be using a shader+bitmap system thats simular to current water systems.

[Laa-Yosh]

My views are generally shared by all texture artists, as that's where I've got them from.
Also, even regular texture mapping is secondary in animation and VFX to matte paintings. Again, it's always easier to paint something directly, instead of trying to manipulate abstract mathematical elements, and the easier a tool is to use, the better the artist can express his/her vision.

Engines shouldn't be designed from purely the tech side. It's the artists who fill the game world with content and thus their requirements should be given very high priority.

[Richard]

Originally Posted by Laa-Yosh

No games are using tech like that. 99% of current games are not using any procedural textures apart from maybe water surfaces (which need to be dynamic). Maybe BF3 and Trials 2 are using some level of proceduralism for the terrain but even that is based on bitmaps. This use of multiple layered textures is not uncommon, though, but these are based on bitmaps at nearly every layer.

BF3 does use procedural generation of terrain layers (with masks of course) + their virtual texturing solution. ETQW's terrain editor let you procedurally distribute terrain textures very closely to what dF is talking about. Then you go in and manually stamp decals and finally bake the MT.

It's definitely doable, procedural does not have to equate to equations (heh) which can be abstracted away in the front-end editor artists use. Same thing with Photoshop filters which have maths equations underneath the GUI controls.

One thing procedural geneartion has on manual data changes is that you have automatic forwards compatibility. In ETQW, aside from a few tests, I didn't touch the manual stamping because if I changed the terrain later which I had to do (from closing a poly-gap to simply raising a vertice a few game units for gameplay reasons) I would need to redo all the manual placing from scratch. It's like changing the mesh after you UV mapped the thing, except you don't live with some stretching, you lose all your work. Procedural (re) generation is a button press away. Sure you may need to tweak it again but your water basins and your snow clearances will simply work on the new geometry. I don't think I ever needed to correct the procedural generation after I changed the terrain mesh.

I get the appeal, but you need extra work to allow an artist to simply paint over the affected part* leaving the rest of the MT intact. OTOH, it's easier to get away from the repeated artificial look (just have your cat walk over your watcom!).

EDIT: * WHILST THE CHANGES REMAIN EDITABLE, obviously.

[Laa-Yosh]

It's not what - at least in the 3D content creation community - is referred to as procedural texturing. It's a higher level tool utilizing bitmap textures; it is procedural, sure, but not a procedural texture.

[Rodéric]

procedural texture splatting.

[Acert93]

Originally Posted by Laa-Yosh

Engines shouldn't be designed from purely the tech side. It's the artists who fill the game world with content and thus their requirements should be given very high priority.

You should write an article on such. It would be interesting to know what approaches allow for the most content generation within a window of time and those that limit content generation, and also how the type of game impacts content generation. We do not hear enough from artists.

[jlippo]

Originally Posted by deeFive

As for having multiple MTs, one MT is 16kx16kx8kx32bits is 2gb in paged memory and I’m not so confident that the next round of consoles will have more than this, so this one MT will need to hold all of the data for (in this example) one game environment (this may also need to include the other RT’s from other parts of the pipeline, i also need to define what a game environment is!).

16k*16k*8k*4bytes is ~8TB
I'm not sure why you would use 3D texture with megatexturing, unless you are using it for irradiance volumes.

As for using multiple MTs there were interesting post and paper which talk about the possibility-
http://sandervanrossen.blogspot.com/...#disqus_thread
http://www.cg.tuwien.ac.at/research/...Mayer-2010-VT/

Originally Posted by deeFive

As for having separate channels for colour and light, it should allow for more vivid experience with the colour of an object being separate to the light colour, which in-turn should help with the post-processing part of the pipeline.

You might want to consider fully dynamic lighting as you wouldn't be constrained with unique texturing if you do that, nor very long texture baking times.

One could use MT for nice lighting/shadow cache to get frame independent lighting. (bake information into different channels during 'textureload' change when needed.)
IE. Directional occlusion, indirect light, shadow masks etc. (I also do not see why these should be in full resolution, especially if they have directional information to mix with normal maps.)

Originally Posted by deeFive

I think your right about normal storage, normal mapping would be a fallback path with tessellation being the first choice (supported by another channel for a decal base damage system). I need to draft the layout of the MT and see how things will fit memory wise.

For displacement I would suggest testing vector displacement mapping for various reasons. (sharp edges and ability to curve on itself.)

[deeFive]

So..

I have had a quick look at amd and other doc's (thanks jlippo) and i think going to have to repick up OGL (i cant find any d3d details) so that might delay any progress but i'll try to keep updating this thread with info.

that said, to be honest im still pinning down design details (art & sound direction and stuff). so this may take a little while.

[Davros]

Originally Posted by deeFive

one MT is 16kx16kx8kx32bits

So you texture is going to be 8192 pixels deep or have 8192 layers ?

[deeFive]

Sorry for the quick responce (its busy again), the MT will contain various volume textures (i think)

on a side note dose anyone have a link to a good pitch document (one that got funding)?

[Davros]

design not pitch but a good article
http://www.gamasutra.com/view/featur..._document_.php
and could be adapted into a pitch
eg:

A game concept should include the following features:
Introduction
Background (optional)
Description
Key features
Genre
Platform(s)
Concept art (optional)

ps:
http://makeitbigingames.com/2007/09/...tch-your-game/

[MJP]

Originally Posted by jlippo

16k*16k*8k*4bytes is ~8TB
I'm not sure why you would use 3D texture with megatexturing, unless you are using it for irradiance volumes.

A signed distance field representation of the scene could be useful for a lot of things.

[jlippo]

Originally Posted by MJP

A signed distance field representation of the scene could be useful for a lot of things.

Certainly an interesting idea..

[Frenetic Pony]

Originally Posted by Acert93

You should write an article on such. It would be interesting to know what approaches allow for the most content generation within a window of time and those that limit content generation, and also how the type of game impacts content generation. We do not hear enough from artists.

As a quick reference I would say: Get rid of things I don't want to do. Give me automatic rigging, and automatic UV mapping, and don't make me unroll UV maps. But those are obvious, from a more practical standpoint the thing I've notices is that a lot of engines and engineers will put in a lot unnecessary controls and tweaks and etc. At least to my eyes.

For example, tooling around in the updated Cryengine SDK I notice a ton of options for tessellation no one would practicably use. Like phong tessellation. Ok, from a tech perspective I understand "hey that's neat, I can totally put that in." But frankly I'd rather have models authored as is and blocky than smooth and ballooned out.

I'd say, honestly, take a look at Unity Pro. That is such a wonderful engine to work with. Very clean, and obvious, and etc. Joking around with a programmer recently at a game jam we both agreed that eventually Unity would just be a "Make game button" where you filled out a questionnaire and then out popped your game. Point is their tools are mostly wonderful to use, and others could take lessons.

[Frenetic Pony]

Also, on a random tangent, I'd love to see sparse texture approach used for spherical harmonic/needlet (is that what microsofts new shiny math is called? It was presented at GDC but I've yet to look) anyway, spherical harmonic probes. That seems to be, for now, THE way to get mostly dynamic GI at a relatively cheap cost. Both Lionhead and "Massive" (are they a ubisoft studio just called Massive?) have come up with neat ways to use both for relatively cheap dynamic diffuse GI effects.

But as far as I know that just load a grid of them around you. With a "sparse texture" like approach you could instead only load the probes that apply to the geometry you're currently viewing. Because the probes are spaced in a grid pattern you obviously wouldn't have a constant cost, but it would still be more efficient than just loading all the probes within X of the player.

[deeFive]

Thanks Davros!

Another quick update its another quick busy day here:

openGL doesn’t seem as tidy as DX is just now, there seem to be a lot of different code paths for the different levels, this may be due to the way the info I found was written, so I’m going to target 4.0 and up so that i can target glMegatex (if that is how it works, please correct me if im worng)

Frenetic Pony - i agree that unity is the leader right now (ahead of cryengine and unreal) would love to give you fully automated uv unwrapping, but i still would like artist to unwrap the uv's a certain way as it may help with shading later in the pipeline (i still need to test this).

i also agree about having a "local" grid arround the player but i need to test to see how much faster this approch is.

In fact I’m using unity as my low (this is where I feel all of the art battles need to be won) end and prototyping platform currently, this work will still stand above that and replacing it (unity) long term.

With that said I’m wanting to automate as much as possible, so what else would you like to see done in engine (just art wise please, i’ll get to the rest later) – to this end here is a list of things of to be automated:
1.) rigging – this should be tied to the ragdoll systems and allow animators to animate
2.) detail shading – this should be done procedurally with texture artists producing colour, normal and SFX guide textures.
3.) Lighting should be handled in engine and be dynamic or volume based
This is just a start there will be more to come! Please feel free to add anything you feel should be here.

Also mods should i start a new thread or continune this one?

[Richard]

You should go ahead and start a new one.