Texture/Material layers in TGEA?

#1 How about just using the material ... I think 16 layers should be enough ;-)

Texture[0] - Texture[15] in the material datablock

#2 Yes but I am looking for a more customizable approach instead of having everything predefined as it is in the TGE resources. Unfortunately any conversion from TGE of those resources I have attempted has ended in failure.

#3 Well more customizable automatically means tinkering with the shader and the C++ side that feeds them with the textures etc.

TGE resource are +- worthless when they are directly or indirectly related to the graphics backend unless you have a deep understanding on how TGEAs side works and how to write shaders for stuff that needs new custommaterials

#4 How would you tell the system to selectively active these 16 textures?

I am pretty new to this so since I have seen that there is a customMaterial as well as material ( I have ready how the custom is derived from material), would you create a custom material, still specify the base texture and then somehow have the ability to blend these textures in?

#5 What do you mean by selectively?

Either they are on the legacy or are not, there is no selective behavior on the legacy.
The main problem is the placing of them as GG didn't spend the least bit of time to fix the editor for TGEA ... this means: you can place 4 textures by painting on the terrain, the other 12 can only be placed by the "automatic painting" ...

and you do that whole thing in the editors, not through a shader or the like. (the needed shader for it already is there and used

#6 Marc, i am "not sure" that modern GPUs can access(sample) more than 8 textures (t0-t7 registers).
I think you're wrong about that, input registers for VS are 16 (v0-v15), not texture registers.

http://msdn2.microsoft.com/en-us/library/bb172924(VS.85).aspx
http://msdn2.microsoft.com/en-us/library/bb172963(VS.85).aspx

#7 ?!
I know but please explain that to GG, not to me :-)
I only repeat what the documents state, and they state texture[0] - texture[15]
Not that I would ever use that many, I don't prefer wasting performance with more ops than needed.

And a little addition info on the 16 texture legacy usage
If you use 16 textures on legacy terrain it will call the 4 texture + detail blend step 4 times on SM2 and a 8 times on SM1.X (as that one only blends 2 textures + detail)

So the more textures you put on the more passes it will take to finish.

#8 So...what's the question?

Yes there are that many texture slots on a material. No you can't use them all simultaneously on current hardware, but you shouldn't need or want to. 4 is really probably the maximum I would use due to fill rate concern across legacy hardware. Considering the number of draw calls for terrain drawing, including re-drawing the detail blocks (which, while it doesn't use more than one texture, requires multiple samplers to properly execute the blend) I can't see why you'd want to use more than 4. That's 4 textures that need to be uploaded and sampled, at a wide variety of mip levels, during terrain drawing.

As a side note, I find it hilarious that, for all the questions regarding, "How many textures can I slap into my game," there's not a single forum post complaining bitterly about the lack of support for DXT, or asking how they can reduce the fill-rate hit for a scene draw.

#9 OK I can see this is leading away from the purpose I need this for.

With this resource in TGE:
www.garagegames.com/mg/forums/result.thread.php?qt=70697

I was able to essentially place transparent layers anywhere I wanted to on the object. This allowed me to basically place damage decals on my players and vehicles. I need a method to do that in TGEA. I was hoping someone had already tried something like it sucessfully.

I can see now that it would have to be a material that is layered on to the object since that is the only way you would be able to specifiy the translucency. So basically I would have the original material, then place layer the other material over it, preferredly by texture XY coordinates like in that resource.

Perhaps now I have better explained myself.

#10 Good point on the DXT Pat.
Would definitely raise the whole thing to a higher performance level.

But we all know that DXT + TGEA is a thing of itself as even GG didn't invest the time to implement it fully (its not even a ResourceInstance *DDS*, so it would definitely need quite some extra work). So it does not seem to be a straight forward thing if you want to integrate it cleanly.

But at least you brought up something that I might look into for my legacy terrain ideas or however one wants to call them. I think Atlas2 is nice but I would like to have something that allows dynamic deformation so either legacy or TX3Ds terrain (haven't had an indepth look at Atlas1 but I saw that there is some kind of editor fragment in the sources of TGEA so I should have a look at that one as well if I find a way through the Atlas2 - Atlas1 mess there). And due to the way the whole thing blends currently, it definitely would benefit of it :)

#11

Quote:there's not a single forum post complaining bitterly about the lack of support for DXT,

Why complain when the stock GG answer is something like: "You have the code: write it!"

#12 Especially as this was the answer on that topic made through Stephen when I remember correctly.

#13 I think moving from FFP is a great deal, it is more versatile, believe me.

Instead of COLOROP, COLORARGn, ALPHAOP, ALPHAARGn, RESULTARG - we have PS
Instead of TEXCOORDINDEX, TEXTURETRANSFORMFLAGS - we have VS.

VS replaces a lot of Render States, such as LIGHTING, DIFFUSEMATERIALSOURCE, SPECULARMATERIALSOURCE, AMBIENTMATERIALSOURCE, EMISSIVEMATERIALSOURCE, SPECULARENABLE, LOCALVIEWER, NORMALIZENORMALS, FOGSTART, FOGEND, FOGDENSITY, AMBIENT, COLORVERTEX.

"You have the code: write it! ..... if you can :)"

#14 For optimization work on the IA games, I've been using the D3DX functions to convert to DXT during texture upload. The implementation is kind of kludgy but it was good to do because it gave me some good ideas on how we really need to change some of the material stuff in TGEA.

There are a few "gotchas" when doing this. The first is that, once a texture is loaded by the texture manager, it ignores the texture profile that it is created with, when returning cached textures. So, for example, if a texture gets loaded with a non DXT texture profile (I used the compression flags in the texture profiles that exist now but are never referenced) and you request it with DXT compression, it will return the first texture. This is really lame, and I didn't fix it because it'd be pretty invasive. I also don't like using D3DX functions if I can avoid it, and for the "real" implementation that will go into the engines I am pretty sure we are going to use a great 3rd party library called Squish.

To signify that you want a texture compressed in a material I just hacked some stuff in that lets you flag different stages for compression (like you don't want to compress normal maps [3Dc and DXT5 color shifting aside]) so you can selectivly compress things. For the skyboxes I hacked some stuff into the MaterialList code that looks for "#DXTn" at the top of a DML and then it will compress the material list.

This gives some big wins, but always, always, always be aware of fill rate issues. We've been finding that the games are GPU bound, and too many samplers is a big part of that.

#15 OK this all interesting and all, but it really doesn't help me at all in what I asked about.

#16 You asked for texture layers which is exactly what I posted straight after your posting.

The alternative is to create a multi pass shader by using the indices [0] [1] etc. the number defines the pass. 0 is rendered first, then 1, then 2, ...

There is no layer resource as TGEA supports it out of the box if you declare the material correctly.

If this does not meet your requirements / dreams, you can always write a shader and define a costum material to do exactly what you want. (there is no way without shaders, TGEA has no fixed pipeline support)

#17 Marc, I understand what you are saying.

However, that method really doesn't meet what I am looking for. Basically what I used that resource for was a texture coordinate based decal system that allowed me to place decals on dts shapes.

#18 Well that would be hand written shader then, TGE resources will not work nor can they be usefully converted on visual stuff due to the large differences in the visual sector.

#19 Agreed. Since I am fairly new at shader writing, is there somewhere I learn how to write the shaders myself? I looked at TDN already, its still pretty sparce on the info.

#20 There are many books on writing HLSL shaders, the DX documentation might perhaps help as well and there are naturally NVIDIAs and ATIs dev pages with their shader development suites which are free which are a good base to start as well.