TLK 1.4 StaticShape/shadow crashing problem
by Phoenix Online Studios · in Torque Game Engine · 02/14/2006 (2:42 pm) · 9 replies
We recently ported our game to the Torque 1.4 Lighting Pack, but upon loading a mission file the whole thing crashed. After some tests I managed to narrow it down to a problem with some StaticShape blocks in the mission file. While some (simple) StaticShape blocks, representing doors, loaded and displayed just fine, some just crashed the game and others crashed it when the camera was turned towards them. This happened with a clean install of TLK 1.4, but the same mission works without problems in TLK 1.3 and with stock Torque 1.4, so it appears to be something in TLK 1.4 causing it.
Furthermore, the game requires player shadows to be cast on DTS meshes, which they don't do by default. Shadows are only cast on terrain and interiors, as defined by the following line in shadow.cc:
U32 Shadow::smShadowMask = TerrainObjectType | InteriorObjectType;
We changed this line to allow for more shadow casting:
Shadow::smShadowMask = TerrainObjectType | InteriorObjectType | StaticShapeObjectType | StaticObjectType | StaticTSObjectType | StaticRenderedObjectType;
At a very acceptable drop in framerate, this worked just fine with TLK 1.3, but with TLK 1.4 the drop is really dramatic when changing it. It goes down to 1-2 fps at the place where the mission starts, which admittedly is a place where the rendering load is high to begin with, but it's a huge change now compared to the small one we had before.
Furthermore, I discovered that removing ALL player shadows, by setting
Shadow::smShadowMask = 0;
suddenly caused the crashing problem to disappear. With this setting, and even just the removal of TerrainObjectType and InteriorObjectType (I haven't tried removing just one of them yet), makes our StaticShapes work again. So clearly there's something fishy with the shadow casting in TLK 1.4, causing our StaticShapes to crash the entire game and the system load increasing immensely for DTS shadow casting. I've read that the shadow rendering has been modified and improved in TLK 1.4, so maybe we have to do something different to get player shadows working now than editing the line above... Any suggestions what could be the problem here and how to solve it?
Furthermore, the game requires player shadows to be cast on DTS meshes, which they don't do by default. Shadows are only cast on terrain and interiors, as defined by the following line in shadow.cc:
U32 Shadow::smShadowMask = TerrainObjectType | InteriorObjectType;
We changed this line to allow for more shadow casting:
Shadow::smShadowMask = TerrainObjectType | InteriorObjectType | StaticShapeObjectType | StaticObjectType | StaticTSObjectType | StaticRenderedObjectType;
At a very acceptable drop in framerate, this worked just fine with TLK 1.3, but with TLK 1.4 the drop is really dramatic when changing it. It goes down to 1-2 fps at the place where the mission starts, which admittedly is a place where the rendering load is high to begin with, but it's a huge change now compared to the small one we had before.
Furthermore, I discovered that removing ALL player shadows, by setting
Shadow::smShadowMask = 0;
suddenly caused the crashing problem to disappear. With this setting, and even just the removal of TerrainObjectType and InteriorObjectType (I haven't tried removing just one of them yet), makes our StaticShapes work again. So clearly there's something fishy with the shadow casting in TLK 1.4, causing our StaticShapes to crash the entire game and the system load increasing immensely for DTS shadow casting. I've read that the shadow rendering has been modified and improved in TLK 1.4, so maybe we have to do something different to get player shadows working now than editing the line above... Any suggestions what could be the problem here and how to solve it?
#2
Disabling dynamic shadows dit not affect the performance as far as I could notice. Adding the shadow mask StaticTSObjectType alone reduced the framerate just as much as before, unfortunately.
02/18/2006 (8:00 am)
So far I haven't been able to trace down the place where the game crashes... But the suggested fix didn't have any effect.Disabling dynamic shadows dit not affect the performance as far as I could notice. Adding the shadow mask StaticTSObjectType alone reduced the framerate just as much as before, unfortunately.
#3
Though the default was changed, the pref was likely already set the last time torque was run.
What debugger are you running Torque in? The debugger should drop you right to the offending line when a crash occurs.
02/18/2006 (10:48 am)
Regarding the performance; try entering this into the console:$pref::TS::sgMultiDynamicDTSShadows = "0";
Though the default was changed, the pref was likely already set the last time torque was run.
What debugger are you running Torque in? The debugger should drop you right to the offending line when a crash occurs.
#4
The reported exception looks like this:
Going back through the call stack step by step shows where this came from:
1: clippedPolyList.cc, line 100:
I did as you suggested to ensure that dynamic DTS shadows really were disabled, but I can't see any difference. Our high collision mesh count is definitely what's making it slow, but still I wonder why the difference in framerate is so huge between TLK 1.3 and 1.4. When removing all but a few meshes, the framerate goes up to nice levels.
Actually, if there is no workaround for the speed problem, a method to disable shadow calculations on the majority of collision meshes might solve the problem, because we don't need it for more than aiPlayer shadows on DTS floor collision meshes and a few extra ones. But I don't know if there's a nice and easy way to implement something like that...
02/21/2006 (8:23 am)
I'm using .NET 2003 for debugging... Had to turn asserts off to reach the point of the crash without running into other problems before it.The reported exception looks like this:
Unhandled exception at 0x006d34d4 in tsl_DEBUG.exe: 0xC0000005: Access violation reading location 0xd8100550.It happens at line 232 of mPlane.h:
F32 bx = l.x-j.x;As far as I can tell, this is a part of code that calculates a plane. I'm certainly not dismissing the possibility that we have some faulty models. I've seen warnings about planes in the console before...
Going back through the call stack step by step shows where this came from:
1: clippedPolyList.cc, line 100:
void ClippedPolyList::plane(U32 v1,U32 v2,U32 v3)
{
mPolyList.last().plane.set(mVertexList[v1].point,
mVertexList[v2].point,mVertexList[v3].point);
}2: terrCollision.cc, line 614:polyList->plane(vp[0],vp[1],vp[2]);3: shadow.cc, line 484:
obj->buildPolyList(&smDepthSortList,gShadowBox,gShadowSphere);That's the first line of code being in a Lighting Pack code block. Going further back through the call stack shows that this came from a ShapeBase::renderShadow call (sgShadow.cc) when trying to render one of our StaticShape entities. I haven't studied this in detail, but I suspect it's the terrain shadow that's causing the crash. Maybe I should check out the differences in the code of TLK 1.3 and 1.4 in these files...
I did as you suggested to ensure that dynamic DTS shadows really were disabled, but I can't see any difference. Our high collision mesh count is definitely what's making it slow, but still I wonder why the difference in framerate is so huge between TLK 1.3 and 1.4. When removing all but a few meshes, the framerate goes up to nice levels.
Actually, if there is no workaround for the speed problem, a method to disable shadow calculations on the majority of collision meshes might solve the problem, because we don't need it for more than aiPlayer shadows on DTS floor collision meshes and a few extra ones. But I don't know if there's a nice and easy way to implement something like that...
#5
02/21/2006 (6:24 pm)
The assertFatals are there to let you know that continuing will likely crash the app, so whatever the assert caption is will help identify the issue. What does it say and is it always the same?
#6
02/23/2006 (11:09 am)
It spammed me with messages about player models missing eye nodes. This is a known problem that we need to fix by re-exporting some old characters, but based on the code it's not something critical for now... I never got to the point of the crash with these messages popping up constantly. I'll try to get rid of that assert in particular and see what else turns up. There was some network-related assert showing up twice before as well, but I don't remember exactly what it was.
#7
02/24/2006 (4:02 pm)
Another quick question; does this happen if you start with a clean TLK 1.4 and only add the extra shadow masks?
#8
But I also think I found the problem: Some shapes that we didn't need to cast shadows did not have shadows disabled. They are most likely so complex that the engine can't handle them. I should have double-checked this before resorting to debugging, but you know how it is... :P
Anyway, I suppose it could be handy to know that this particular issue can occur in TLK 1.4 when you try to cast shadows off animated objects, that are possibly too complex and possibly have some polygon issues...
And thanks again for all the help!!! :)
03/04/2006 (8:07 am)
To answer your last question: Yes it does!But I also think I found the problem: Some shapes that we didn't need to cast shadows did not have shadows disabled. They are most likely so complex that the engine can't handle them. I should have double-checked this before resorting to debugging, but you know how it is... :P
Anyway, I suppose it could be handy to know that this particular issue can occur in TLK 1.4 when you try to cast shadows off animated objects, that are possibly too complex and possibly have some polygon issues...
And thanks again for all the help!!! :)
#9
http://www.garagegames.com/mg/forums/result.thread.php?qt=44985
Our crash bug was occuring on the exact same line.
05/30/2006 (6:18 am)
Hi think we may have run into a similar issue and may have a work around that you can use.http://www.garagegames.com/mg/forums/result.thread.php?qt=44985
Our crash bug was occuring on the exact same line.
Torque Owner John Kabus (BobTheCBuilder)
Adding dts objects to the shadow receivers is fine, however it does increase the calculation overhead. The larger overhead in TLK 1.4 you are seeing is because of the multiple shadows. To remove these set the static variable 'sgLightManager::sgMultiDynamicDTSShadows' (in sgLightManager.cc) to false.