Increase Performance of my Scenery
by Tobias B. · in Torque 3D Professional · 10/26/2009 (12:21 pm) · 10 replies
Hi,
I'm presently working on a car racing scene. This includes the automatic generation of tracks including guard rails, passenger walks etc. These items may count up to many hundreds along the track and they seem to kill my performance. For the time being, each item is automatically scripted into the mission file.
The geometry of these files is very simple (mainly some boxes), but their vast number seems to be a problem: Wether the performance is decreased drastically, or the game crashes on startup.
So I see basically two options - please comment:
1) Does it make sense to use LODs in this case? I mean, the shapes itself are really simple (5-10 boxes each guard rail plus 1 box per 2m passenger walk), but I could leave out the textures for lower LOD. Does it help to simply leave out textures for lower LODs and to keep the geometry?
2) Is it possible to define the objects (one guard rail, one passenger walk) and to repeat them - just like a pointer in C++? I have always the same object and just need several hundred instances. Is there any possibility to handle that more elegant than writing several hundred copies in the mission file? That should save a lot of texture memory, right? These shape replicators for trees etc. do probably do the same, I guess... with the difference that I want to explicitly set the position of each instance.
3) Is there any chance to get a poly count for the scene presently rendered, and is thare an average maximum number of polys one should not exceed? The same question holds for texture memory...
Probably these questions are very basic - thanks anyways for hints and comments.
Best Regards,
Tobias
I'm presently working on a car racing scene. This includes the automatic generation of tracks including guard rails, passenger walks etc. These items may count up to many hundreds along the track and they seem to kill my performance. For the time being, each item is automatically scripted into the mission file.
The geometry of these files is very simple (mainly some boxes), but their vast number seems to be a problem: Wether the performance is decreased drastically, or the game crashes on startup.
So I see basically two options - please comment:
1) Does it make sense to use LODs in this case? I mean, the shapes itself are really simple (5-10 boxes each guard rail plus 1 box per 2m passenger walk), but I could leave out the textures for lower LOD. Does it help to simply leave out textures for lower LODs and to keep the geometry?
2) Is it possible to define the objects (one guard rail, one passenger walk) and to repeat them - just like a pointer in C++? I have always the same object and just need several hundred instances. Is there any possibility to handle that more elegant than writing several hundred copies in the mission file? That should save a lot of texture memory, right? These shape replicators for trees etc. do probably do the same, I guess... with the difference that I want to explicitly set the position of each instance.
3) Is there any chance to get a poly count for the scene presently rendered, and is thare an average maximum number of polys one should not exceed? The same question holds for texture memory...
Probably these questions are very basic - thanks anyways for hints and comments.
Best Regards,
Tobias
#2
Sounds like you have tons of objects that are all very cheap to render... but together they eat up alot of performance.
In general you have a limit of about 2000 draw calls per-scene before performance starts to tank. If you include the extra draw calls nessasary in Advanced Lighting... this can get out of control quickly if your not careful.
You cannot expect to build your game out of lego block like parts unless you optimize the scene or write special code. It really depends on your game how to approch it.
One is to LOD smaller elements out at a distance. So you add a second LOD which has no geometry under it and set it to appear when the object gets small on the screen. In this case the object won't be rendered saving you its processing time. Depending on your game this may be enough.
Another is to combine static objects which share the same materials into a single mesh. This is either an art issue generally, but in your case it sounds like a technical one. This will require some custom coding.
metrics( fps );
... into the console to get frame rate and general rendering stats.
Its hard to say what will work for your game... it depends on your target systems and game requirements... but in general keep an eye on the draw calls. Alot more than 2000 and your usually introuble.
10/27/2009 (5:07 am)
Quote:The geometry of these files is very simple (mainly some boxes), but their vast number seems to be a problem
Sounds like you have tons of objects that are all very cheap to render... but together they eat up alot of performance.
In general you have a limit of about 2000 draw calls per-scene before performance starts to tank. If you include the extra draw calls nessasary in Advanced Lighting... this can get out of control quickly if your not careful.
You cannot expect to build your game out of lego block like parts unless you optimize the scene or write special code. It really depends on your game how to approch it.
One is to LOD smaller elements out at a distance. So you add a second LOD which has no geometry under it and set it to appear when the object gets small on the screen. In this case the object won't be rendered saving you its processing time. Depending on your game this may be enough.
Another is to combine static objects which share the same materials into a single mesh. This is either an art issue generally, but in your case it sounds like a technical one. This will require some custom coding.
Quote:2) Is it possible to define the objects (one guard rail, one passenger walk) and to repeat themAt the moment Torque doesn't support "instancing" of meshes, but we're aiming to do so by 1.2.
Quote:3) Is there any chance to get a poly count for the scene presently renderedType...
metrics( fps );
... into the console to get frame rate and general rendering stats.
Its hard to say what will work for your game... it depends on your target systems and game requirements... but in general keep an eye on the draw calls. Alot more than 2000 and your usually introuble.
#3
It's a pain to see 75% of the CPU sleeping while I need more CPU power! Our GPUs seem to be completely bored... The main problem arises together with dynamic lights (10-15 spotlights) and shadows - these seem to computed on the CPU, not on the GPU. Can you confirm that?
@Tom: Thanks for these points! The approach of including empty LODs (if I got you right) sounds good since it allows a kind of selective viewing distance, right? Will test it immediately!
10/27/2009 (5:25 am)
@Steve: We got a Super-Powerful-Gaming-Machine using 2 x nVidia Geforce 285 in SLI Mode and an Intel Q9550 Quad-Core-CPU. The CPU seems to be the bottle neck since only one core is usable in T3D. Is there someone thinking about multi-threading the engine? ;-) It's a pain to see 75% of the CPU sleeping while I need more CPU power! Our GPUs seem to be completely bored... The main problem arises together with dynamic lights (10-15 spotlights) and shadows - these seem to computed on the CPU, not on the GPU. Can you confirm that?
@Tom: Thanks for these points! The approach of including empty LODs (if I got you right) sounds good since it allows a kind of selective viewing distance, right? Will test it immediately!
#4
10/27/2009 (6:04 am)
Yes... we are working on taking advantage of multicore systems. Its just not possible to do multicore rendering without DX11... which we hope to start working on in the next 6 months.
#5
Especially the scripting end would benefit significantly from multi core support to unleash some power. I think the best example for what this can do if really used is Supreme Commander where all game logic, ai etc is in LUA and runs on multiple cores.
10/27/2009 (6:29 am)
Even without threaded rendering, aren't there enough things that could already be done in distinct threads like scripting, scene graph / position / visibility handling + client - server connection and syncronization management etc that could be parallelized.Especially the scripting end would benefit significantly from multi core support to unleash some power. I think the best example for what this can do if really used is Supreme Commander where all game logic, ai etc is in LUA and runs on multiple cores.
#6
10/27/2009 (11:35 am)
@Tobias - that's flippin' Skynet! Keep it away from the nuclear weapons.
#7
10/27/2009 (1:07 pm)
@Steve: "Come with me if you want to live... ahm... play!"
#8
On the other hand, I have static objects like trees or buildings, but their shadows seem also to be calculated dynamically which consumes CPU power. Is that right?
Can I make them draw their shadows baked into the environment while keeping the cars with dynamic shadows?
11/05/2009 (12:51 pm)
What about shadows? I have some dynamically moving objects (cars) which need to be calculated with dynamic shadows. Thus, I'm using Advanced Lightning.On the other hand, I have static objects like trees or buildings, but their shadows seem also to be calculated dynamically which consumes CPU power. Is that right?
Can I make them draw their shadows baked into the environment while keeping the cars with dynamic shadows?
#9
So do this... enter metrics( "fps gfx" ) in the console to get frame rate and draw call counts. What is the range of draw calls you get in your typical scene?
If you then disable the Sun shadow you should see a 4x drop in draw calls and your framerate get a ton better.
11/05/2009 (3:40 pm)
@Tobias - Its all or nothing with AL shadows.So do this... enter metrics( "fps gfx" ) in the console to get frame rate and draw call counts. What is the range of draw calls you get in your typical scene?
If you then disable the Sun shadow you should see a 4x drop in draw calls and your framerate get a ton better.
#10
What about the pureLight? If I use their add-on, it should be possible to distinguish between dynamic and static shadows. I mean, it's quite uneffective to recalculate shadows every frame....
Another point: I'm handling collisions externally and I don't need any collision handling. Neither with terrain nor with any object. I guess collision checking also consumes computation time. Is there a quick hack to disable all collision checking?
11/09/2009 (5:36 am)
Tom - thanks for the hint. I'll check that.What about the pureLight? If I use their add-on, it should be possible to distinguish between dynamic and static shadows. I mean, it's quite uneffective to recalculate shadows every frame....
Another point: I'm handling collisions externally and I don't need any collision handling. Neither with terrain nor with any object. I guess collision checking also consumes computation time. Is there a quick hack to disable all collision checking?
Associate Steve Acaster
[YorkshireRifles.com]
Texture's only get loaded once, regardless of how many objects use that texture. Mipmap your textures, use DDS.
For Texture memory useage in the console type:
Performance is rather dependant on your rig. What's your GPU? Anything less than 8800 (not sure what ATI equivalent is) and you should be using Basic Lighting, or at least not have shadows on in AL.