Crash report: System.ArithmeticException was unhandled

[multox]

This happened randomly, completely out my debuggable code. There were about 1500 boxes and spheres colliding at that time.

Code: Select all

System.ArithmeticException was unhandled
  Message="Function does not accept floating point Not-a-Number values."
  Source="mscorlib"
  StackTrace:
       at System.Math.Sign(Single value)
       at BEPUphysics.Entities.Box.getExtremePoint(Vector3& d, Vector3& positionToUse, Quaternion& orientationToUse, Single margin, Vector3& extremePoint)
       at BEPUphysics.Toolbox.findMinkowskiDifferenceExtremePoint(Entity a, Entity b, Vector3& axis, Vector3& positionA, Vector3& positionB, Quaternion& orientationA, Quaternion& orientationB, Single marginA, Single marginB)
       at BEPUphysics.Toolbox.findConservativeDistanceEstimate(Entity objA, Entity objB, Vector3& positionA, Vector3& positionB, Quaternion& orientationA, Quaternion& orientationB, Single marginA, Single marginB, Vector3& separatingDirection)
       at BEPUphysics.Toolbox.areObjectsCollidingMPR(Entity a, Entity b, Vector3& positionA, Vector3& positionB, Quaternion& orientationA, Quaternion& orientationB, Single& distance, Vector3& normal)
       at BEPUphysics.Toolbox.areSweptObjectsCollidingCA(Entity objA, Entity objB, Vector3& originalPositionA, Vector3& originalPositionB, Quaternion& originalOrientationA, Quaternion& originalOrientationB, Vector3& finalPositionA, Vector3& finalPositionB, Vector3& nextPositionA, Vector3& nextPositionB, Single& timeOfImpact)
       at BEPUphysics.Space.updateLinearContinuousMotionMultithreadedSubFunction(Int32 index)
       at BEPUphysics.Threading.ParallelLoopWorker.work()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: 

[Norbo]

This looks to be a numerical problem. Things like this can happen when colliding object scales are too extreme due to the nature of single point floating point numbers.

Judging by the error, this is happening during continuous collision detection between a box and a large triangle in the terrain mesh. The best way to solve this kind of issue is to make sure each individual triangle in the mesh is fairly regular sized. Sticking to around 0.5 to 10 units per dimension is very safe. The engine can handle more safely in most cases, but it's a good rule of thumb.

The problem can be exacerbated by very fast moving objects in CCD, since they require a longer swept shape which can be numerically harder. "Very fast" here means something like moving significantly faster than the entity's whole size per frame.

The numerical problems can also show up in normal collisions outside of CCD in the form of jitter when extreme scales are involved.

Obviously, the fact that the sweep test can fail so fantastically (even in awkward configurations) is not ideal. The supporting systems are on the rewrite list to increase performance and robustness.

Now if you don't actually have any large or super small triangles and it's crashing like that, something else odd is going on.

[Norbo]

The getExtremePoint NaN is also a common symptom of velocities being corrupted somewhere along the line. If any velocities are ever set, make sure they are not NaN'd or otherwise invalid. Normal collisions should never be the cause NaN's except in extreme numerical problem cases (I don't think a NaN of this type has ever been reported).

[Norbo]

I should also clarify that the most common form of numerical problem-induced crash is an infinite loop in the MPR algorithm. The NaN scenario outlined above is more likely related to bad velocities.

Sorry about the meandering explanations, I'm a little tired today