Error: No Plane Possible?

#1 Well, take a look at mPlane.h at line 233, then with the debugger, trace it back to what's making the call.

Remember, a plane can be determined by 3 points. If two of these points are exactly the same, then you really only have a line (and any plane will fit that). or, if two of these points line up on a line (ie: the X, Y, or Z terms are the same) then you can't necessarily make a plane of it. I know it's a little more complicated than that, but take a look online for the Plane function, and then do a little more research.

Plane calculations are used a lot in collisions. You can apply them to other circumstances to determine orientation and such, but mainly for collision. Maybe have a bad surface somewhere.

- Brett

#2 Thanks brett, had enough for the moment though, gonna leave torque alone for a while.

#3 This is wierd,

1. If i'm in 3rd POV when I enter the building, it crashes
2. If I enter in 1st person it doesn't
3. If I switch to 3rd POV when in the building, it crashes!

Its something to do with the bounding box of the player, if I use a small player, its ok, if I use a bigger player, IT CRASHES!

#4 This is now happening all over the place! I originally thought it was an interior but it seems to be related to the player model and the camera. Changing camera mode in any interior now causes this error, it also happens when the camera hits the roof!

I'm not at all sure how to debug the engine, I'm using VS.Net 2003 if anyone cn offer some advice :)

Any ideas?

#5 Only thing I could recommend, if you havent done so already ... is re-download the 1.3 installer and reinstall it and test it out in there with a fresh version, or grab the HEAD

#6 I'm having that problem now, too.

I was about to post something, but then I saw it here.

I've got a fairly fresh build, from HEAD - but I have added a new object type for the player to control. It is derived from the ShapeBase object.

It COULD be related to my model (somehow) - something not configured correctly. I do have eye and cam joints. Or it could be related to the new object class. Or possibly the exporter for MilkShape 3D.

What I DO know is that this error is coming from the generation of the view frustrums from what seems to be uninitialzed camera parameters.

I get this problem about 50% of the time. Sometimes things work okay in the regular mode, but switching to the free-floating camera hoses it. Sometimes everything works fine.

Is there some camera initialization code that I could be missing? Or is there a known issue with the Milkshape exporter? Fruitbat - are you using custom .cc files for your playable object, or are you simply using the built-in Torque class?

#7 @Jay:
The only difference from the stock 1.3 is the lighting pack and model utilities, apart from that I haven't touched any of the script or engine.

Do you get the same error message? Have you got the lighting pack or modelling tools installed?

#8 Stock 1.3, grabbed from HEAD about 2 months ago.

No lighting packs or new model utilities. I was adding the Advanced Camera code last night, but the problem has been around for a couple of weeks. I've been ignoring it. The only other changes I've made were to add the fix for the hovercraft collision (though I'm not using the hover vehicle currently), and my new object class derived from BaseShape. It WORKS most of the time (so development has continued - when I have time). Until I saw this thread, I assumed it was something I was doing wrong in the class.

I also added some additional code so I could break on the assertion and trace back the error I was receiving.

I get the message when I run the debug version of the Torque demo. In the retail version, the screen never clears or updates, and the UI elements just constantly overwrite each other (which makes the flaws in the health-bar transparencies turn white, and you leave a mouse-trail wherever you go).

What model editing package are you using?

#9 Just as an FYI--I don't have a fix/solution per se, but I ran into this occasionally myself, and it's rough to debug:

The error message is an AssertFatal that will only actually force a crash when you are compiling a BUILD=DEBUG executable. It's there because something in your model violates assumptions in the rendering/processing for the specific object(s) that you are rendering.

I ran into this mostly when either importing dts models with very complex collision meshes, and also ran into it once when I was working on manually applying the repeatTerrainOff code into my tpager fiasco.

My only real suggestion would be to carefully search for errors in the export, or possibly look for problems with collision, but since you're using .dif, collision is way different, so that may not be an appropriate suggestion.

#10 When I broke on the assertion, I saw that it came from creating the camera frustrum planes - the problem was that the points for the frustrums were out somewhere > 1.0e+09, and they were identical (You need three unique points to calculate a plane).

My assumption - since my problem always occured at the start of the mission or when I switched camera modes - was that I was missing some camera initialization somewhere. Though Fruitbat is having the problem when running into collision meshes.

I had this problem with NO collision mesh, as well with a simple cube mesh. It seemed to happen more frequently when I enlarged the model and the mesh. The model I'm having a problem with is around 1500 polygons --- is there some kind of inherent limit to the number of polygons a Torque model can handle? Maybe I'm stomping over memory - that would explain why the problem is intermittant.

#11 Oh - hey - possible idea.

Since I'm deriving my object off the ShapeBase class, does the collision mesh still apply? I remember seeing how they were used by vehicles, but not by the player. Could that be a factor?

Or am I just barking up the wrong tree? My knowledge of Torque is very limited - I'm learning as I go.

It's nice to know I'm in good company with this problem --- I just wish someone had a more definitive answer.

------ EDIT ------------
NEGATIVE ON THAT - I've had a chance to play with it with several different models of different poly counts, including an 80-triangle sphere and the "buggy" model that comes with Torque. Got the same problems intermittantly. Sometimes on the initial load, sometimes when I switched to camera control.

If this was happening 100% of the time it'd be a lot easier to figure out.

#12 Okay - here's what I'm seeing

The problem is getting caused in:

PotentialRenderList::setupClipPlanes(SceneState* state)

What's happening is the temp matrix (the inverse of state->mModelView) is hammering the corners of the view frustrum. For example I've got the following temp matrix:

-	temp	{m=0x0012e950 }	MatrixF
-	m	0x0012e950	float [16]
	[0]	0.99837893	float
	[1]	-0.056916729	float
	[2]	0.00000000	float
	[3]	-1.7348298e+009	float
	[4]	0.056916729	float
	[5]	0.99837893	float
	[6]	0.00000000	float
	[7]	-1.7348298e+009	float
	[8]	0.00000000	float
	[9]	0.00000000	float
	[10]	1.0000000	float
	[11]	-8.6187008e+009	float
	[12]	0.00000000	float
	[13]	0.00000000	float
	[14]	0.00000000	float
	[15]	1.0000000	float

I am still trying to figure out what mModelView is supposed to be, but my guess is something is being done wrong that is hammering it and putting it's translation out in la-la land. What's happening (I think....) is that all my vectors are losing their resolution and becoming:

+	farPosLeftUp	{x=-1.7348303e+009 y=-1.7348293e+009 z=-8.6187008e+009 }	Point3F

Anyone got a suggestion as to what is going wrong here?

#13 @Jay: I don't have any specifics to point you towards, but after 8+ months of working with TGE, I'm very confident that if something asserts, it's a UserError(tm). I would suggest that maybe you do a "work both ends towards the middle" strategy, and see if you can figure out what may be going wrong in either the model itself, or the export/import pipeline as well as the engine debugging.

I know that when I was hit with the Assert, it was definitely in "I'm really confused here, hack this and see what happens" type of implementation, and I'm thinking that the reason you and FruitBat are getting this now has to do with either a problem with the model(s) themselves, or a bug in the exporter/importer process.

#14 Interiors
The thing is that some of these models were compiled 8 weeks ago and have been working fine and been run over a 1000 times with no problem. This problem has only recently started in a new mission. Now it may be one of the new models (Difs I'm talking about) has introduced an error, but how would it spread from the erroneous dif to the others? Maybe the scenetree? or a plane that is infinite and cutting through other difs, but that would show up in the debug render modes surely?

Any idea how to even start tracking down this problem, I have tested each model individually and no plane error when they are on their own.

Jay
Thanks for the debugging info, can I pick your brains when you've got half an hour :)

#15 There does seem to be a problem in the DIF files in my instance, the buildings that cause the crash seem to flash the exterior occaisonally and the camera does not stick to the plane (wall, ceiling, roof), it seems to go through it. But the crash is still random.
I've been through the models and there is no error in the MAP file (I am blind from all the number checking) which again leads me to believe its got to be an issue with the CSG process. Would it be possible to round the erroneous figuires in the matrix? May not be the source of the problem but it would stop the crash.

#16 Further investigations reveal that the camera is managing to enter a brush in the DIF! If you get the angle right the entire building dissapears. The player or projectiles do not have this problem, if you jump he hits the offending brush like normal, when the camera is in a brush the player still moves and its collision detection is correct (i.e. even though the building isn't rendering the character still moves through it as normal).

I am soooo confused!

#17 How does the camera entering the brush cause the plane error, I wonder?

My problem is (I think) mission-based --- something is kicking out the camera into Outer Timbuktu, or it is simply not getting an initial position set somehow.

Is there a call I'm supposed to be making in the .CS scripts that I've somehow left out that properly initializes the camera?

#18 I'm guessing that the camera is looking for the plane to lock to, so it travels along the ceiling, I guess that because it passes through the face it can't then follow that plane or even reference it, hence the crash.

#19 FruitBatInShades...

Lemme just say this: "Stick to it!" The way I finally learned Torque was to just stick with it. After I had spent 2 months on Stencil Shadows and was ready to give up, I pushed ahead and had my biggest breakthrough of all. When I was working on the racing game, I came to a point where the collision just wouldn't work... What did I do?? That's right... I pushed ahead and now I'm working with Bravetree on an amazing game.

When there seems like there's no light at the end of the tunnel, or that you'll never solve a problem, that's usually when you have your biggest breakthroughs. I respect your commitment so far... don't let me down!

- Brett

#20

F32 squared = x*x + y*y + z*z;

AssertFatal(squared != 0.0, "Error, no plane possible!");

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