Author Topic: calcMinDistance with BreakIfLarger option detecting sloped surfaces  (Read 4902 times)

Offline ToddMcF2002

  • long
  • ***
  • Posts: 103
    • View Profile

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?


Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 12295
    • View Profile
    • http://www.jpct.net
What value are you using for breakIfLarger?

Offline ToddMcF2002

  • long
  • ***
  • Posts: 103
    • View Profile
120

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 12295
    • View Profile
    • http://www.jpct.net
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.

Offline ToddMcF2002

  • long
  • ***
  • Posts: 103
    • View Profile
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]
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.


Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 12295
    • View Profile
    • http://www.jpct.net
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... ;)