Metrics in TSE?
by Justin Tolchin · in Torque Game Engine Advanced · 07/18/2005 (3:17 pm) · 7 replies
Hi all,
Is there any way to get useful video metrics out of TSE, the way you used to be able to get them in TGE by entering "metrics(video);" in the console? Has anybody ported any of that functionality over to TSE? I'm seeing really bad performance in my app and according to the profiler it's somewhere in the rendering, so I'd like to know how many polys it thinks it's drawing, etc.
Thanks!
Is there any way to get useful video metrics out of TSE, the way you used to be able to get them in TGE by entering "metrics(video);" in the console? Has anybody ported any of that functionality over to TSE? I'm seeing really bad performance in my app and according to the profiler it's somewhere in the rendering, so I'd like to know how many polys it thinks it's drawing, etc.
Thanks!
#2
Anyway, thanks for the tip!
07/21/2005 (2:01 pm)
Ok, thanks Brian. I downloaded nvPerfHUD and it seems to work well. Unfortunately it mostly confirmed that my app's performance problems are somewhere in the rendering code and not on the card itself, but I did learn that the amount of texture memory we're consuming is also killing performance. :-/Anyway, thanks for the tip!
#3
07/21/2005 (4:46 pm)
Texture memory can be a huge killer, and with TSE it's very easy to use gigs of the stuff. You have to exercise discipline to keep those numbers down.
#4
The thing is that nvPerfHUD is telling us we're using around 110-115 megs of video memory which seems like a lot more than we really are using. Does Torque preload texture data based on what's referenced by all the datablocks that it knows about? Or does it only get loaded in when an object gets instantiated that uses that datablock? Meaning, if I have an RTSUnit datablock called "ScoutData" that refers to "scout.dts", does Torque load up scout.dts and see what textures it uses and then load those textures into the video card memory, even if I haven't created any scouts yet?
07/21/2005 (5:04 pm)
Yeah, I know a lot of this is just inexperience. Our artists aren't sure how big to make the textures and I'm not sure how to advise them. We're making an RTS so the units are fairly small on the screen but we want to allow the user to zoom a bit, so it's hard to know how much detail is "enough". We were using 512x512 textures for all the units but that seems to be too much. We also had "mask" textures that we use to handle adding a player color to each object (using a shader) and we just realized those are also 512x512 which is totally unnecessary. The mounted weapon texture size needs to come way down too. Live and learn. :-) The thing is that nvPerfHUD is telling us we're using around 110-115 megs of video memory which seems like a lot more than we really are using. Does Torque preload texture data based on what's referenced by all the datablocks that it knows about? Or does it only get loaded in when an object gets instantiated that uses that datablock? Meaning, if I have an RTSUnit datablock called "ScoutData" that refers to "scout.dts", does Torque load up scout.dts and see what textures it uses and then load those textures into the video card memory, even if I haven't created any scouts yet?
#5
VertexBuffers, mipmaps, back- and frontbuffer are allocated in video memory too.
a 1024x768 front buffer alone eats about 3 Megs (no counting the amount of memory swallowed by the Pitch) ... then you have 1 or 2 additional Backbuffers in your chain so you get to roughly 6 to 10mb for the display only. If you use different Renderpasses then it will need Video Memory too (Water Reflection for instance).
Then you have Depthbuffer and Stencil Buffer.
If TSE doesnt use Texture Compression then each 512x512x24 Texture eats 768kb. That is without mipmaps. The Complete mipmap chain would be 512x512 + 256x256 + 128x128 +64x64 + 32x32 + 16x16 + 8x8 + 4x4 + 2x2 + 1x1 = 1MB (RGB) or 1.3MB (RGBA). Texture Compression will reduce it to 256kb.
If you have Interiors you have to consider Lightmaps which are stored in Video Ram they have lower resolution but they may have mipmap chains too and they are created uniquely for every brush of an Interior.
I think Atlas uses some Memory too. Cant tell if Atlas will Page in only the LOD of an Chunk that is actually needed or if he gets the whole chain but every vertex uses a minimum of 12 Bytes (XYZ only). If you add Vertex Normals (+12 Bytes), Vertex color (+4 Bytes) and Texture Coordinates (+8 Bytes) you have 36 kb for every Vertex that is stored in a Vertex Buffer. So for a 5000 Poly model you need about 176kb. I dont know how many Polygons Atlas will save in Video Ram (maybe ben can enlighten us there :))
Adding that i dont think that 110-115 Megs is such an unrealistic number.
As far as i can remember AGP was invented to have an additional piece of memory (in system memory) that has fast write acces to video card ram. So your 110-115 Megs should run on a 64Meg Graphicscard (it would be slower tho).
07/22/2005 (12:48 am)
There is not just Textures in Video Memory.VertexBuffers, mipmaps, back- and frontbuffer are allocated in video memory too.
a 1024x768 front buffer alone eats about 3 Megs (no counting the amount of memory swallowed by the Pitch) ... then you have 1 or 2 additional Backbuffers in your chain so you get to roughly 6 to 10mb for the display only. If you use different Renderpasses then it will need Video Memory too (Water Reflection for instance).
Then you have Depthbuffer and Stencil Buffer.
If TSE doesnt use Texture Compression then each 512x512x24 Texture eats 768kb. That is without mipmaps. The Complete mipmap chain would be 512x512 + 256x256 + 128x128 +64x64 + 32x32 + 16x16 + 8x8 + 4x4 + 2x2 + 1x1 = 1MB (RGB) or 1.3MB (RGBA). Texture Compression will reduce it to 256kb.
If you have Interiors you have to consider Lightmaps which are stored in Video Ram they have lower resolution but they may have mipmap chains too and they are created uniquely for every brush of an Interior.
I think Atlas uses some Memory too. Cant tell if Atlas will Page in only the LOD of an Chunk that is actually needed or if he gets the whole chain but every vertex uses a minimum of 12 Bytes (XYZ only). If you add Vertex Normals (+12 Bytes), Vertex color (+4 Bytes) and Texture Coordinates (+8 Bytes) you have 36 kb for every Vertex that is stored in a Vertex Buffer. So for a 5000 Poly model you need about 176kb. I dont know how many Polygons Atlas will save in Video Ram (maybe ben can enlighten us there :))
Adding that i dont think that 110-115 Megs is such an unrealistic number.
As far as i can remember AGP was invented to have an additional piece of memory (in system memory) that has fast write acces to video card ram. So your 110-115 Megs should run on a 64Meg Graphicscard (it would be slower tho).
#6
07/28/2005 (10:07 am)
Good points! Thanks, that makes a lot more sense now. I also discovered that we had an object with a 60 frame .ifl where each frame was a 512x512 texture(!). Oops. That was WAY more resolution than we needed so shrinking those down to 128x128 saved a ton of resources. We could probably go even smaller than that without any problem.
#7
Atlas all around takes between 32-64MB depending on the exact terrain and view parameters. It only pages in the LODs that are needed (both texture and geometry). Textures get a full mip chain, but they are DXT compressed.
A 60 frame IFL with a 512x512 texture eats about 96 MB, including mip chains.
07/28/2005 (10:57 am)
Thank you for the explanation, Florian! Well said.Atlas all around takes between 32-64MB depending on the exact terrain and view parameters. It only pages in the LODs that are needed (both texture and geometry). Textures get a full mip chain, but they are DXT compressed.
A 60 frame IFL with a 512x512 texture eats about 96 MB, including mip chains.
Torque Owner Brian Ramage
Black Jacket Games