Terrible performance rendering terrain horizon
by Justin Tolchin · in Torque Game Engine Advanced · 04/04/2005 (2:18 pm) · 22 replies
Hi all,
I've started porting my RTS app over to TSE and I was getting the following error:
AssertFatal(smWaterMark + allocSize <= smHighWaterMark, "Error alloc too large, increase frame size!");
According to this post:
www.garagegames.com/mg/forums/result.thread.php?qt=20923
it happens when the engine tries to render too much terrain. The game comes up fine at first because the initial view angle causes only a fairly small amount of terrain to be in view, but when I tred to tilt the camera up to see the horizon, I would get that error.
At Ben's suggestion I increased the max alloc size from 3 megs to 9 megs (in various increments) and now I can get the terrain to render with any view angle, but when the horizon & sky is in view the rendering slows down to a crawl (maybe one frame a second).
I'm still using the same frenzy.mis and frenzy.ter files that I was using with the stock RTS stuff except I'm using a flat heightmap and the squareSize is set to 8 instead of 5. The "visibleDistance" parameter in the Sky object is set to 600, in case that matters.
I ran a profile (my first one so I hope I did it right) and this is the result. It doesn't mean anything to me but maybe somebody out there can tell me what it's trying to say:
I've started porting my RTS app over to TSE and I was getting the following error:
AssertFatal(smWaterMark + allocSize <= smHighWaterMark, "Error alloc too large, increase frame size!");
According to this post:
www.garagegames.com/mg/forums/result.thread.php?qt=20923
it happens when the engine tries to render too much terrain. The game comes up fine at first because the initial view angle causes only a fairly small amount of terrain to be in view, but when I tred to tilt the camera up to see the horizon, I would get that error.
At Ben's suggestion I increased the max alloc size from 3 megs to 9 megs (in various increments) and now I can get the terrain to render with any view angle, but when the horizon & sky is in view the rendering slows down to a crawl (maybe one frame a second).
I'm still using the same frenzy.mis and frenzy.ter files that I was using with the stock RTS stuff except I'm using a flat heightmap and the squareSize is set to 8 instead of 5. The "visibleDistance" parameter in the Sky object is set to 600, in case that matters.
I ran a profile (my first one so I hope I did it right) and this is the result. It doesn't mean anything to me but maybe somebody out there can tell me what it's trying to say:
#2
04/04/2005 (5:50 pm)
Holy crap, 43% of your time in the DIP? Looks like your video card is unhappy with the data. Try turning down your viewing distance to 200-300.
#3
04/04/2005 (8:23 pm)
Oh, it's a port? Hmm... Might be you've messed something up somewhere in the process! What does your hierarchical profiler dump look like?
#4
I'll try turning down the view distance and see what happens.
Here's the remainder of the profile dump that I didn't post yesterday (I didn't want to clog up the post if if wasn't necessary). I assume this is what you were referring to.
04/05/2005 (11:35 am)
Well I could definitely have messed up somewhere in the port. There was a bunch of code that I was trying to port over to do the RTS unit selection circle rendering and the minimap stuff. I eventually gave up on it (hopefully someone far wiser than I wll come along soon and figure out how to port that stuff), but I might still be calling some of that code so I'll take a look. But I seem to recall this was happening even before I started trying to port the code over.I'll try turning down the view distance and see what happens.
Here's the remainder of the profile dump that I didn't post yesterday (I didn't want to clog up the post if if wasn't necessary). I assume this is what you were referring to.
Ordered by non-sub total time - %%NSTime %% Time Invoke # Name 11.257 -88.743 0 ROOT 100.000 0.335 73 MainLoop 99.658 0.011 73 ProcessTimeEvent 97.453 0.002 73 RenderFrame 97.319 1.597 73 CanvasRenderControls 95.683 0.014 73 SceneGraphRender 95.346 0.762 73 TraverseScene 94.582 0.242 5548 SceneStateRenderImage 91.645 0.012 73 TerrainRender 85.240 0.036 73 TerrainRenderEmit 84.202 2.582 15549 TerrainRenderStep 52.731 1.715 1389190 Terrain_batchEnd 42.333 42.264 5548 TRender_DIP 0.069 0.069 16425 MemoryFree 7.320 1.353 5548 Terrain_bufferCopy 3.119 3.119 5548 Terrain_bufferCopy_lockV 2.745 2.745 5548 Terrain_bufferCopy_lockP 0.058 0.058 5548 Terrain_bufferCopy_unlockP 0.045 0.045 5548 Terrain_bufferCopy_unlockV 1.290 1.290 1389190 Terrain_TexGen 0.073 0.073 16644 MemoryAlloc 28.889 1.812 1389190 TerrainRenderStepChunk 27.077 2.255 1389190 TerrainRender_renderChunkNormal 20.799 5.809 1389190 TR_chunkFormer 4.139 4.139 1389190 TR_center 4.116 2.496 1389190 TR_e2fix 1.621 1.621 1389190 TR_fixEdge 3.133 1.932 1389190 TR_e3fix 1.201 1.201 1389190 TR_fixEdge 2.241 2.241 1389190 TR_corners 0.703 0.693 1389190 TR_e0fix 0.010 0.010 15987 TR_fixEdge 0.658 0.650 1389190 TR_e1fix 0.009 0.009 11461 TR_fixEdge 4.023 1.436 1389190 TR_chunkLatter 1.132 1.132 1316190 TR_subDivLvl1Plus 1.045 1.045 46063 TR_levelMinusOne 0.410 0.410 26937 TR_subDivLvl0 0.967 0.002 73 Terrain_batchEnd
#5
04/05/2005 (11:36 am)
0.811 0.809 73 TRender_DIP 0.001 0.001 219 MemoryFree 0.153 0.019 73 Terrain_bufferCopy 0.084 0.084 73 Terrain_bufferCopy_lockP 0.048 0.048 73 Terrain_bufferCopy_lockV 0.001 0.001 73 Terrain_bufferCopy_unlockP 0.001 0.001 73 Terrain_bufferCopy_unlockV 0.001 0.001 219 MemoryAlloc 0.033 0.033 15622 TerrTexture_getNextFrameTex 0.002 0.002 73 AllocatedTexture_trimFreeList 6.387 6.174 73 TerrainRenderRecurse 0.177 0.177 269735 TerrainRender_testSquareVisibility 0.036 0.036 15549 AllocatedTexture_alloc 0.006 0.006 73 TerrainRenderSetup 0.001 0.001 73 TerrainRender_buildClippingPlanes 2.605 2.564 5402 TSShapeInstanceRender 0.020 0.020 12994 MemoryAlloc 0.017 0.017 13213 MemoryFree 0.003 0.003 5402 TSShapeInstanceMaterials 0.002 0.002 5402 TSShapeInstanceRenderBillboards 0.090 0.088 73 SkyRender 0.001 0.001 803 MemoryAlloc 0.001 0.001 803 MemoryFree 0.000 0.000 146 MemoryFree 0.000 0.000 73 MemoryAlloc 0.001 0.001 219 MemoryAlloc 0.001 0.001 219 MemoryFree 0.163 0.163 73 BuildFogTexture 0.147 0.118 73 BuildSceneTree 0.018 0.018 657 ContainerCastRay 0.010 0.010 5767 MemoryAlloc 0.002 0.001 219 MemoryRealloc 0.001 0.001 217 MemoryAlloc 0.000 0.000 217 MemoryFree 0.000 0.000 73 MemoryFree 0.010 0.010 6351 MemoryFree 0.002 0.002 657 MemoryAlloc 0.015 0.015 9064 MemoryAlloc 0.015 0.015 73 GFXBeginScene 0.010 0.010 8991 MemoryFree 0.118 0.118 73 SwapBuffers 0.013 0.013 73 CanvasPreRender 0.001 0.001 73 GFXEndScene 1.067 0.001 73 ServerProcess 1.066 0.006 73 AdvanceServerTime 1.060 0.107 453 AdvanceObjects 0.953 0.645 5889 RTSUnit_Physics 0.102 0.054 5889 RTSUnit_Misc 0.049 0.049 5889 UpdateActionThread 0.102 0.102 5889 RTSUnit_UpdatePos 0.041 0.041 29445 MemoryAlloc 0.032 0.032 29445 MemoryFree 0.024 0.024 5889 RTSUnit_Z 0.005 0.005 5889 RTSUnit_Move 0.756 0.013 73 ClientProcess 0.741 0.032 73 AdvanceClientTime 0.706 0.072 453 AdvanceObjects 0.633 0.543 5889 RTSUnit_Physics 0.033 0.033 29445 MemoryAlloc 0.029 0.029 29445 MemoryFree 0.020 0.020 5889 RTSUnit_Z 0.006 0.006 5889 RTSUnit_Move 0.003 0.003 5889 RTSUnit_UpdatePos 0.001 0.001 453 MemoryAlloc 0.003 0.003 949 UpdateActionThread 0.001 0.001 73 ContainerCastRay 0.305 0.014 73 ServerNetProcess
#6
04/05/2005 (11:36 am)
0.289 0.289 73 RTS_CAMERA_SCOPE_QUERY 0.000 0.000 73 MemoryAlloc 0.000 0.000 73 MemoryFree 0.001 0.001 526 MemoryFree 0.000 0.000 73 MemoryAlloc 0.040 0.036 73 SimAdvanceTime 0.002 0.002 1160 MemoryAlloc 0.002 0.002 1160 MemoryFree 0.027 0.023 73 ClientNetProcess 0.002 0.002 526 MemoryAlloc 0.002 0.002 526 MemoryFree 0.007 0.007 85 ProcessInputEvent 0.000 0.000 20 MemoryAlloc 0.000 0.000 20 MemoryFree 0.000 0.000 1 MemoryFree
#7
I did have some changes to the terrRender.cpp/.h code so I reverted to the HEAD version, and removed the terrSelection.cc code (RTS-specific stuff) from the build, but it doesn't seem to be making any difference. The minimap code isn't even being called so I know that's not causing a problem. I ran the profiler again and the TRender_DIP stuff is still taking over 37% of the time. I also noticed that TSShapeInstanceRender is now up to 10% which seems like a big increase from the previous run but I don't know if that means anything.
Any thoughts?
@Ben: P.S. regarding your comment in the "original" thread... the terrain heightmap I'm using isn't actually totally flat (I lied :-) )... it's flat except for a raised edge all the way around so I can see where the terrain block ends. When I tilt the view up I can see the edge. Also I never mentioned my hardware: I'm using a GeForce FX 5900.
04/05/2005 (12:15 pm)
Well I bumped the view distance down to 300 but it isn't making any apparent difference in frame rate. :-(I did have some changes to the terrRender.cpp/.h code so I reverted to the HEAD version, and removed the terrSelection.cc code (RTS-specific stuff) from the build, but it doesn't seem to be making any difference. The minimap code isn't even being called so I know that's not causing a problem. I ran the profiler again and the TRender_DIP stuff is still taking over 37% of the time. I also noticed that TSShapeInstanceRender is now up to 10% which seems like a big increase from the previous run but I don't know if that means anything.
Any thoughts?
@Ben: P.S. regarding your comment in the "original" thread... the terrain heightmap I'm using isn't actually totally flat (I lied :-) )... it's flat except for a raised edge all the way around so I can see where the terrain block ends. When I tilt the view up I can see the edge. Also I never mentioned my hardware: I'm using a GeForce FX 5900.
#8
04/06/2005 (11:43 am)
I don't know what's going on here but it looks like the terrain code is rendering FAR in excess of what it ought to be... I would suggest reverting the entire terrain directory and seeing if that fixes things.
#9
The only other weird thing I'm seeing is that I have a few .dts objects which show up fine when using the stock TSE with the "-mod show" option, but when I try to use my modified TSE build like this:
tse_debug.exe -game -mod show
it asserts when I try to load the .dts:
"Trying to call drawPrimitive with no current primitive buffer, call setPrimitiveBuffer()"
It will load up other .dts objects fine, and I'm not sure what the difference is between them. Does anyone know why this would happen? I know it seems like a totally separate issue but I'm wondering if they're possibly related somehow. I do know that this second problem is definitely caused by using the "-game" option because if I take that out the objects render fine in the Show tool whether I'm using the stock TSE or my modified build (by "modified" I mean the changes I needed for the RTS stuff).
04/11/2005 (6:13 pm)
Ok, I've now reverted the terrain directory to the CVS version (the new one with the water block demo in it) and I'm still seeing the exact same behavior. :-( I diffed the terrain folders and they are identical so it must be somewhere else.The only other weird thing I'm seeing is that I have a few .dts objects which show up fine when using the stock TSE with the "-mod show" option, but when I try to use my modified TSE build like this:
tse_debug.exe -game
it asserts when I try to load the .dts:
"Trying to call drawPrimitive with no current primitive buffer, call setPrimitiveBuffer()"
It will load up other .dts objects fine, and I'm not sure what the difference is between them. Does anyone know why this would happen? I know it seems like a totally separate issue but I'm wondering if they're possibly related somehow. I do know that this second problem is definitely caused by using the "-game
#10
04/12/2005 (11:53 pm)
I'd start reverting stuff back subdir by subdir till I got the problem to go away, then diffing the changed subdir against the original to see what was wrong. Sounds like something is deeply hosed... 
#11
I later added the terrain back, and got the same behaviour again. Then I removed the fog, and the problem got less extreme. Maybe that's something you've ran into on your port? Try fiddling with the fog?
Just a guess.
04/13/2005 (6:00 pm)
Justin, have you tried to start TSE normally without any changes whatsoever, go outside the orc test demo and look at the horizon? With our FX5200 computer here, I got very low framerates (like 1-3) and lockups. This never gone away, except for when the terrain was removed.I later added the terrain back, and got the same behaviour again. Then I removed the fog, and the problem got less extreme. Maybe that's something you've ran into on your port? Try fiddling with the fog?
Just a guess.
#12
04/13/2005 (7:47 pm)
Stefan - you're saying you get the same issue with a stock build of Torque Shader Engine?
#13
@Ben: yep, that's my current plan (reverting all the folders one by one), I just haven't had time to do it yet. I'll let you know what I discover. Thanks!
04/14/2005 (10:39 am)
@Stefan: using a stock build of TSE in the "outdoors" part of the demo I get around 7-10 fps with a debug build and 50-100 fps using a release build. The framerate goes up quickly when I'm higher up I am in the scene, presumably because of the way the fog quickly limits the draw distance, so I will play around with the fog values in my game and see what happens. But the visibleDistance/fogDistance values in the demo are 800/500 and in my game they're currently set to 300/300 so I don't think that's the problem.@Ben: yep, that's my current plan (reverting all the folders one by one), I just haven't had time to do it yet. I'll let you know what I discover. Thanks!
#14
I did some playing around and noted a couple of things, however, it's definitely the terrain that's the issue somehow. If you start the orcbase stock TSE demo and go into the editor and change the terrain size from it's current 8 to something way higher, you get all your performance back.
Also, removing that water block helps a little too - you can't see it from just using the scene-change buttons in the demo anyway.
I think this issue could potentially hurt a lot of people looking at this demo, however, it sounds like it's not very noticeable in release mode versus debug mode, although I haven't tried that myself.
Thanks -- Tim.
04/15/2005 (4:58 am)
@Ben - this is the problem I was talking about in my recent post in the bugs forum. I get a huge stuttering slowdown whenever I'm going from the inside to the outside of the orcbase and when I'm outside and ONLY looking in that same direction. If I look anywhere else, performance is fine.I did some playing around and noted a couple of things, however, it's definitely the terrain that's the issue somehow. If you start the orcbase stock TSE demo and go into the editor and change the terrain size from it's current 8 to something way higher, you get all your performance back.
Also, removing that water block helps a little too - you can't see it from just using the scene-change buttons in the demo anyway.
I think this issue could potentially hurt a lot of people looking at this demo, however, it sounds like it's not very noticeable in release mode versus debug mode, although I haven't tried that myself.
Thanks -- Tim.
#15
You have latest drivers, at least a min spec GPU, etc?wd
04/15/2005 (1:54 pm)
Are you observing this problem in release, or debug, builds of Torque? If the latter, it's to be expected - there's a lot of extra validation that occurs in debug, which tends to slow CPU intensive things like the "old" terrain down. If the former, then we've got a real problem on our hands...You have latest drivers, at least a min spec GPU, etc?wd
#16
It was only like this on the FX5200, then I switched GPU and the problem was never to be seen again.
I tried both with debug builds and release builds. There was also a few other minor problems which I've put into the TSE Manager, but these also went away with the GPU-change.
04/15/2005 (3:10 pm)
Yes Ben, I'm saying it worked that way but NOT with the latest CVS. When testing, it was 2 months ago.It was only like this on the FX5200, then I switched GPU and the problem was never to be seen again.
I tried both with debug builds and release builds. There was also a few other minor problems which I've put into the TSE Manager, but these also went away with the GPU-change.
#17
04/15/2005 (3:44 pm)
TSE Manager?
#18
With debug build fps is between 24 and 90 apart from at the end when looking at the orc base - drops to 4 fps. There is also a really bad stutter going inside to outside.
Card is an NVidea 6600GT with the latest drivers.
btw ... release with the water demo - 90 to 180 fps @ 800 x 600 and looks stunning.
04/22/2005 (9:35 am)
On a fresh release build I am getting 6 fps (yes that is six) whenever the doorway to outside is in view and when outside looking in the direction of the orc base. It also occurs when coming down the corridor back to the 'orc' room andwhilst moving the camera about in the room. Everywhere else the fps is around 120 to 150 @ 800 600. With debug build fps is between 24 and 90 apart from at the end when looking at the orc base - drops to 4 fps. There is also a really bad stutter going inside to outside.
Card is an NVidea 6600GT with the latest drivers.
btw ... release with the water demo - 90 to 180 fps @ 800 x 600 and looks stunning.
#19
Yes the TSE Project Manager that is up on this site. I do not have the link though, atm. It's the one with all the issues in it and who's working on it and at what priority, you know. ;)
04/26/2005 (4:58 pm)
Ben Garney,Yes the TSE Project Manager that is up on this site. I do not have the link though, atm. It's the one with all the issues in it and who's working on it and at what priority, you know. ;)
#20
04/26/2005 (7:51 pm)
Ah, yes... that project manager. Let me know if that works out for you. :) 
Torque Owner Justin Tolchin
Thanks!