Performance question - Texture sizes
by Dusty Monk · in Torque 3D Professional · 10/19/2010 (8:04 pm) · 6 replies
So we're in the midst of making a performance pass on our level, in T3D B2. We've already gathered some metrics, and done many of the things that have been suggested in various threads around here, such as creating NULL LOD's for many objects, reducing the # of materials where possible, decreasing the number of splits in shadows, reducing shadow distance, etc. And we've seen some significant gains.
One of things we've done is to go through and convert pretty much all of our diffuse maps (and the few normal maps we're still using) to DXT1 .DDS files, with mipmaps built in. This has made a significant improvement.
However, due to some recent changes we've made, I'm beginning to worry we might be going the wrong way. That is, despite improvements to FPS, and reductions in draw calls, I'm still seeing some pretty serious hitches as we move around the level, especially as we turn and view across a part of the level for the first time. This has me wondering if texture load times are perhaps becoming an issue.
Something we've started to do is to combine textures for a number of small objects into a single, larger, .DDS texture. So before, where we might have had 4 to 6 different 256x256 textures, resulting in that many different materials, we now have a single 1024x1024 .DDS texture (and resultant material), and all of those objects referencing that material.
My concern is that the load time for the larger 1024x1024 texture is outweighing the gains we might make by reducing the # of draw calls for having only a single texture. And I don't really know exactly how to go about determining if this is the case quantitatively.
So for general question for the hardware gurus.. can a general statement be made in terms of better performance about having fewer, larger textures,versus many, smaller ones? Especially if the textures are all mipmapped and sized by powers of 2?
And a follow up, besides the gfx metrics, which I'm using (gfx, fps, and shadow), are their other metrics or tools that anyone can suggest to make quantitave assessments of how efficient (or not) our texture and material use is?
I have to profess to not being much of a render monkey -- more of a sim and gameplay guy -- so any help or suggestions along these lines would be greatly appreciated.
Dusty
One of things we've done is to go through and convert pretty much all of our diffuse maps (and the few normal maps we're still using) to DXT1 .DDS files, with mipmaps built in. This has made a significant improvement.
However, due to some recent changes we've made, I'm beginning to worry we might be going the wrong way. That is, despite improvements to FPS, and reductions in draw calls, I'm still seeing some pretty serious hitches as we move around the level, especially as we turn and view across a part of the level for the first time. This has me wondering if texture load times are perhaps becoming an issue.
Something we've started to do is to combine textures for a number of small objects into a single, larger, .DDS texture. So before, where we might have had 4 to 6 different 256x256 textures, resulting in that many different materials, we now have a single 1024x1024 .DDS texture (and resultant material), and all of those objects referencing that material.
My concern is that the load time for the larger 1024x1024 texture is outweighing the gains we might make by reducing the # of draw calls for having only a single texture. And I don't really know exactly how to go about determining if this is the case quantitatively.
So for general question for the hardware gurus.. can a general statement be made in terms of better performance about having fewer, larger textures,versus many, smaller ones? Especially if the textures are all mipmapped and sized by powers of 2?
And a follow up, besides the gfx metrics, which I'm using (gfx, fps, and shadow), are their other metrics or tools that anyone can suggest to make quantitave assessments of how efficient (or not) our texture and material use is?
I have to profess to not being much of a render monkey -- more of a sim and gameplay guy -- so any help or suggestions along these lines would be greatly appreciated.
Dusty
About the author
Dusty Monk is founder and president of Windstorm Studios, an independant game studio. Formerly a sr. programmer at Ensemble Studios, Dusty has worked on AAA titles such as Age of Empires II & III, and Halo Wars.
#2
Yeah the hack for placing an object with every material on it inside the view frustrum at the beginning of the level (but behind a progress UI) is not a bad idea. Like you, I'd need some means of trying to figure out exactly every material I'm using (there are a LOT). And better yet would be a script function that could go through and just preload all of the materials as a part of the level load process.
Hopefully I can still get someone to chime in on texture efficiency recommendations, as even with texture preloading, I'd still rather just build the textures in a more efficient manner, if I can do so.
And thanks for the texture profile stats command -- I'll give that a try this morning. Those are the gems you love to find!
Dusty
10/20/2010 (1:28 pm)
Hey Steve:Yeah the hack for placing an object with every material on it inside the view frustrum at the beginning of the level (but behind a progress UI) is not a bad idea. Like you, I'd need some means of trying to figure out exactly every material I'm using (there are a LOT). And better yet would be a script function that could go through and just preload all of the materials as a part of the level load process.
Hopefully I can still get someone to chime in on texture efficiency recommendations, as even with texture preloading, I'd still rather just build the textures in a more efficient manner, if I can do so.
And thanks for the texture profile stats command -- I'll give that a try this morning. Those are the gems you love to find!
Dusty
#3
Whilst 4 x512 does appear to be the same as 1 x1024 (though on-the-fly loading the 1024s make a big judder), it might not be such a good idea if you've got a mesh with only material. Smaller textures load faster and there might not be any point to having unrelated mesh materials lumped together.
Amalgamating textures into a larger one obvious helps reduce drawcalls on a mesh with multiple materials, but you can't do that with tiling textures.
I came up with the idea of making a real low-res "master" texture for all my buildings, one which has larger tiling maps of all my brickwork shrunk right down, which I can use at range on the lower LODs where the detail isn't visible to the human eye. I guess that's sort of like a low-res atlus/megatexture for LOD.
10/20/2010 (2:21 pm)
Quick note on my experiments with texture efficiency ...Whilst 4 x512 does appear to be the same as 1 x1024 (though on-the-fly loading the 1024s make a big judder), it might not be such a good idea if you've got a mesh with only material. Smaller textures load faster and there might not be any point to having unrelated mesh materials lumped together.
Amalgamating textures into a larger one obvious helps reduce drawcalls on a mesh with multiple materials, but you can't do that with tiling textures.
I came up with the idea of making a real low-res "master" texture for all my buildings, one which has larger tiling maps of all my brickwork shrunk right down, which I can use at range on the lower LODs where the detail isn't visible to the human eye. I guess that's sort of like a low-res atlus/megatexture for LOD.
#4
10/20/2010 (3:12 pm)
I am working on performance issue with my project also. can you guys suggest some posts or more of your own ideas and working measures for getting the best performance? 
#5
10/20/2010 (3:44 pm)
I've recently done a performance sweep; increasing performance by reducing texture sizes on dts objects that have a huge poly count. Keeping the texture sizes high where detail is required (for now). One of my major issues is tree's, so I've removed them for now, but may try billboarding some onto the back of high terrains, spreading trees around rather than keeping them grouped together helps but is definately a frame rate killer. 
#6
By managing memory, I mean handling loading/unloading, especially on memory saturation.
Nicolas Buquet
www.buquet-net.com/cv/
10/20/2010 (4:42 pm)
I think it is easier for the GPU to manage its graphic memory with a lot of small textures than a few big textures.By managing memory, I mean handling loading/unloading, especially on memory saturation.
Nicolas Buquet
www.buquet-net.com/cv/
Associate Steve Acaster
[YorkshireRifles.com]
Manoel(?) did mention that it'd be possible to have a tiny object with all textures on visible at start and hidden behind a fullscreen gui as a hack to get them all to load at the beginning.
I was wondering if it would be possible to load the textures via script at the start and made a thread up in the hope of suggestions - linky
for extra metrics try
I wrote that one down after Tom told me it!