Game Development Community

Multiple Materials & Performance in TGEA

by Greg G · in Torque Game Engine Advanced · 03/09/2009 (10:26 am) · 5 replies

Awhile ago I created a thread that talked about how torque renders objects redundantly if there was more than one material on the same mesh:

www.garagegames.com/community/forums/viewthread/60180

I am really interested to know if TGEA shares this problem, and if this is still an issue will be something that is fixed with COLLADA in Torque3D?

#1
03/09/2009 (11:07 am)
TGEA will do batch rendering, so a mesh with 7 separate textures will be rendered in 7 batches. As an example, lets say you have 7 'different' tree mesh, they all have the same trunk texture, but 7 different foliage textures. All the trunks are rendered in one batch, with the foliage being 7 batch so 8 render calls even if you have 100 of the tree mesh (this example is dumbed down for the sake of simplicity, there are still other render features to deal with).

I believe this is actually a hardware function, not specifically TGEA, and before being a hardware function it was handled in software (some video drivers handled it for you if the option was specifically used).

The for mentioned thread is a tad misleading, in that TGE use a new render call for each texture, not that it render the FULL mesh redundantly for each texture on the mesh.

To learn more, google TRIANGLE STRIPS as conceptually -simply put- this is the way 3D hardware views mesh data. So think of each new texture as new 'strip'- well this is kinda flawed terminology but the easiest way to think of it without dumping a large amount of nerdy hardware knowledge.
#2
03/09/2009 (12:05 pm)
Yes, but if multiple materials share one mesh inside the DTS file (for example if the trunk has two textures), will all of the polygons for the trunk mesh be rendered once for the first batch pass and again for the second batch pass since the trunk is a single mesh and not separate mesh nodes in the DTS hierarchy like the cards used for the leaves?

Or are ONLY the verts associated with that texture/material rendered for each batch pass?
#3
03/09/2009 (12:43 pm)
There is not any rendering overhead for useing multiple textures on one mesh, less the fact that each texture use a new render call. And even that is poor use of terminology. It have never been that it render the FULL mesh redundantly for each texture on a mesh; this is a misleading concept. It have been in the past that each texture on a mesh would set a state change and new render pass, and even this is fundamentally flawed logic once you delve into how 3D graphic hardware truly function, disregard how separate API's feed the video card.

If what you are asking is; Is it OK to use multiple textures on a mesh? The answer is yes, its not going to hurt anything especially if the textures are used repeatedly on other mesh in the scene as in my first example. I reuse a large set a textures on hundreds of different mesh, sometimes with more then 10 separate textures on ONE mesh, and never- not even when useing TGE had any performance slowdown caused from my mesh useing multiple textures.
#4
03/09/2009 (1:04 pm)
Thanks for the explanation. This seams to have been a myth for awhile now. I to have noticed no performance hits, but had read multiple places (the earliest I can remember is a post by Logan Foster) that you would "double your polycount" by adding additional materials to a single mesh.

As a result I have been breaking up my meshes, but that really doesn't appear to be necessary and the frame rate tests I have done show no noticeable impact. I was just trying to understand where the misconception came from, and also make sure my models were as optimized as possible.
#5
03/09/2009 (1:23 pm)
I had a similar discussion many years ago with Tim Sweeney, who explained that the days before 'real' 3D hardware multiple textures on one mesh would essentially cause the full mesh to be computed for each texture, what is most likely where the "multiple textures = double your polycount" concept comes from. This was specific to certain programing techniques at the time. 'Hardware' mesh do not fit into this handicap.