1,1024x1024 texture, or 4,512x512 textures?
by Harvey Greensall · in Torque Game Engine Advanced · 10/08/2007 (6:00 am) · 11 replies
Hi All,
Right, we're bugfixing art and optimising etc....such fun !
Anybody know anything about texture size vs performance? Say we've got 5 different objects, all with their own 512x512 texture used say 10 times each in the level...Is it better to squeeze these onto one shared 1024x1024 texture for these 5 objects instead? Does it make any difference/sense at all etc.
I can see it makes sense to have one 1024 instead of 5 512s, as we're using less space for the 5 objects, but is there any disadvantage to using a bigger texture?
Thanks, be interested in hearing your thoughts,
harv
Right, we're bugfixing art and optimising etc....such fun !
Anybody know anything about texture size vs performance? Say we've got 5 different objects, all with their own 512x512 texture used say 10 times each in the level...Is it better to squeeze these onto one shared 1024x1024 texture for these 5 objects instead? Does it make any difference/sense at all etc.
I can see it makes sense to have one 1024 instead of 5 512s, as we're using less space for the 5 objects, but is there any disadvantage to using a bigger texture?
Thanks, be interested in hearing your thoughts,
harv
#2
From what I can gather, DDS is the way to go, our textures have always been .pngs ...The reason I started this entire process is that we're having framerate issues on some Nvidea cards, so that also makes sense to go for an Nvidea plugin to create the textures huh?
As for the 1024x1024 issue, I think you're right there too, I'll do some tests and see how it goes.
Cheers for the info. J.C !!
10/08/2007 (7:20 am)
Yeah, I've been scratching around the forums for a couple of hours, and I think you've hit the nail on the head there.From what I can gather, DDS is the way to go, our textures have always been .pngs ...The reason I started this entire process is that we're having framerate issues on some Nvidea cards, so that also makes sense to go for an Nvidea plugin to create the textures huh?
As for the 1024x1024 issue, I think you're right there too, I'll do some tests and see how it goes.
Cheers for the info. J.C !!
#3
Moving most of your Diffuse (non normal map) textures to DDS should improve if not fix it
10/08/2007 (4:00 pm)
Framerate issues may very well be tied to some existing texture bugs with Nvidia cards/drivers.Moving most of your Diffuse (non normal map) textures to DDS should improve if not fix it
#4
TDN Link
BTW: Read This for multiple texture models
10/08/2007 (4:04 pm)
I saw 512*512 mentioned as max in some previous reading through the stuff here at GG...TDN Link
BTW: Read This for multiple texture models
#5
pref::TextureManager::qualityMode =0;
This will reduce all of your texture sizes by half. If that improves performance on those trouble cards, then the DDS stuff may help you out.
Just wanted to mention that, it's good to actually find out what the performance problem is before you try to solve it. ;)
JC's also right about having less state changes if you combine textures together. You'll have a decent win if this also allows you to combine materials together as well. This will allow the render batcher to batch more stuff together which means less shader changes.
10/08/2007 (6:40 pm)
A good test to run is to setpref::TextureManager::qualityMode =0;
This will reduce all of your texture sizes by half. If that improves performance on those trouble cards, then the DDS stuff may help you out.
Just wanted to mention that, it's good to actually find out what the performance problem is before you try to solve it. ;)
JC's also right about having less state changes if you combine textures together. You'll have a decent win if this also allows you to combine materials together as well. This will allow the render batcher to batch more stuff together which means less shader changes.
#6
@Jeremiah ... So don't make normal maps DDSs then? Any reason why?
@Christian ... I think the 512 thing is for TGE not TGEA. As far as I'm aware I think TGEA can handle 2048s..I may be mistaken though (not that we've used any)...As for the links, thanks, they're really, very interesting!!
@Brian ... Thanks for the tip, I'll have a good look into it. And yes, by combining textures together, we'll be able to have less materials in our material.cs if that's what you mean...Basically, if we had say 20 different 512 textures for all of our target objects in a level, we have 20 separate materials too, we'll now have 4 different 1024 ones instead, probably all DDS instead of pngs too...Surely that's got to help us out with our nVidea problem eh? it's not all Nvidea cards by the way, just all QUADROS and we've seen it on some 7600 setups, but not all strangely...wierd! No problems at all with ATIs though...
H.
10/09/2007 (1:56 am)
Thank you all for your comments guys...great stuff... I do have a couple of questions though...@Jeremiah ... So don't make normal maps DDSs then? Any reason why?
@Christian ... I think the 512 thing is for TGE not TGEA. As far as I'm aware I think TGEA can handle 2048s..I may be mistaken though (not that we've used any)...As for the links, thanks, they're really, very interesting!!
@Brian ... Thanks for the tip, I'll have a good look into it. And yes, by combining textures together, we'll be able to have less materials in our material.cs if that's what you mean...Basically, if we had say 20 different 512 textures for all of our target objects in a level, we have 20 separate materials too, we'll now have 4 different 1024 ones instead, probably all DDS instead of pngs too...Surely that's got to help us out with our nVidea problem eh? it's not all Nvidea cards by the way, just all QUADROS and we've seen it on some 7600 setups, but not all strangely...wierd! No problems at all with ATIs though...
H.
#7
On the normal-map DDS: DDS lose pixel data which you actually just put on the texture to create fictive details. Would therefor be kind of counter productive, as you could just take a texture with 1/2 width and height instead without compression and end up +- at the same point.
You still could use DDS without compression thought. But as DDS is a "hacked in" format into TGEA (no ressourceInstance derivate like any other media and model format), some seem to prefer PNG, as I do.
10/09/2007 (2:25 am)
Yeah TGEA supports anything your card can handle. Beside the terrains where this does not hold as they have hardcoded limits and assumptions.On the normal-map DDS: DDS lose pixel data which you actually just put on the texture to create fictive details. Would therefor be kind of counter productive, as you could just take a texture with 1/2 width and height instead without compression and end up +- at the same point.
You still could use DDS without compression thought. But as DDS is a "hacked in" format into TGEA (no ressourceInstance derivate like any other media and model format), some seem to prefer PNG, as I do.
#8
So you can have DDS normal maps if you like, but they're no better than having a .png but just halving it's size...Does this apply to the diffuse too? I've been exporting as DDSs, with no visible difference in quality, and they're smaller than my .pngs in filesize. I understand they don't 'decompress' onto the videocard too, so would help loads. One question to anyone who may know, if we go the DDS route, is it better to let the DDS exporter create mipmaps or just leave it to the engine as we did with .pngs?
10/09/2007 (3:01 am)
Blimey...Now I'm in a world of uncertainty and confusion 8)So you can have DDS normal maps if you like, but they're no better than having a .png but just halving it's size...Does this apply to the diffuse too? I've been exporting as DDSs, with no visible difference in quality, and they're smaller than my .pngs in filesize. I understand they don't 'decompress' onto the videocard too, so would help loads. One question to anyone who may know, if we go the DDS route, is it better to let the DDS exporter create mipmaps or just leave it to the engine as we did with .pngs?
#9
The lose of quality depends on the DXT mode used. As it stores the same amount of data on less space, they naturally have to lose quality / information at some point.
For diffuse maps you don't see that problem really, as you do not see it with JPG normally. Thats due to superb texture filtering technics etc.
But a normal map is never shown. it is used for pure informations for the processing of the surface in the pixel shader and on that end, difference can become noticable. But you might want to check out the differences. perhaps its that minimal that it can't be noticed and you can use them as well :)
Don't know if DDS are smaller than PNG if you don't use DXT compression modes. If they are, you naturally can use them for anything when not applying DXT compression.
10/09/2007 (11:47 pm)
If you use DDS, its better to store the mipmaps directly in them, otherwise the GPU will have to create them which costs runtime instead of precalculation time on your side.The lose of quality depends on the DXT mode used. As it stores the same amount of data on less space, they naturally have to lose quality / information at some point.
For diffuse maps you don't see that problem really, as you do not see it with JPG normally. Thats due to superb texture filtering technics etc.
But a normal map is never shown. it is used for pure informations for the processing of the surface in the pixel shader and on that end, difference can become noticable. But you might want to check out the differences. perhaps its that minimal that it can't be noticed and you can use them as well :)
Don't know if DDS are smaller than PNG if you don't use DXT compression modes. If they are, you naturally can use them for anything when not applying DXT compression.
#10
I've set everything up as usual...added the .dds file extension to the material.cs entry and the texture just appears orange. If I drop it in as a .png instead, works fine...
So near, yet so far...
10/10/2007 (2:05 am)
Have you guys seen .DDSs working in TGEA? If so, what DXT compression mode did you use? Did you use the Nvidea plugin to create them? I've set everything up as usual...added the .dds file extension to the material.cs entry and the texture just appears orange. If I drop it in as a .png instead, works fine...
So near, yet so far...
#11
new Material(crownhullmaterial)
{
baseTex[0] = "~/data/shapes/EXPORT/crownhull.dds";
mapTo = "Crownhull";
};
DDSs now work fine 8)
Thanks guys, yet again loving the GG forums, great stuff!
10/10/2007 (2:32 am)
Just had a good scout about and found I'd not got a line I needed in my material.cs for anyone who's interested I had to add the bold text below to force the .dds to be used...new Material(crownhullmaterial)
{
baseTex[0] = "~/data/shapes/EXPORT/crownhull.dds";
mapTo = "Crownhull";
};
DDSs now work fine 8)
Thanks guys, yet again loving the GG forums, great stuff!
Torque 3D Owner J.C. Smith