calcMinDistance with BreakIfLarger option detecting sloped surfaces

[ToddMcF2002]

Strange issue:

If I have a sloped plane, meaning the terrain itself is sloped, calcMinDistance with breakIfLarger works just fine.  However, if I'm running up a sloped surface that is an object on the plane, using breakIfLarger causes the slope to not be detected and I fall through to the plane under it.  This is especially true where the sloped object meets the plane.  So if I'm running down the slope, toward the bottom I suddenly fall through.

Using the "normal" calcMinDistance takes care of it - but I'm curious why this is happening?

[EgonOlsen]

What value are you using for breakIfLarger?

[ToddMcF2002]

120

[EgonOlsen]

I guess 120 is too low then in your case. The difference between the two methods is, that the one without the breakIfLarger is using a very very large value for breakIfLarger internally.

[ToddMcF2002]

I'll stick with the standard calcMinDistance().  I did not notice any penalty at all for the calculation.

As an aside - I changed something structurally that took my test from ~280FPS to ~400FPS, and I was wondering what your thoughts were on this:

Using the car sample - you are calling "place" after adjusting the rotation and speed factors and then reseting the rotationMatrix and applying the new one.   The change I made was to apply the rotation directly to the object (essentially skipping the yRot tracking) and letting the rotationMatrix take care of itself.  So I dropped this code:

Code Select Expand


rotMat=getRotationMatrix();
rotMat.setIdentity();
setRotationMatrix(rotMat);


With the rotationMatrix already calculated I took "moveForward" and added the Ellipsoid Collision detection.  Here is the big change:  Once that collision translation is complete I zero out any Y axis adjustment and call the calcMinDistance() code to handle Y axis adjustment on the terrain.

So essentially its like the car sample with additional Ellipsoid detection in the same pass but without the RotationMatrix adjustment.  My FPS jumped up 100 FPS once the change was done.

Of course it might be a total coincidence.  I might have had 3DMax open or something chewing RAM and eating FPS before the change too.

[EgonOlsen]

I'll stick with the standard calcMinDistance().  I did not notice any penalty at all for the calculation.

As long as you are using OcTrees, the penalty isn't huge if even measurable at all.

As an aside - I changed something structurally that took my test from ~280FPS to ~400FPS, and I was wondering what your thoughts were on this:...

I'm not sure on this one...the rotation-matrix stuff that i was doing is cheap. It can in no way give you such a gain by leaving it out. Anyway, it's better this way then the other way round...