Tris Versus Textures
by Steve Acaster · 04/15/2009 (11:25 am) · 30 comments
A long time ago, in a galaxy far, far away (these forums), someone (probably Matt Fairfax) made a post on the forums or in a blog which gave the memory useage for various texture sizes. I noted that useage did not double with size, but was on a much more aggressive scale. Thus 1024x gave a lot more of a kicking to Vram than two 512x.
So, town2 version (counts on fingers) er ... 4? is done. It's a polysouped DTS, with all of the buildings enterable. No facades this time. The 2 storey facade textures (1024x) have been ditched in favour of standard 512x brickwork textures (which the facades were previously based on and had been used around the map for low walls). All doors and windows are now modeled, and are proper openings. All buildings are now fully enterable and made up of multiple rooms. Each building has at least one staircase, large buildings have two. Access to and from upstairs is granted. Access through all buildings now exists.
Prefab houses
There are currently 6 building types being used as prefabs, with a couple of custom ones (eg: church and chapel - church is still a facade, the only one left). All have at least one front and back external door, a minumum of 8 windows and 7 rooms. All have at least one staircase.
There are 50 buildings in the village. That's 641 windows, 180 external doors, 578 rooms, with 81 staircases, all linked, all useable, all explorable. I didn't count how many internal doors there were, but obviously they are what seperate the rooms so work it out (it might even be the same number as the rooms).
Needless to say this has affected the tris slightly. Tris now stands at around 48k up from 15k. And it's also affected performance - for the better.
From all closed facades to 1399-ish openings for view and movement
Previously, with most of my Vcard (256mb 7900GS) settings on "performance" with x2 AA and Anisotropic OFF and display on x768, I was recording 165fps with the polysouped, facade mesh.
Dispensing of the services of the 1024x facade textures, and increasing the polysouped mesh by over 500%, I get the following results.
New Vcard settings are "quality" including x2 anistropic and AA. At x768 it gives a whopping 196fps, and at x1050 it gives an equally impressive 127fps.
I did have a few issues with exporting the DTS. I had to split the model into 6 seperate meshes, as together they exceeded the max vertices count. But as seperate meshes within the same DTS model they exported fine. This is DTS only, I don't have a DIF version of this... err ... town version.
There's lots more opportunites to worry about being ambushed. 1399 of them
So, point proven on Vram and texture size against tris count. This was conducted on TGEA1.7.1, 1.8.1 would probably gain more of a performance boost (maybe 10%). How this will work with T3D lighting system remains to be seen, but I'd be quietly hopeful that all will be well.
In the meantime I have a Campaign for Real Ale Festival to go to, the last refuge of Saint George Flag waving, folk singing, Morris Dancing, sandal wearing, unkempt beardies who have a deep understanding of the different forms of droppings excreted by the monstrous badger of doom.
BADGER_OF_DOOM is also the current codename for my project - it's not just the 3A studios that can make up stupid codenames for games still in development, so can one guy working away in his bedroom
God save England, 'arry and Saint George!
So, town2 version (counts on fingers) er ... 4? is done. It's a polysouped DTS, with all of the buildings enterable. No facades this time. The 2 storey facade textures (1024x) have been ditched in favour of standard 512x brickwork textures (which the facades were previously based on and had been used around the map for low walls). All doors and windows are now modeled, and are proper openings. All buildings are now fully enterable and made up of multiple rooms. Each building has at least one staircase, large buildings have two. Access to and from upstairs is granted. Access through all buildings now exists.
Prefab houses
There are currently 6 building types being used as prefabs, with a couple of custom ones (eg: church and chapel - church is still a facade, the only one left). All have at least one front and back external door, a minumum of 8 windows and 7 rooms. All have at least one staircase.
There are 50 buildings in the village. That's 641 windows, 180 external doors, 578 rooms, with 81 staircases, all linked, all useable, all explorable. I didn't count how many internal doors there were, but obviously they are what seperate the rooms so work it out (it might even be the same number as the rooms).
Needless to say this has affected the tris slightly. Tris now stands at around 48k up from 15k. And it's also affected performance - for the better.
From all closed facades to 1399-ish openings for view and movement
Previously, with most of my Vcard (256mb 7900GS) settings on "performance" with x2 AA and Anisotropic OFF and display on x768, I was recording 165fps with the polysouped, facade mesh.
Dispensing of the services of the 1024x facade textures, and increasing the polysouped mesh by over 500%, I get the following results.
New Vcard settings are "quality" including x2 anistropic and AA. At x768 it gives a whopping 196fps, and at x1050 it gives an equally impressive 127fps.
I did have a few issues with exporting the DTS. I had to split the model into 6 seperate meshes, as together they exceeded the max vertices count. But as seperate meshes within the same DTS model they exported fine. This is DTS only, I don't have a DIF version of this... err ... town version.
There's lots more opportunites to worry about being ambushed. 1399 of them
So, point proven on Vram and texture size against tris count. This was conducted on TGEA1.7.1, 1.8.1 would probably gain more of a performance boost (maybe 10%). How this will work with T3D lighting system remains to be seen, but I'd be quietly hopeful that all will be well.
In the meantime I have a Campaign for Real Ale Festival to go to, the last refuge of Saint George Flag waving, folk singing, Morris Dancing, sandal wearing, unkempt beardies who have a deep understanding of the different forms of droppings excreted by the monstrous badger of doom.
BADGER_OF_DOOM is also the current codename for my project - it's not just the 3A studios that can make up stupid codenames for games still in development, so can one guy working away in his bedroom
God save England, 'arry and Saint George!
About the author
One Bloke ... In His Bedroom ... Making Indie Games ...
#2
04/15/2009 (12:10 pm)
That's certainly how it seems Ted, a 5 fold increase in geometry is a lot less resource munching on TGEA than using 15 1024x textures. The above DTS village has 27 512x textures. 
#3
Texture filtering is more expensive on larger textures than smaller textures, so it's more work per pixel for the graphics card to sample the texture. And that is the main reason that you see the performance increase.
Also, sometimes the graphics card/API has to move the textures around in memory, and that's another thing that makes larger textures more expensive. For one, with smaller textures it's easier to fit them in memory in a way that reduces the frequency that they have to be moved, and the amount of data that has to be moved for each texture is also reduced.
04/15/2009 (12:43 pm)
Triangle count is not much of a factor anymore (within reasonable limits) compared to pixel calculations/overdraw. Since you're not changing much in relation to pixel overdraw there the cost of increasing the triangle count is almost nonexistent.Texture filtering is more expensive on larger textures than smaller textures, so it's more work per pixel for the graphics card to sample the texture. And that is the main reason that you see the performance increase.
Also, sometimes the graphics card/API has to move the textures around in memory, and that's another thing that makes larger textures more expensive. For one, with smaller textures it's easier to fit them in memory in a way that reduces the frequency that they have to be moved, and the amount of data that has to be moved for each texture is also reduced.
#4
I just did a test with all 27 textures and their normalmaps at 256x and the performance increase was really negligible, just 5fps in both x768 and x1050. So I understand what you mean.
04/15/2009 (1:23 pm)
Thanks for that explanation Gerald.I just did a test with all 27 textures and their normalmaps at 256x and the performance increase was really negligible, just 5fps in both x768 and x1050. So I understand what you mean.
#5
512 x 512 x 2 = 524288 pixels
Try the same test with 2x [1024x512 px] textures instead and see if you get different results.
2 512 maps isn't the same texture space as one 1024 map. It's not like you're getting a magical benefit, I don't think. 2 512 maps should take up 1/2 as much vram as a 1024 map. You cut out 1/2 of the texture data in lieu of a large increase of polygons. It's true that tris != pixels in terms of rendering weight. Tris are actually much cheaper (As Gerald above said).
04/15/2009 (1:26 pm)
1024 x 1024 = 1048576 pixels512 x 512 x 2 = 524288 pixels
Try the same test with 2x [1024x512 px] textures instead and see if you get different results.
2 512 maps isn't the same texture space as one 1024 map. It's not like you're getting a magical benefit, I don't think. 2 512 maps should take up 1/2 as much vram as a 1024 map. You cut out 1/2 of the texture data in lieu of a large increase of polygons. It's true that tris != pixels in terms of rendering weight. Tris are actually much cheaper (As Gerald above said).
#6
I'm not an expert on this, so I could be speaking incorrectly, but if you aren't already, you should try using .DDS as an experiment.
I think that would reduce the filtering load on the GPU without significantly increasing the texture size. Essentially the DDS exporter is pre-calculating the filters, and if you're using the Photoshop exporter, you actually get better results than what most GPU's produce.
It's awesome that you have it down to six meshes. That gives you a good ratio of batches to triangles.
Great blog! Thanks for the information.
04/15/2009 (1:28 pm)
Something to try... what file format are you using for your textures?I'm not an expert on this, so I could be speaking incorrectly, but if you aren't already, you should try using .DDS as an experiment.
I think that would reduce the filtering load on the GPU without significantly increasing the texture size. Essentially the DDS exporter is pre-calculating the filters, and if you're using the Photoshop exporter, you actually get better results than what most GPU's produce.
It's awesome that you have it down to six meshes. That gives you a good ratio of batches to triangles.
Great blog! Thanks for the information.
#7
04/15/2009 (1:33 pm)
DDS for textures, jpg for normals - though I'll be changing that as I had my problems with optical effect errors on DDS normals explained to me. 
#8
1. Use DTS... they perform very well.
2. Test using prefab buildings instead of one large DTS. It can sometimes be better for culling and performance when you take point 3 into consideration...
3. Make lower LOD buildings. At your lowest LOD your bulding should take no more than one draw call to render. Remove unnessasary complexities at a distance like all the interior of the building.
4. Use DDS textures agressively.
04/15/2009 (1:52 pm)
As for preparing for Torque 3D a few thoughts...1. Use DTS... they perform very well.
2. Test using prefab buildings instead of one large DTS. It can sometimes be better for culling and performance when you take point 3 into consideration...
3. Make lower LOD buildings. At your lowest LOD your bulding should take no more than one draw call to render. Remove unnessasary complexities at a distance like all the interior of the building.
4. Use DDS textures agressively.
#9
Using my high poly version with just two 1024x512s (all others 512x) I noticed an average 10fps drop from the above blog results.
Also using my lowpoly facade version with all 14 1024x1024 replaced with 1024x512s gave very low (in comparision) results on both DTS and DIF versions (111/70fps). Worse than 165/125 fps recorded in my previous blog. I suspect this is related to my older gen Vcard.
@Tom
1. Okay, I'm finding that too.
2. I'll see which works best when the Beta comes out (which this is all kinda prep for anyhow). My stuff is really quite low-poly anyhow, individually, buildings are 582-1120 tris.
3. Apart from these large environmental models (if you're always in them, there is not point LODing) I LOD everything.
4. Okaydokee.
04/15/2009 (2:13 pm)
@TonyUsing my high poly version with just two 1024x512s (all others 512x) I noticed an average 10fps drop from the above blog results.
Also using my lowpoly facade version with all 14 1024x1024 replaced with 1024x512s gave very low (in comparision) results on both DTS and DIF versions (111/70fps). Worse than 165/125 fps recorded in my previous blog. I suspect this is related to my older gen Vcard.
@Tom
1. Okay, I'm finding that too.
2. I'll see which works best when the Beta comes out (which this is all kinda prep for anyhow). My stuff is really quite low-poly anyhow, individually, buildings are 582-1120 tris.
3. Apart from these large environmental models (if you're always in them, there is not point LODing) I LOD everything.
4. Okaydokee.
#10
Well you don't split them up for reducing polycount. You do so for culling. Consider that from the shadow point of view it can often only see one or two houses, but your model my have your entire city combined into one mesh. This means that your entire city is rendered into the shadow although only a small fraction can be seen. You might be able to get away with this on the sun shadows... but it wouldn't if you add lots of little point lights. Eventually you will bog down the GPU with too many triangles.
The reason to LOD is for when your looking across your city at buildings in the distance. If your rendering the inside walls of your buildings when its rendering a shadow for the sun your wasting triangles.
All that said... you'll still have to test your scene and see what works best. If your buildings are all really under 1200 triangles you might have enough triangle thruput to get away with it.
04/15/2009 (2:31 pm)
@Steve - Well you don't split them up for reducing polycount. You do so for culling. Consider that from the shadow point of view it can often only see one or two houses, but your model my have your entire city combined into one mesh. This means that your entire city is rendered into the shadow although only a small fraction can be seen. You might be able to get away with this on the sun shadows... but it wouldn't if you add lots of little point lights. Eventually you will bog down the GPU with too many triangles.
The reason to LOD is for when your looking across your city at buildings in the distance. If your rendering the inside walls of your buildings when its rendering a shadow for the sun your wasting triangles.
All that said... you'll still have to test your scene and see what works best. If your buildings are all really under 1200 triangles you might have enough triangle thruput to get away with it.
#11
I am a little surprised you get such a difference though, I know for uncompressed textures (jpg, pngs, etc) by moving from 512x512 to 1024x1024 you quadruple the vram required to store them but I didn't think the same was true for DXTC textures as they're kept in compressed format and then decompressed by hardware on the Video card when required.... perhaps my knowledge isn't quite right then.
Either way thanks for the blog it's really very useful and I'll have to see how much difference it makes for our game.
04/15/2009 (2:37 pm)
Great work there Steve and I can second some of what Gerald has said about moving around in memory, the smaller your textures the more you'll keep in VRAM and get texture cache hits rather than having to reload from System Ram into VRAM.I am a little surprised you get such a difference though, I know for uncompressed textures (jpg, pngs, etc) by moving from 512x512 to 1024x1024 you quadruple the vram required to store them but I didn't think the same was true for DXTC textures as they're kept in compressed format and then decompressed by hardware on the Video card when required.... perhaps my knowledge isn't quite right then.
Either way thanks for the blog it's really very useful and I'll have to see how much difference it makes for our game.
#12
For normals, an uncompressed DDS works just fine. It's larger than your JPG on disk (but as large in VRAM) but again it loads faster and has better quality.
DXT lack quality when using fine gradients, though.
04/15/2009 (2:50 pm)
DXT (referred to DDS above) textures travel faster trough the bus, but on todays cards it probably isn't something you'll notice by watching FPS. They do load lots faster, and are much smaller in size compared to uncompressed textures.For normals, an uncompressed DDS works just fine. It's larger than your JPG on disk (but as large in VRAM) but again it loads faster and has better quality.
DXT lack quality when using fine gradients, though.
#13
After changing all my nomal maps to DDS with 3 mipmaps (same as textures, they get too blurry with full mipmapping and both are DXT5), I'm getting just over 200fps on x768 for both 512x48K_tris and the facaded 1024x15K_tris.
Hadn't occured to me previously to test the jpeg load in the normal maps.
So, I reckon that's good news all round, it really makes a difference to the 1024x normals.
04/15/2009 (3:53 pm)
* Stop Press *After changing all my nomal maps to DDS with 3 mipmaps (same as textures, they get too blurry with full mipmapping and both are DXT5), I'm getting just over 200fps on x768 for both 512x48K_tris and the facaded 1024x15K_tris.
Hadn't occured to me previously to test the jpeg load in the normal maps.
So, I reckon that's good news all round, it really makes a difference to the 1024x normals.
#14
04/15/2009 (4:36 pm)
Any reason why you decided on DXT5? You'd get better compression from DXT1 so long as your textures are Opaque
#15
04/15/2009 (4:52 pm)
To be honest it was what was selected, but also because I believe T3D will be moving the specular alpha channel to the normals alpha.
#16
04/15/2009 (5:34 pm)
I really enjoy reading your posts. The town looks (as always) very well done. 
#17
So, uhh, now there can be a sniper in every window, a shooter around every corner, or a badguy in every room?
04/15/2009 (6:08 pm)
Awesome test(s) Steve! It seems you're always just a couple of steps ahead of things I'm wanting to test myself. But then I'm sometimes slow and very easily distracted ;) Comes from working on 7 different things at once I suppose. So, uhh, now there can be a sniper in every window, a shooter around every corner, or a badguy in every room?
#18
Now a recent test using TGEA 1.8.1 on a larger DTS only on a Vcard 512meg 9500GT at 1680x945 res 1024x and 512x mix of textures performance was lower but at that res i was not surprised at an average FPS of 45/50. Also keep in mind that nothing is yet optimized.
I am still doing some tests, i have other DTS objects i want to include in the mission for testing before i lean one way or the other. but base performance is pretty good.
I am leaning more towards dts however. Performance is good, and plus i suck harsh at making DIF interiors. Never could get a grip in the UVmapping aspect of the current Dif Tools. No offence to the tools themselves, but i just got spoiled by Lightwaves superior uvmapping tools and abilities. Plus the DTS exporter is pure genius.
04/15/2009 (6:13 pm)
Well, I am not all that surprised by the results. I did some tests on this quite some time ago after integrating Polysoup/opcode into TGE 1.5.2 using the same building in DTS and DIF. All using 512x textures. FPS was high at 175+ on a Vcard 256meg 7600m GS on a res of 1440x900.Now a recent test using TGEA 1.8.1 on a larger DTS only on a Vcard 512meg 9500GT at 1680x945 res 1024x and 512x mix of textures performance was lower but at that res i was not surprised at an average FPS of 45/50. Also keep in mind that nothing is yet optimized.
I am still doing some tests, i have other DTS objects i want to include in the mission for testing before i lean one way or the other. but base performance is pretty good.
I am leaning more towards dts however. Performance is good, and plus i suck harsh at making DIF interiors. Never could get a grip in the UVmapping aspect of the current Dif Tools. No offence to the tools themselves, but i just got spoiled by Lightwaves superior uvmapping tools and abilities. Plus the DTS exporter is pure genius.
#19
also, as a side note "Thus 1024x gave a lot more of a kicking to Vram than two 512x." it takes 4x 512x512 textures to equal that of a 1024x1024 ;)
@ Roland Orr, just wondering what your using for DIF's that requires UV Mapping ? their textured on a face by face basis like old style BSP's from halflife and doom etc, no need for UV Mapping.
04/15/2009 (6:43 pm)
Hey steve, ive had a few problems with dxt5 with the dds's ive been using,the alpha channel gets alot of artifacts, the setting ive had best results with is 8.8.8.8...also, as a side note "Thus 1024x gave a lot more of a kicking to Vram than two 512x." it takes 4x 512x512 textures to equal that of a 1024x1024 ;)
@ Roland Orr, just wondering what your using for DIF's that requires UV Mapping ? their textured on a face by face basis like old style BSP's from halflife and doom etc, no need for UV Mapping.
#20
@Andy Wright, yeah I just noticed those artifacts in the dds normalmaps, they don't seem to shift regardless of what type of compression gets used.
Anyhow, I'll be having a few days off. Hull Real Ale Festival at Queens Gardens College starts tomorrow ... er ... today ... in 9 hours.
04/15/2009 (6:55 pm)
@Michael Quote:So, uhh, now there can be a sniper in every window, a shooter around every corner, or a badguy in every room?That's the idea, plus a lot more freedom of movement for the player, cutting through gardens etc. I'm toying with the idea of having random enemy spawns from each spawn_trigger, so on each play through (or restart if the player is killed and has to load the game again) the location of the enemy for that area/building group would randomize. So the player would never be entirely sure where the next enemy will pop-up from. Would make a change to the "get killed by guy behind door, load last save, know guy is behind door, get him first".
@Andy Wright, yeah I just noticed those artifacts in the dds normalmaps, they don't seem to shift regardless of what type of compression gets used.
Anyhow, I'll be having a few days off. Hull Real Ale Festival at Queens Gardens College starts tomorrow ... er ... today ... in 9 hours.
Torque 3D Owner Ted Southard