Huge framerate drop when moving - LOGGED
by Chris · in Torque 3D Professional · 07/01/2010 (2:04 am) · 16 replies
Can anyone explain to me what causes the huge framerate drop when you move?
For example when I stand still I get around 120-150FPS but soon as I take a step it drops to 50fps then when I stop it goes right back up.
When other people move around on me screen this does not happen.
1.1B1
For example when I stand still I get around 120-150FPS but soon as I take a step it drops to 50fps then when I stop it goes right back up.
When other people move around on me screen this does not happen.
1.1B1
About the author
#2
07/01/2010 (3:16 am)
I had this problem once, thought it was the shadows at first, but it turns out it acctually was my not-so-clever setup of collision meshes. Try to avoid using "visible mesh" as collision. If that isn't your issue, do as Caylo said and use profiler.
#3
Don't quote me on that last one, I think that's the command but doing it from memory.
As Marcus suggested it sounds like it could be your collision meshes.
07/01/2010 (4:00 am)
Yeah Chris it's worth while using the profiler to find out exactly what is causing the issue, not sure about the key bindings Caylo mentioned but I just use the console commands:// Start profiling the game
profilerenable(1);
// stop profiling
profilerenable(0);
// display profile output to the console
profilerdump();
// save profiler output to file
profilerdumptofile("profile.txt");Don't quote me on that last one, I think that's the command but doing it from memory.
As Marcus suggested it sounds like it could be your collision meshes.
#4
07/01/2010 (4:01 am)
We have lots of collision meshes, and some visible meshes
#5
Mine looks like this: and I think that it is telling me that most of my system stress is on rendering my Ai characters and their weapons (I've 50 of these guys in-game for the test, so I guess that's fair enough)
07/01/2010 (8:17 am)
Press CTRL+F3 and hold it (without moving!) for a few seconds it'll write a profile on release which you can then find in you project/game directory.Mine looks like this: and I think that it is telling me that most of my system stress is on rendering my Ai characters and their weapons (I've 50 of these guys in-game for the test, so I guess that's fair enough)
Profiler Data Dump: Ordered by non-sub total time - %%NSTime %% Time Invoke # Name 13.184 39.069 294444 ShapeBase_PrepRenderImage 10.212 10.542 226640 TSSkinMesh_UpdateSkin 7.783 7.784 226640 TSMesh_CreateVBIB 4.385 5.923 1891866 TSMesh_InnerRender 3.409 3.409 188110 ContainerCastRayRendered 3.367 5.549 1715237 MatInstance_setTransforms 3.099 14.515 20526 RenderMeshMgr_render 2.842 2.842 1866 SwapBuffers
#6
07/01/2010 (10:21 am)
Is this movement on terrain? Statics? DIFs? Just a casual guess but I would assume something to do with collision. If not that then maybe you have some custom code that deals with player movement? The advice to use the profiler is spot on.
#7
And I am guessing it is collision or networking related myself.
07/01/2010 (10:22 am)
It is on terrain, have not really tested inside buildings.And I am guessing it is collision or networking related myself.
#8
07/01/2010 (7:00 pm)
Logged: TQA-490
#9
07/02/2010 (1:24 am)
Chris if you post your pprofiler log here or the first sections of then some of the clever code monkeys will be able to pin point more accurately exactly which bit it is.
#10
and
07/02/2010 (11:13 am)
%%NSTime %% Time Invoke # Name 25.266 37.142 54587 ContainerFindObjects_Box 11.171 11.171 22007 TSMesh_buildPolyListOpcode 10.227 16.723 146 SimAdvanceTime 6.591 7.769 46239 Player_PhysicsSection 6.514 6.514 531231 SimFindObject 6.431 10.191 146 StdClientProcessList_AdvanceTime 4.267 4.267 6263 ClippedPolyList_CullUnusedVerts 4.113 4.113 51 GFXD3D9TextureObject_lockRT 3.056 64.676 146 CanvasRenderControls 1.116 1.128 2532 TSMesh_CreateVBIB 1.102 3.603 2428 RenderMeshMgr_render 1.080 100.000 146 MainLoop 1.014 1.014 146 SwapBuffers ...snipped...
and
22.070 25.153 476 StdClientProcessList_AdvanceTime 10.500 16.882 476 SimAdvanceTime 7.853 44.677 476 CanvasRenderControls 6.404 6.404 498943 SimFindObject 5.936 7.767 38239 ContainerFindObjects_Box 5.677 6.665 34876 Player_PhysicsSection 3.123 3.123 476 SwapBuffers 2.583 100.000 476 MainLoop 1.927 2.566 79016 GFXDevice_updateStates 1.626 1.885 9996 GFXDevice_drawTextN 1.594 1.594 5997 TSMesh_buildPolyListOpcode 1.577 5.782 2380 ProjectedShadow_RenderToTexture 1.576 1.669 550 GFXTextureManager_CreateTexture_Bitmap 1.542 2.752 3332 RenderObjectMgr_render 1.505 1.561 3332 TSSkinMesh_UpdateSkin 1.490 1.490 3332 TSMesh_CreateVBIB 1.476 5.422 3808 RenderMeshMgr_render 0.964 8.691 51408 ProjectedShadow_UpdateDecal 0.899 8.097 55729 Player_ProcessTick 0.776 15.264 476 SceneGraphRender_PreRenderSignal 0.774 1.042 1105756 GenericConstBufferLayout_set 0.709 1.267 47600 TSMesh_InnerRender
#11
07/02/2010 (11:19 am)
Also54.664 0.002 146 GameRenderWorld 54.661 0.013 146 SceneGraphRender 46.966 0.405 146 SceneGraphRender_PreRenderSignal 42.457 0.614 15768 ProjectedShadow_UpdateDecal 41.752 0.374 6233 DecalManager_clipDecal 36.896 0.029 6233 DecalManager_clipDecal_buildPolyList 36.867 25.005 6233 ContainerFindObjects_Box 11.861 0.690 33906 TSShapeInstance_buildPolyListOpcode_MeshObjInst 11.171 11.171 22007 TSMesh_buildPolyListOpcode
#12
So somehow that ContainerFindObjects_Box in the decal manager is very expensive when the actor is moving
07/02/2010 (11:27 am)
This issue is resolved whenbool DecalManager::clipDecal( DecalInstance *decal, Vector<Point3F> *edgeVerts, const Point2F *clipDepth )
{
return false;So somehow that ContainerFindObjects_Box in the decal manager is very expensive when the actor is moving
#13
If you look at your expensive call:
You can see it's the projectedShadow-updateDecal calling decal manager which calles the buildPolyList, etc.
Basically what it does is look at the shadow and what it falls on, then build a list of polygons from the object it hits and the clips the shadow decal based on those polys - which is expensive to do. Manoel posted info about it recently and knows infinately more about it than me.
In the world editor you can change the DecalType on each object from "visible mesh" to "collision mesh" and it will improve your performance a lot (Assuming you have good simple collision meshes) because there should be far far fewer polys in your collision mesh than your visible meshes
07/02/2010 (2:34 pm)
I'm guessing you are you using basic lighting? It uses decals for drawing the shadows and it's really very expensive If you look at your expensive call:
04. 42.457 0.614 15768 ProjectedShadow_UpdateDecal 05. 41.752 0.374 6233 DecalManager_clipDecal 06. 36.896 0.029 6233 DecalManager_clipDecal_buildPolyList 07. 36.867 25.005 6233 ContainerFindObjects_Box
You can see it's the projectedShadow-updateDecal calling decal manager which calles the buildPolyList, etc.
Basically what it does is look at the shadow and what it falls on, then build a list of polygons from the object it hits and the clips the shadow decal based on those polys - which is expensive to do. Manoel posted info about it recently and knows infinately more about it than me.
In the world editor you can change the DecalType on each object from "visible mesh" to "collision mesh" and it will improve your performance a lot (Assuming you have good simple collision meshes) because there should be far far fewer polys in your collision mesh than your visible meshes
#14
I have an idea for an alternative B&L shadow that doesn't require polygon clipping and casts on the actual geometry: instead of clipping, just re-render the geometry the shadow is being cast on with the same material the shadow decal uses, while drawing the extruded shadow volume to the stencil buffer so only the areas that intersect it are rendered. The drawback is extra draw calls and a little more fill-rate due to the stenciling.
I also think there should be an even simpler shadow type, as an option: the good ol' blob shadow. Not using a decal, however: a simple raycast to find the blob's center would suffice.
07/03/2010 (7:51 pm)
Decals shadows are quite expensive if you cast them on detailed collision geometry. They are an extreme solution for doing shadows with as little GPU stress as possible, but the burden on the CPU can be too high on complex scenes.I have an idea for an alternative B&L shadow that doesn't require polygon clipping and casts on the actual geometry: instead of clipping, just re-render the geometry the shadow is being cast on with the same material the shadow decal uses, while drawing the extruded shadow volume to the stencil buffer so only the areas that intersect it are rendered. The drawback is extra draw calls and a little more fill-rate due to the stenciling.
I also think there should be an even simpler shadow type, as an option: the good ol' blob shadow. Not using a decal, however: a simple raycast to find the blob's center would suffice.
#15
07/04/2010 (12:00 am)
We don't even care about dynamic shadows at this point. Its not worth the frame rate drop for us
#16
It's funny that you would suggest that as I'm currently putting the finishing touches on a stencil buffer shadow implementation in tgea. It's currently working in tgea 1.7.1. I was thinking about releasing possibly as a commercial add-on for torque.
07/04/2010 (12:50 pm)
Manoel-It's funny that you would suggest that as I'm currently putting the finishing touches on a stencil buffer shadow implementation in tgea. It's currently working in tgea 1.7.1. I was thinking about releasing possibly as a commercial add-on for torque.
Torque 3D Owner Caylo Gypsyblood