Error: No Plane Possible?

#21 I can produce this error by using duplicators in Quark. I noticed the exact symptoms of causing the error when my camera sees a model come in contact with certain sections of a dif. But it only occurred on difs made using the duplicator in Quark. This really bummed me out since duplicators are a huge time saver. I tried several different versions of the map2dts program to no avail. I did bring this up last spring, but it seemed like I was the only one that noticed it. So, if it is user error to use duplicators then I am guilty. I have no idea what it is doing to the geometry of the shape, but I can build a dif that will cause it. This was on the 1.2 version of Torque. I have not attempted to crash the 1.3 version yet. Yes, I did convert the duplicator to individual difs to see if it helped and it did not. I finally decided to not use duplicators at the time.

If anyone needs a dif that will cause this I can whip one up for you.

Thanks,
Frank

#22

Quote:Sorry to be thick but how can any set of numbers in x,y,z result in 0.0 other than 0?

I think it's checking for a distance calculation there, so yeah - it's a test for zero.

Frank - I'm not up to that level YET - we'll see how insane I get and see if I feel like cracking open that code. I just want to get familiar enough with the Torque code first so I can know why *I* am having this problem.

I am using NO DIF files right now - it's all terrain and a couple of DTS files.

#23 Found my problem (I think) - it was the collision volumes getting initialized to extremely high values on creation, but then never set to the proper size / shape.

#24 How were the collision volumes being initialised? In a modelling package or during import to torque?
"More input stephanie"

@Frank: If you can supply a simple QRK that shows this behaviour, I'd love to take a look :)

#25 The problem was in my C++ code, not the model. So it's not directly related to your problem.

However - here's a thought. If the collision data on your maps is somehow broken (exporter issue?) - if somehow one face of the collision volume is unbounded (? Still learning how that works?) or otherwise in error, it could do the same thing, kicking your camera off to never-never land.

I'm not sure yet how you'd track / dump that information... anyone else have an idea? (Man, I hate being such a newbie...)

#26 I had a similar problem and this fis what we did to fix it:

in shadowVolumeBSP.cc
in the function ShadowVolumeBSP::buildPolyVolume
just after this code block:

(*traverse) = createNode();
      Point3F & a = poly->mWinding[i];
      Point3F & b = poly->mWinding[j];
      Point3F c = b + pointOffset;

add this:

////////////////////////
	  Point3F dir = b-a;
	  Point3F pointOffsetCopy = pointOffset;
	  pointOffsetCopy.normalize();
	  dir.normalize();
	  F32 f = mDot(dir, pointOffsetCopy);
	  if ( f >= 0.9999f || f <= -0.9999f )
		  continue;
	  ////////////////////////

this may not be exactly your problem. But perhaps it will give you some direction on how to handle it if you see that your callstack is calling a function that is working in a similar fashion.

#27 This appears to be working for my case, where I didn't even have to collide with anything. It does seem that my problem occurred whenever I was in the shadow of one of my enormous .difs, but it's hard to tell for sure. I just ran my program for 10 minutes without it crashing, where it would crash within 10 seconds before. I hope it's the fix!

-edit-
Well, scratch that... the problem appeared again. It does seem to be less frequent, though.