Lag (GFX) and Torque3D
by Marcus L · in Torque 3D Professional · 03/20/2010 (9:07 am) · 20 replies
Ok...
So ever since i ported my game from TGEA to T3D (1.1a) i have had issues with lag. Now, since i am clueless of what causes lag and how to avoid it, I'm going asking these questions:
1. According to Spencer (#3), having multiple textures on one object causes the engine to render the model for each texture applied. Is this true?
2. Does texture size matter (I'm pretty sure it does)? And if so, how much does it matter. Like the difference between 2048 and 1024.
3. Does baking textures help reduce lag, and if so, what textures should i bake?
4. Can calling a rayCast each second cause lag. If so, how can i make a function that checks what your aiming at without causing lag.
5. Can having AIs around, doing nothing cause lag?
6. Lastly. Does anyone have an explanation of why I'm having a normal FPS inside a house when standing still, but then if i move it drops down dramatically.
Just to clarify. My PC is/was a gaming PC. I can run most modern games from Low to Medium settings (on MW 2 i had Medium settings, and no lag). PC Specs: Dell XPS m1530 | nVidia 8600m gt | 4 GB RAM | Intel Core 2 Duo CPU @ 2.50 GHz.
Thanks.
So ever since i ported my game from TGEA to T3D (1.1a) i have had issues with lag. Now, since i am clueless of what causes lag and how to avoid it, I'm going asking these questions:
1. According to Spencer (#3), having multiple textures on one object causes the engine to render the model for each texture applied. Is this true?
2. Does texture size matter (I'm pretty sure it does)? And if so, how much does it matter. Like the difference between 2048 and 1024.
3. Does baking textures help reduce lag, and if so, what textures should i bake?
4. Can calling a rayCast each second cause lag. If so, how can i make a function that checks what your aiming at without causing lag.
5. Can having AIs around, doing nothing cause lag?
6. Lastly. Does anyone have an explanation of why I'm having a normal FPS inside a house when standing still, but then if i move it drops down dramatically.
Just to clarify. My PC is/was a gaming PC. I can run most modern games from Low to Medium settings (on MW 2 i had Medium settings, and no lag). PC Specs: Dell XPS m1530 | nVidia 8600m gt | 4 GB RAM | Intel Core 2 Duo CPU @ 2.50 GHz.
Thanks.
#2
2. Texture size is a huuuuuuge issue. One of the most limiting factors for your games is the amount of VRAM that is available. The moment you run out of VRAM thing start swapping between the GPU and the HDD and it causes a pretty significant loss of performance. With the exception of DDS, any bitmap that you send to be displayed in your game exists in VRAM uncompressed (it doesnt matter that its a 30kb JPEG on the HDD, the pixel data is still uncompressed to be used in your game). Since this a long post I dont want to look up the exact numbers but doing the math quickly in my head a 1024x1024 bitmap will use up roughly around 5.3mb of VRAM, a 2048x2048 is roughly 21.5mb of VRAM. As such its easy to see why you can run out of VRAM very quickly and why most games are throwing more polygons at a problem now than relying on per-pixel bitmap effects.
3. By baked textures I assume you mean baked lighting, aka lightmaps? If so then yes. Baked lighting will take up signficantly less VRAM than using dynamic shadow casting lights. However baked lighting is static and doesn't change. Most AAA games (ie. everything done with Unreal and many otherse) will use a combination of baked lightmaps and a few dynamic lights in combination to get the best of both worlds.
4. Dunno Im just an artist. With that said its likely dependent upon how many calls you are making, one or two likely won't be too bad, but doing a lot could be problematic.
5. Speaking as an artist, yes I would imagine it will likely cause some performance degredation since the system is still calculating what the AI should do
6. One of the biggest reason why I have seen a big degredation on FPS in Torque3D is because you are in Basic Lighting mode. The decal system used in BL is much more crude than in AL. Because of this when shadows need to be cast from the player model onto a surface its using a brute force polysoup method to create the decal plane for the player shadow. Swithing to AL would be an instant fix to the problem if this was the case and something you could check right away. If it is the problem then you need to decide if you need to use BL and if so use some creative work arounds in these cases. If not, then provide more information about your scene such as draw-calls, triangle count, vram usage, etc. that will help give more information about what is going on in the scene.
03/20/2010 (9:39 am)
1. This would be correct, as this would result in the requirement of another draw call for the object for each different texture. Lets say you have one texture for skin and one for the armor, that's 2 draw calls instead of 1 if the two were combined on the same texture. The reason for this is that you really can only have 1 base texture per sub-mesh, so when you need to use two, like in the example of skin and armor, what looks to be one single mesh in your 3D app is actually broken into 2 sub-meshes in the game engine. With that said its very common to have multiple sub-meshes per character model so its not a huge issue unless you go execessive (like double digits) and even then its not as much as an issue in comparison to the other objects that make up your scene.2. Texture size is a huuuuuuge issue. One of the most limiting factors for your games is the amount of VRAM that is available. The moment you run out of VRAM thing start swapping between the GPU and the HDD and it causes a pretty significant loss of performance. With the exception of DDS, any bitmap that you send to be displayed in your game exists in VRAM uncompressed (it doesnt matter that its a 30kb JPEG on the HDD, the pixel data is still uncompressed to be used in your game). Since this a long post I dont want to look up the exact numbers but doing the math quickly in my head a 1024x1024 bitmap will use up roughly around 5.3mb of VRAM, a 2048x2048 is roughly 21.5mb of VRAM. As such its easy to see why you can run out of VRAM very quickly and why most games are throwing more polygons at a problem now than relying on per-pixel bitmap effects.
3. By baked textures I assume you mean baked lighting, aka lightmaps? If so then yes. Baked lighting will take up signficantly less VRAM than using dynamic shadow casting lights. However baked lighting is static and doesn't change. Most AAA games (ie. everything done with Unreal and many otherse) will use a combination of baked lightmaps and a few dynamic lights in combination to get the best of both worlds.
4. Dunno Im just an artist. With that said its likely dependent upon how many calls you are making, one or two likely won't be too bad, but doing a lot could be problematic.
5. Speaking as an artist, yes I would imagine it will likely cause some performance degredation since the system is still calculating what the AI should do
6. One of the biggest reason why I have seen a big degredation on FPS in Torque3D is because you are in Basic Lighting mode. The decal system used in BL is much more crude than in AL. Because of this when shadows need to be cast from the player model onto a surface its using a brute force polysoup method to create the decal plane for the player shadow. Swithing to AL would be an instant fix to the problem if this was the case and something you could check right away. If it is the problem then you need to decide if you need to use BL and if so use some creative work arounds in these cases. If not, then provide more information about your scene such as draw-calls, triangle count, vram usage, etc. that will help give more information about what is going on in the scene.
#3
Thanks for the info. This explains alot.
Just one question for you steve (if you read this). In your videos on youTube where do you use light maps? everywhere (cuz is seems to be running really smooth)?
03/20/2010 (2:08 pm)
@ steve & loganThanks for the info. This explains alot.
Just one question for you steve (if you read this). In your videos on youTube where do you use light maps? everywhere (cuz is seems to be running really smooth)?
#4
Yeah, EVERYTHING you see in that video is lightmapped - there's no lights at all (hence why there is no spec or normal maps). That's what it looks like in Basic Lighting.
Also my lightmaps are very low quality - I was more after lighting colour effects than hardened geometry fake shadows, that's 2 miles of corridor taking up 82 megs of texture memory (the vast majority are 512 size)... I'm going to edit it all eventually in order to cut down on some drawcalls. I'm also using T3D zoning and portals (just to split the rendering into 3-4 big sections).
03/20/2010 (2:49 pm)
@MarcusYeah, EVERYTHING you see in that video is lightmapped - there's no lights at all (hence why there is no spec or normal maps). That's what it looks like in Basic Lighting.
Also my lightmaps are very low quality - I was more after lighting colour effects than hardened geometry fake shadows, that's 2 miles of corridor taking up 82 megs of texture memory (the vast majority are 512 size)... I'm going to edit it all eventually in order to cut down on some drawcalls. I'm also using T3D zoning and portals (just to split the rendering into 3-4 big sections).
#5
Lag commonly for games is related to high latency on the networking or strong fluctuations of the same causing problems with the object updates and interpolation.
03/20/2010 (3:27 pm)
One thing that potentially would help to prevent confusion for future searchers: What you are seeing and talking about is not lag but framerate problems / stutter.Lag commonly for games is related to high latency on the networking or strong fluctuations of the same causing problems with the object updates and interpolation.
#7
Does that means, if I have sub meshes Head and Torso with 1 textures per sub mesh, I will need twice the time to render it than the same "global" mesh with no sub mesh and 1 global textures?
What about layer, does having multiple layer impact a lot the rendering process? or does the texture layer are "merged" before the rendering process?
Thanks,
03/21/2010 (2:04 am)
I'm sure to understand the 2 textures per mesh.Does that means, if I have sub meshes Head and Torso with 1 textures per sub mesh, I will need twice the time to render it than the same "global" mesh with no sub mesh and 1 global textures?
What about layer, does having multiple layer impact a lot the rendering process? or does the texture layer are "merged" before the rendering process?
Thanks,
#8
{edit} It looks like a new layer does cause a new draw. After a quick test I realised I was looking at the wrong polycount/drawcall info - doh!
Having multiple meshes visible (hidden meshes don't draw) each mesh has to be drawn seperately --- because they are seperate objects.
If you have 2 meshes using the same texture, that's double the drawcalls.
2 mesh + 1 texture = 2 draw 1xVRAM
2 mesh + 2 texture = 4 draw 2xVRAM
1 mesh + 1 texture = 1 draw 1xVRAM
1 mesh + 2 texture = 2 draw 1xVRAM
That's a bit of a simplistic example to be honest, but you get the idea.
Remember:
Once you have a texture in VRAM (existing in the level) it gets copied everytime it occurs --- so if you have 50 models with the same texture ...
50 mesh + 1 texture = 50 draw 1xVRAM
You still only use VRAM once
03/21/2010 (8:25 am)
Quote:
does having multiple layer impact a lot the rendering process?
{edit} It looks like a new layer does cause a new draw. After a quick test I realised I was looking at the wrong polycount/drawcall info - doh!
Having multiple meshes visible (hidden meshes don't draw) each mesh has to be drawn seperately --- because they are seperate objects.
If you have 2 meshes using the same texture, that's double the drawcalls.
2 mesh + 1 texture = 2 draw 1xVRAM
2 mesh + 2 texture = 4 draw 2xVRAM
1 mesh + 1 texture = 1 draw 1xVRAM
1 mesh + 2 texture = 2 draw 1xVRAM
That's a bit of a simplistic example to be honest, but you get the idea.
Remember:
Once you have a texture in VRAM (existing in the level) it gets copied everytime it occurs --- so if you have 50 models with the same texture ...
50 mesh + 1 texture = 50 draw 1xVRAM
You still only use VRAM once
#9
So if I'm going to make a city with some buildings using the same texture, are you saying that i should make the city in one mesh?
03/21/2010 (8:32 am)
Quote:If you have 2 meshes using the same texture, that's double the drawcalls.
So if I'm going to make a city with some buildings using the same texture, are you saying that i should make the city in one mesh?
#10
Best bet, make your city as one object - see how it fairs in-game. If it's bad, go back and split-it up into areas/buildings in your modeling app and then LOD them.
That video I posted showing off the lightmaps in the level is made of 121 main sections. I'll probably thin that down and merge a few in the future to save on a few drawcalls - aswell as merge a few textures together for the same effect.
{edit} In total I have 201 objects in scene. But I don't have it all lit at once, I have triggers that turn lights off if players aren't in an area, and I have multiple zones and portals. The worst it gets is around 300k+ polys and 1300+ drawcalls (without players/AI running around).
03/21/2010 (8:46 am)
If you can ... it depends on how detailed it is. If you can LOD areas down it'll help in the distance if it's very high detail. If it's lower detail you might be able to get away with one object and ignore LODs. If you are standing in one object you're never away from it = hence no need for LODs. You still probably have to have multiple meshes to avoid mesh truncating on export.Best bet, make your city as one object - see how it fairs in-game. If it's bad, go back and split-it up into areas/buildings in your modeling app and then LOD them.
That video I posted showing off the lightmaps in the level is made of 121 main sections. I'll probably thin that down and merge a few in the future to save on a few drawcalls - aswell as merge a few textures together for the same effect.
{edit} In total I have 201 objects in scene. But I don't have it all lit at once, I have triggers that turn lights off if players aren't in an area, and I have multiple zones and portals. The worst it gets is around 300k+ polys and 1300+ drawcalls (without players/AI running around).
#11
I did a microcosm of a test, using a single object. Poly and Draw is high as it's taking in the whole scene.
4xMesh 2xTex Poly=93184 Draw=275
2xMesh 2xTex Poly=93184 Draw=263 (as expected)
1xMesh 2xTex Poly=93164 Draw=263 ?
I'd have actually expected the polycount to rise on the last one but it went down ....
03/21/2010 (9:53 am)
Just to pour oil into the water ....I did a microcosm of a test, using a single object. Poly and Draw is high as it's taking in the whole scene.
4xMesh 2xTex Poly=93184 Draw=275
2xMesh 2xTex Poly=93184 Draw=263 (as expected)
1xMesh 2xTex Poly=93164 Draw=263 ?
I'd have actually expected the polycount to rise on the last one but it went down ....
#12
T3D do not use batch rendering?
I thought this was an advanced game engine.
03/21/2010 (12:08 pm)
Wait... T3D do not use batch rendering?
I thought this was an advanced game engine.
#13
03/21/2010 (4:02 pm)
AL pretty much has to do a pass on just about everything in a certain radius of the player even if it is out of LOS. We have been working in quite a few configuration options to adjust the AL distance/texture size/etc and have gotten a greatly increased performance metric out of it without losing too much of the environment. A bit more aggressive culling of the shadow pass on certain objects I think would help greatly in the stock engine. 
#14
So you're still running on the same hardware...presumably you haven't drastically increased the content, polygon count, and/or texture resolution (although you did mention an increase from 1024^2 to 2048^2 on texture size).
Was this performing better on the "inferior" TGEA?
That's the part of this thread that doesn't quite compute for me.
04/09/2010 (12:07 pm)
The piece of this question that bothers me is that all this began occurring when you went from TGEA to T3D. Is that correct?So you're still running on the same hardware...presumably you haven't drastically increased the content, polygon count, and/or texture resolution (although you did mention an increase from 1024^2 to 2048^2 on texture size).
Was this performing better on the "inferior" TGEA?
That's the part of this thread that doesn't quite compute for me.
#16
As my ignorance in understanding expressed in a very simplistic manor, would not each texture require a one render call? So if I have 100 mesh objects who have 3 textures each, they render all of the 100 mesh in 3 draw calls (Not each of the 100 mesh render in 3 draw calls each)?
And as Ron Barbosa ask above; Why do T3D require so much extra hardware horsepower to render the similar scene that TGA spit out with ease (excluding T3D shadow rendering overhead)?
04/09/2010 (5:09 pm)
In what way is T3D batching? As my ignorance in understanding expressed in a very simplistic manor, would not each texture require a one render call? So if I have 100 mesh objects who have 3 textures each, they render all of the 100 mesh in 3 draw calls (Not each of the 100 mesh render in 3 draw calls each)?
And as Ron Barbosa ask above; Why do T3D require so much extra hardware horsepower to render the similar scene that TGA spit out with ease (excluding T3D shadow rendering overhead)?
#17
I have loaded levels up with upwards of 2000 animated trees and 5k billboard particles with advanced lighting and gotten the limits of the engine on my machine. Roughly 16 million polygons and 11k draw calls are the max my poor system can keep above 5 fps, But wow does it look FABULOUS! I'm still working on finding that magic sweet spot for looks vs performance. I believe that even though the tree meshes are using the same textures having to render all of the shadow maps makes it a moot point possibly?
04/09/2010 (6:26 pm)
I've certainly not seen any indication of savings by using a single mesh rendered multiple times.I have loaded levels up with upwards of 2000 animated trees and 5k billboard particles with advanced lighting and gotten the limits of the engine on my machine. Roughly 16 million polygons and 11k draw calls are the max my poor system can keep above 5 fps, But wow does it look FABULOUS! I'm still working on finding that magic sweet spot for looks vs performance. I believe that even though the tree meshes are using the same textures having to render all of the shadow maps makes it a moot point possibly?
#18
I am sure that one of them could spare 5 minutes to write a decent reply..right ?
Afterall, I think that the reply may make a great piece for the documentation. (hint hint)
04/09/2010 (8:32 pm)
It would be great if a T3D developer could provide specific notes on these topics instead of having us guess and assume and test.I am sure that one of them could spare 5 minutes to write a decent reply..right ?
Afterall, I think that the reply may make a great piece for the documentation. (hint hint)
#19
Well, i don't think i experienced this in the beginning. It might have been my fault for why its lagging now. But my frames did drop quiet a lot after porting to T3D. In any map. But i believe that has something to do with more advanced graphics and such.
Just did a test. Ported an empty map form TGEA to T3D and the frames dropped shockingly much. In T3D i had around 70fps, while in TGEA i had 235fps. wtf? why is that?
04/10/2010 (6:48 am)
Quote:14#: The piece of this question that bothers me is that all this began occurring when you went from TGEA to T3D. Is that correct?
Well, i don't think i experienced this in the beginning. It might have been my fault for why its lagging now. But my frames did drop quiet a lot after porting to T3D. In any map. But i believe that has something to do with more advanced graphics and such.
Just did a test. Ported an empty map form TGEA to T3D and the frames dropped shockingly much. In T3D i had around 70fps, while in TGEA i had 235fps. wtf? why is that?
#20
Its like complaining that the frame rate in Doom is faster than Crysis therefore Crysis must be broken in some way.
When comparing TGEA to T3D performance the *only* valid comparison is in Basic Lighting mode.
04/10/2010 (10:56 am)
There is nothing shocking that the static lighting and shadows in TGEA being faster than the dynamic lighting and shaodws in Torque 3D.Its like complaining that the frame rate in Doom is faster than Crysis therefore Crysis must be broken in some way.
When comparing TGEA to T3D performance the *only* valid comparison is in Basic Lighting mode.
Associate Steve Acaster
[YorkshireRifles.com]
2. Yes. 2048 is 4x bigger than 1024. (take next bit with a pinch of salt I'm not certain of it all) Textures all have to go into memory on your GPU. So if you have a 256mb card, 1x2048 texture is using nearly 1 percent of your available rendering memory on it's own. And you've got to render everything in scene with that GPU memory ... or it'll defer to the CPU which is having to run the game too and it's gonna be slow.
3. Baking textures as in baking shadows/lightmaps? Yes, but if you're using dynamic shadowing over them then it'll still be calculating that (eg: universal sun shadows + lightmaps = still universal shadows)
4. Yes, your CPU is having to do the calculations, and longer distances cause more calculation. Having just "one" thing do this might not be so bad, but lots of things will lag.
5. AI still has to render visually, also they still have to do their think routines. AI like players and all "animated skinned meshes" are resource greedy and should be LODed harshly - you can lose tonnes of geometry over a short distance without it looking poppy. In general, LOD everything harshly!!! Also reduce textures/shaders with distance --- and bones/nodes.
6. When you move, things have to update on screen.
If you haven't already, increase packetrate and size - try 32 and 450 (I use 32/900) Online increases can cause issues if people are using a dialup or slow connection. 10/200 default is for default so it will never fail, but it limits how fast stuff can send info around --- hence lag.
-----------------
Your specs are really limited by the 8600m -- m is never as good as not m, and the difference between the 86 and 88 is huge. Dynamic shadows are likely to be killing you (and LODs if you haven't done them - check drawcalls and polycount in metrics)
CoD doesn't use full defered rendering (Crysis does - T3D gives me better performance than that - with a GTS250). CoD uses dynamic shadowing only in places, for certain static lights, to illuminate a small area - everything is lightmapped with stencilled dynamic shadows.
Personally, because I use lightmaps, I've also modded the lighting settings so that "low" is still Advanced Lighting but has no dynamic shadows. Performance is great, and gives lower end systems the chance to use Advanced Lighting Niceness (spec, normal maps etc) just without the dynamic shadows.
Example busy scene in my game:
Advanced Lighting with Shadows == 2300 drawcalls 57fps
Advanced Lighting NO Shadows == 563 drawcalls 169fps
Spot the difference! All that geometry drawing shadows is real expensive (and it's a crowded scene)
And in Basic Lighting it's 263 drawcalls with 230fps.