Ike Turner
Veteran
If Rage had 4x the texel density
- Thread starter kyleb
- Start date
True, but it does have to be done by the developers/artists and they don't want to wait around to find out if a particular texture can be compressed without significant loss of quality or not.
sorry didn’t mean to take so long to answer (I’ve been a little busy).
Does the megatexture currently store player and npc textures?
Have there been any new demos of procedural detail shaders in the last 3 months?
Artists might love procedural detail shaders (or "surface attribute" shaders) as it would let them just export uv, normal/tessellation and colour maps. with the rest been tweak-able in engine (said engine would need to support all the major file fomats to save the artists time), via sliders or 1 channel (greyscale textures = more artist burden)
But for this too look good you may need 7 or 8 layers and im not sure how fast that would be.
Does the megatexture currently store player and npc textures?
Have there been any new demos of procedural detail shaders in the last 3 months?
Artists might love procedural detail shaders (or "surface attribute" shaders) as it would let them just export uv, normal/tessellation and colour maps. with the rest been tweak-able in engine (said engine would need to support all the major file fomats to save the artists time), via sliders or 1 channel (greyscale textures = more artist burden)
But for this too look good you may need 7 or 8 layers and im not sure how fast that would be.
hmmm, that would mean that all of the textures would have to get smaller in order for this to work as well as needing more shader time to render all of the extra attributes (which is fine (with me!) on PC, not so good for consoles or slate PC's).
Have any idtech 5 post-mortems, about performance been released by ID (or are any upcoming, GDC, siggraph, ect...)?
Have any idtech 5 post-mortems, about performance been released by ID (or are any upcoming, GDC, siggraph, ect...)?
so im going to look into AMD PRTex to see what improvements (imo) could be made, does how do people feel about this list of base attributes:
1.) base mesh (g-buffer)
2.) base colour
3.) base normals/tessellation
4.) base sub-surface
5.) base specular
6.) base dirt
7.) base light
8.) base shadow
1.) base mesh (g-buffer)
2.) base colour
3.) base normals/tessellation
4.) base sub-surface
5.) base specular
6.) base dirt
7.) base light
8.) base shadow
Unfortunately no. I'm sure you're familiar with the established knowledge about MTs in id Tech 5? 3 types: static geometry, dynamic geometry and special effects (i.e. translucency). IIRC, id did eventually use standard texture mapping (or at best using atlases) for some surfaces like the GUI, etc. Anyway, static geometry MTs using 3 channels (everything baked in), the dynamic geometry have 6 (?) channels for the tangent normals and specularity. The special effect MTs would have more channels but AFAIK we never got any specifics on these.
WRT your other post, a couple of questions:
1) what do you mean by "going to look into AMD PRTex to see what improvements (imo) could be made"? In id Tech 5 or in a brand new engine? IIRC (again - getting old) JC said they could have used AMD's tech but the storage MTs would have to be broken up into 32k^2 (someone else said 16k^2). And what kind of improvements? Performance or quality? JC mentioned (and sort of post-mortem mode) that had they known what they knew at release time they'd probably change the encoding to store the different MT levels together, rather than by coordinates as that would aleviate the initial stream where you see the entire screen at lowest rez. Maybe load the first MT level right off the bat and then adapt.
2) Why would you need two atributes for colour and light? Related, would a normal atribute be usable as a tesselation atribute? Don't you need more information? (I'm thinking tangent normals).
No, artists hate fighting with procedurals, and would prefer to just move in with a brush and paint exactly what they want
so im at work and its a little busy so i'll laa-Yosh first as its a quicker answer, sorry richard i'll give a full answer once its slowed down here(at work) a little.
so the aim is for the artists would be for them to paint areas that the procedurals will effect and based on what you said it may even be better to let them do it in editor, does this sound better?
Also please keep in mind im thinking out loud here, all feedback and ideas are welcome!
so the aim is for the artists would be for them to paint areas that the procedurals will effect and based on what you said it may even be better to let them do it in editor, does this sound better?
Also please keep in mind im thinking out loud here, all feedback and ideas are welcome!
Artists don't like procedurals. They always look more artificial and less good, compared to just painting without restrictions. They're also pretty hard to work with because they require thinking in numbers instead of colors and shapes.
An artist would always prefer higher texture res to messing with any kind of procedurals.
An artist would always prefer higher texture res to messing with any kind of procedurals.
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!
Also Its begining to slow here so im going to take some time to answer richard!
I dont understand the above
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?
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?
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.
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.
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.
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.
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.
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.
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.