Lighting mission crashes on DIF
by Andy Hawkins · in Torque Game Engine · 12/28/2005 (4:21 pm) · 21 replies
I get a crash every now and then when the "lighting mission" phase is run on load or when I hit ALT+L to relight the scene whilst in the editor. This happens in TGE 1.3 and 1.4.
I did a Winmerge to see the difference between the previous working mission file and the crashing one and found it to be the position of a particular DIF file. When I merged the old position back the crash stopped (the "lighting mission" phase completed without crashing).
I did a few tweaks to put the DIF back where it should be - basically I'm lining up segments of a bridge to make a big one and the ends need to line up. I think I got it pretty close, if not right next to the previous bridge segment. I relit the scene and it didn't crash.
I believe the crash could stem from two DIF's overlapping each other slightly and corrupting light maps either in each other or the terrain.
Does anyone know why this is happening, if there's a fix etc?
I did a Winmerge to see the difference between the previous working mission file and the crashing one and found it to be the position of a particular DIF file. When I merged the old position back the crash stopped (the "lighting mission" phase completed without crashing).
I did a few tweaks to put the DIF back where it should be - basically I'm lining up segments of a bridge to make a big one and the ends need to line up. I think I got it pretty close, if not right next to the previous bridge segment. I relit the scene and it didn't crash.
I believe the crash could stem from two DIF's overlapping each other slightly and corrupting light maps either in each other or the terrain.
Does anyone know why this is happening, if there's a fix etc?
#2
1) Are DIF's allowed to have overlapping faces within themselves? It seems one DIF by itself doesn't crash in Torque. Maybe I should review all the faces and snap them together. Is this possible in Quark? I have a hard time getting edges to snap, it seems I can only get them "fairly" close.
2) If I go this way, should I attempt to have edges in Quark meet and share the same world space or should I "butt" them up against each other?
3) I don't know if this will make a difference, but I guess the cleaner the Quark map is, the less rendering problems I will have. Is there a "snap" function in Quark or do I just use the grid align tool?
12/28/2005 (8:16 pm)
I did try that which created a 1meg file consisting of 4 bridge segments. This crashed too. 1) Are DIF's allowed to have overlapping faces within themselves? It seems one DIF by itself doesn't crash in Torque. Maybe I should review all the faces and snap them together. Is this possible in Quark? I have a hard time getting edges to snap, it seems I can only get them "fairly" close.
2) If I go this way, should I attempt to have edges in Quark meet and share the same world space or should I "butt" them up against each other?
3) I don't know if this will make a difference, but I guess the cleaner the Quark map is, the less rendering problems I will have. Is there a "snap" function in Quark or do I just use the grid align tool?
#3
I snapped all the polys, cleanup up dodgy polys and finally finished a "clean" DIF. I loaded it into Torque and it crashes. I moved it a bit, relit the scene and it worked.
I moved it again, relit the scene and it crashed.
I even removed objects from the Quark scene and re-exported until I had redefined the structure of the DIF and then it worked - then I moved it in Torque, relit and crash!!!!
I have a clean model that maybe, possibly, sometimes if I stand on one foot and hold my breath - might work - but there's no way to be sure.
Not a happy camper right now, any help would be appreciated.
EDIT : Hmm - some dodgy-ness in the hand rails - if I remove them it doesn't crash...
There must be a more reliable method - perhaps Quark is the problem? Can I send the Quark map to someone for tests???
12/28/2005 (11:52 pm)
Okay after a lot of rework I've found this doesn't work reliably. I snapped all the polys, cleanup up dodgy polys and finally finished a "clean" DIF. I loaded it into Torque and it crashes. I moved it a bit, relit the scene and it worked.
I moved it again, relit the scene and it crashed.
I even removed objects from the Quark scene and re-exported until I had redefined the structure of the DIF and then it worked - then I moved it in Torque, relit and crash!!!!
I have a clean model that maybe, possibly, sometimes if I stand on one foot and hold my breath - might work - but there's no way to be sure.
Not a happy camper right now, any help would be appreciated.
EDIT : Hmm - some dodgy-ness in the hand rails - if I remove them it doesn't crash...
There must be a more reliable method - perhaps Quark is the problem? Can I send the Quark map to someone for tests???
#4
In Quark I have a line of cubes stretched up for railings. These vertical struts are causing the problem. With 8 of them (copied from 1 original) it works fine in Torque.
But if I add 4 more it crashes. I've tried lots of different combos in Quark - putting in a different heirarchy, different group, batch them all together in one group, split them into the 4 groups.
There's seems to be a limit imposed on the number of copies of this cube I am using. I don't want to have to make individual ones, I would rather use the first one I textured, then linear duplicate it to have a line of posts for the hand rail.
Any ideas why this would cause a problem? Too many? Too thin?
12/29/2005 (6:52 am)
Okay - worked the problem more and found this...In Quark I have a line of cubes stretched up for railings. These vertical struts are causing the problem. With 8 of them (copied from 1 original) it works fine in Torque.
But if I add 4 more it crashes. I've tried lots of different combos in Quark - putting in a different heirarchy, different group, batch them all together in one group, split them into the 4 groups.
There's seems to be a limit imposed on the number of copies of this cube I am using. I don't want to have to make individual ones, I would rather use the first one I textured, then linear duplicate it to have a line of posts for the hand rail.
Any ideas why this would cause a problem? Too many? Too thin?
#5
12/31/2005 (6:46 pm)
Narrow geometry can cause big problems with map2dif & torque's lighting, due to numerical precision issues. Map2Dif plus should address some of those, and if you can run in debug mode and post the call stack that will help us fix the problem.
#6
12/31/2005 (8:32 pm)
Will do. So I should run Map2Dif in debug and Torque in debug? Where does the call stack(s) get generated so I can post them?
#7
12/31/2005 (9:07 pm)
You should butt the faces and if the face is hidden place a 'null' texture on the that face. Never let geomerty overlap. You can get away with it but it's not good practice. Where it's possible, make the brush a detail brush as this will keep from further cutting up the face that it's touching. As for the grid snapping in Quark...it's a bitch, I've never had much luck in keeping complex maps on the grid with Quark.
#8
@Eric - what's a detail brush? as opposed to other brushes? I thought there was only one type of brush...
\
12/31/2005 (10:09 pm)
@Eric and about Quark to others: Is Cart Shop the better alternative then for dealing with more accurate placement of brushes.@Eric - what's a detail brush? as opposed to other brushes? I thought there was only one type of brush...
\
#9
an example callstack would be:
torqueDemo_DEBUG.exe!GameInterface::journalProcess() Line 159 C++
torqueDemo_DEBUG.exe!DemoGame::main(int argc=1, const char * * argv=0x012e33e8) Line 444 C++
torqueDemo_DEBUG.exe!run(int argc=1, const char * * argv=0x012e33e8) Line 1279 + 0x1a C++
torqueDemo_DEBUG.exe!main(int argc=1, const char * * argv=0x012e33e8) Line 1319 + 0xd C++
torqueDemo_DEBUG.exe!mainCRTStartup() Line 259 + 0x12 C
kernel32.dll!7c816d4f()
12/31/2005 (10:58 pm)
@Andy - You get the callstack by running the app in Debug mode thru the debugger. If you've built the app in .net, then just press F5 to launch the debugger. At the time of the crash look in .net for a "CallStack" window. If one isn't visable the go to the menu Debug->windows->Callstack.an example callstack would be:
torqueDemo_DEBUG.exe!GameInterface::journalProcess() Line 159 C++
torqueDemo_DEBUG.exe!DemoGame::main(int argc=1, const char * * argv=0x012e33e8) Line 444 C++
torqueDemo_DEBUG.exe!run(int argc=1, const char * * argv=0x012e33e8) Line 1279 + 0x1a C++
torqueDemo_DEBUG.exe!main(int argc=1, const char * * argv=0x012e33e8) Line 1319 + 0xd C++
torqueDemo_DEBUG.exe!mainCRTStartup() Line 259 + 0x12 C
kernel32.dll!7c816d4f()
#10
Would it help if I send the DIF to someone?
01/01/2006 (2:51 am)
Alrighty then... one call stack. I loaded the bridge into Stronghold. It lit okay, I rotated it, relit and crashed...Would it help if I send the DIF to someone?
ShadowVolumeBSP::createPoly() line 281 + 3 bytes
ShadowVolumeBSP::splitPoly(ShadowVolumeBSP::SVPoly * 0x030e689c, const PlaneF & {...}, ShadowVolumeBSP::SVPoly * * 0x0012f0fc, ShadowVolumeBSP::SVPoly * * 0x0012f0f8) line 85 + 8 bytes
ShadowVolumeBSP::insertPoly(ShadowVolumeBSP::SVNode * * 0x02ff9244, ShadowVolumeBSP::SVPoly * 0x030e689c) line 198
ShadowVolumeBSP::insertPolyBack(ShadowVolumeBSP::SVNode * * 0x02ff917c, ShadowVolumeBSP::SVPoly * 0x030e689c) line 240
ShadowVolumeBSP::insertPoly(ShadowVolumeBSP::SVNode * * 0x02ff917c, ShadowVolumeBSP::SVPoly * 0x030e689c) line 190
ShadowVolumeBSP::insertPolyBack(ShadowVolumeBSP::SVNode * * 0x02ff9164, ShadowVolumeBSP::SVPoly * 0x030e689c) line 240
ShadowVolumeBSP::insertPoly(ShadowVolumeBSP::SVNode * * 0x02ff9164, ShadowVolumeBSP::SVPoly * 0x030e689c) line 190
ShadowVolumeBSP::insertPolyFront(ShadowVolumeBSP::SVNode * * 0x02ff9150, ShadowVolumeBSP::SVPoly * 0x030e689c) line 220
ShadowVolumeBSP::insertPoly(ShadowVolumeBSP::SVNode * * 0x02ff9150, ShadowVolumeBSP::SVPoly * 0x030e689c) line 186
ShadowVolumeBSP::insertPolyFront(ShadowVolumeBSP::SVNode * * 0x02ff9064, ShadowVolumeBSP::SVPoly * 0x030e689c) line 220
ShadowVolumeBSP::insertPoly(ShadowVolumeBSP::SVNode * * 0x02ff9064, ShadowVolumeBSP::SVPoly * 0x030e6d88) line 201
ShadowVolumeBSP::insertPolyBack(ShadowVolumeBSP::SVNode * * 0x02ff8fc4, ShadowVolumeBSP::SVPoly * 0x030e6d88) line 240
ShadowVolumeBSP::insertPoly(ShadowVolumeBSP::SVNode * * 0x02ff8fc4, ShadowVolumeBSP::SVPoly * 0x030e6d88) line 190
ShadowVolumeBSP::insertPolyBack(ShadowVolumeBSP::SVNode * * 0x0012fac8, ShadowVolumeBSP::SVPoly * 0x030e6d88) line 240
ShadowVolumeBSP::insertPoly(ShadowVolumeBSP::SVNode * * 0x0012fac8, ShadowVolumeBSP::SVPoly * 0x030e6d88) line 190
ShadowVolumeBSP::insertPoly(ShadowVolumeBSP::SVPoly * 0x030e6d88) line 130 + 48 bytes
SceneLighting::addInterior(ShadowVolumeBSP * 0x0012faac, SceneLighting::InteriorProxy & {...}, LightInfo * 0x0329b58c, int 0) line 886
SceneLighting::InteriorProxy::light(LightInfo * 0x0329b58c) line 1708
SceneLighting::processEvent(unsigned int 0, int 28) line 1185 + 51 bytes
SceneLightingProcessEvent::process(SimObject * 0x02ed8cd0) line 112
Sim::advanceToTime(unsigned int 30836) line 157 + 17 bytes
Sim::advanceTime(unsigned int 294) line 165 + 14 bytes
DemoGame::processTimeEvent(TimeEvent * 0x0012fe60) line 694 + 9 bytes
GameInterface::processEvent(Event * 0x0012fe60) line 71 + 17 bytes
GameInterface::postEvent(Event & {...}) line 153 + 17 bytes
TimeManager::process() line 1225 + 23 bytes
DemoGame::main(int 1, const char * * 0x01132da0) line 510
run(int 1, const char * * 0x01132da0) line 1142 + 26 bytes
main(int 1, const char * * 0x01132da0) line 1178 + 13 bytes
TORQUEDEMO_DEBUG! mainCRTStartup + 197 bytes
KERNEL32! 7c816d4f()
#11
Also - Make Sure You Are Using Map2dif Plus. It works a LOT better and may fix these problems.
01/01/2006 (3:01 pm)
Hmm, ok.Also - Make Sure You Are Using Map2dif Plus. It works a LOT better and may fix these problems.
#12
01/01/2006 (8:27 pm)
I've run into this problem before, ususally when TGE tries to light lots of small thin brushes within a certain area of each other. I'd try to run it through Map2DIF Plus, and if you still run into problems with crashing during lighting, try removing those tall thin brushes your using for a railing(?) in the screenshot above, those could possibly be the culprit. If anything, it will help identify what part of the DIF file that is causing the relight crash.
#13
So it would seem the railings cause problems if part of another object, but not if they alone - even though they cast shadows on the bridge itself.
I haven't tried map2dif plus yet.
So how to people do railings in Quark then? I guess I could do a png but Quark doesn't support png's.
01/01/2006 (10:06 pm)
I had to separate the railings (tall thin brushes) from the main bridge and load them into Torque by themselves, then align them to the bridge again. So there a 2 difs to make the bridge, 1 dif is the bridge, the other bridge is the railings. So it would seem the railings cause problems if part of another object, but not if they alone - even though they cast shadows on the bridge itself.
I haven't tried map2dif plus yet.
So how to people do railings in Quark then? I guess I could do a png but Quark doesn't support png's.
#14
So it would seem the railings cause problems if part of another object, but not if they alone - even though they cast shadows on the bridge itself.
I haven't tried map2dif plus yet.
So how to people do railings in Quark then? I guess I could do a png but Quark doesn't support png's.
01/02/2006 (12:51 am)
I had to separate the railings (tall thin brushes) from the main bridge and load them into Torque by themselves, then align them to the bridge again. So there are 2 difs to make the bridge, 1 dif is the bridge, the other dif is the railings. So it would seem the railings cause problems if part of another object, but not if they alone - even though they cast shadows on the bridge itself.
I haven't tried map2dif plus yet.
So how to people do railings in Quark then? I guess I could do a png but Quark doesn't support png's.
#15
01/02/2006 (3:28 am)
Please try map2dif plus. It is a rewrite of map2dif and may solve this problem right off the bat. We have spent many months of effort doing the new version in order to help solve just these sorts of problems. :)
#16
When I take the thin rails out and use map2dif plus - it compiles. Looks like the map2dif plus is also having problems with the thin rails.
01/02/2006 (3:56 pm)
Okay - tried to use Map2Dif plus and it's even worse - it doesn't even compile the map. It gets stuck on Creating BSP - Done, Creating Surfaces....When I take the thin rails out and use map2dif plus - it compiles. Looks like the map2dif plus is also having problems with the thin rails.
#17
01/02/2006 (4:28 pm)
Get Cartography Shop and the Torque PipeLine. You will be amazed at the ease of creating dif's. Then buy Constructor later:) I do some very complex railings in my western game and I have absolutely no issues with map2dif)plus. Even if you do get it working I still suggest losing Quark. Quark is very fuctional but the pain it causes isn't worth it to me. This is just my opinion:)
#18
01/02/2006 (5:12 pm)
@Eric - my only concern with that is that I read Sickhead and Cart Shop had a falling out. I'm concerned that I might be purchasing products with no future support.
#19
01/02/2006 (5:21 pm)
@Eric - my only concern with that is that I read Sickhead and Cart Shop had a falling out. I'm concerned that I might be purchasing products with no future support. 
#20
01/03/2006 (4:17 pm)
Have you loooked at using detail brushes? 
Torque Owner Eric Johnson