Game Development Community

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

#1
07/01/2010 (2:12 am)
Sounds like a good place to use the profiler. If i remember correctly it is keybind to ctrl f3.
#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
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
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
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
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)
Also

54.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
07/02/2010 (11:27 am)
This issue is resolved when

bool 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
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
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
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.