Possible bug in PenetrationDepth value?

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
kcoul
Posts: 7
Joined: Wed Feb 22, 2017 9:44 pm

Possible bug in PenetrationDepth value?

Post by kcoul »

Hi Norbo,

Thanks for your help getting up and running combining BEPU with Helix-3D Toolkit in WPF. I am having trouble getting reliable values back from the contactInfo.Contact.PenetrationDepth variable for determining collisions in non-realtime simulation with very tiny increments of coordinate values between colliding objects.

I want it to be possible for objects to be exactly side-by-side or stacked with no collision detection, down to the smallest possible floating point value for their relative sizes. But if any objects overlap by even the tiniest value, to detect this as a collision. I am not using either XNA or MonoGame so it is tricky to understand how I should be tweaking the engine to work the way I want it to.

Sometimes I am getting an extremely large value back from penetration depth, which makes me wonder if there is a bug in the way this double value is calculated. It seems to be "rounding the back", where a very tiny value suddenly becomes a very large positive value by flipping the mantissa. An example number I get back is
3.40282347E+38 which is actually 340,282,346,999,999,936,944,928,768,456,368,192,088 ... it cannot be a valid calculation!

Anyway, I am wondering if it is even possible to use this engine the way I hope to. I want to be able to make increments of maybe even 0.001 or 0.0001 of a unit and have the engine switch from no collision detected to collision detected.

Here's an example of a fairly irregular shape I would like to not require an unusually high epsilon value for, which in this case needs to be at 0.33 for the two pieces to fit together with no gap (visually). I am using the MobileMesh shape as it seems to be the best common denominator.
Is the engine simply not designed for such small positional deltas or is there anything more I can do to achieve the precision I am hoping for?

Image

Thanks again.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Possible bug in PenetrationDepth value?

Post by Norbo »

First, if you see crazy near-infinite penetration values, there's either a bug somewhere or some bad data. If you can reproduce it in the demos I could take a look.

Second, the engine is indeed primarily designed for high performance game-like simulations, not precision industrial work. I would strongly advise against its use for anything involving risks to human life or anywhere else where a bug could cause unacceptable losses.

Given the focus of the engine, it makes use of inexact numerical algorithms in many places, like the Gilbert Johnson Keerthi algorithm and minkowski portal refinement. While these can be tuned to get fairly precise, they are a poor choice for precisions near individual floating point ulps. Even in the other analytic collision detection implementations, performance almost always won over numerical precision. So if maximum precision is absolutely critical, it's not a great choice.

That said, provided a simulation on the order of 1 unit across, 0.001 or 0.0001 isn't that unreasonable. If you're working on the scale of 10-100 units and are requiring epsilons of 0.33, something is likely misconfigured or otherwise broken.

For reference, the engine operates on an expected scale 'window'. By default, this is configured to provide good results for dynamic simulations somewhere in the 0.5 and 100 units range. If you're more interested in the smaller end of the scale, you'll probably want to adjust this scale window. The BEPUphysicsDemos ConfigurationHelper.ApplyScale adjusts all of the relevant tuning factors. So, if objects tend to be around 0.005 to 1 unit, then calling ConfigurationHelper.ApplyScale(0.01f) may improve results. The second block of epsilons is most relevant for collision detection accuracy. Going too small on the scale will probably be pretty forgiving for your purposes- excessively small tuning primarily hurts dynamic simulation.

There is a limit to that tuning, however- at a certain point, the numerical instability of the incremental algorithms combined with the single precision floating point numbers will limit the refinement. At that point, if you still need more, there is the option of just changing every single float in the engine to a double. It's pretty tedious, but occasionally valuable.
Post Reply