Function does not accept floating point Not-a-Number values

[aCallum]

We are attmepting to set the worldTransform of an Entity but are running into the above exeption.

What we know:
- We are using

Code: Select all

vehicle.Body.WorldTransform = matrix.CreateFromQuaternion(quaternion.Identity) * matrix.CreateTranslation(new vector3(0, 20, 5000));

to se the world transform of the entity.
- The exception is thrown within

BEPUutilities.RigidTransform.GetBoundingBox(ref RigidTransform shapeTransform, out BoundingBox boundingBox) {}

- The exception gives the following stack trace:

at System.Math.Sign(Single value)
at BEPUphysics.CollisionShapes.ConvexShapes.BoxShape.GetBoundingBox(RigidTransform& shapeTransform, BoundingBox& boundingBox)
at BEPUphysics.BroadPhaseEntries.MobileCollidables.ConvexCollidable`1.UpdateBoundingBoxInternal(Single dt)
at BEPUphysics.BroadPhaseEntries.MobileCollidables.EntityCollidable.UpdateBoundingBox(Single dt)
at BEPUphysics.OtherSpaceStages.BoundingBoxUpdater.LoopBody(Int32 i)
at BEPUphysics.Threading.ParallelLoopWorker.Work()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

Interesting things to note:
- Using the above method above (vehicle.Body.WorldTransform = ... ) the exception is NOT thrown when a value below 500 is used.
- Using the above method above (vehicle.Body.WorldTransform = ... ) the exception is thrown when a value above 500 is used.
- The exception is thrown only when there is ONE instance of this vehicle object (a compound body) exists in the space and we set its the position.
- The exception still occurs when threading is NOT used
- The position appears to be set before the exception occurs
- We are using the compiled dlls in this project

We have come accross one other thread that discussed the problem being external to the library - but we have yet to find the source.

[Norbo]

Setting the world transform appears to be a red herring in this case. It's not the actual problem source. It just changes the simulation into a state which allows the problem to occur.

Without any intervention, propagating NaNs are often caught in the bounding box recomputation as shown. By the time that happens, the NaNs have probably corrupted a significant chunk of simulation state. This can make it tricky to figure out where the original corruption occurred- that is, the first time something became NaN (or infinity, or otherwise invalid).

One of the easier ways to deal with this is to compile BEPUphysics with the CHECKMATH compilation symbol defined. With CHECKMATH, many validations are inserted into the code. They typically catch propagating NaNs much sooner. Even if it doesn't isolate the issue completely, it can still point the way for more validations to be added.

[aCallum]

Thanks for the concise response - just compiled with CHECKMATH - falling over with the LinearVelocity of the entity. No time to explore today but will have a look later this week. Knowing this I'm thinking it could be moving the entity to such a far distance (in z), causes the engine to evaluate the change in distance as a velocity change? Resulting in a LinearVelocity of 0, 0, NaN

[Norbo]

Knowing this I'm thinking it could be moving the entity to such a far distance (in z), causes the engine to evaluate the change in distance as a velocity change? Resulting in a LinearVelocity of 0, 0, NaN

Setting the world transform directly changes the position and orientation. It doesn't change the velocity.

If you're seeing a NaN in the LinearVelocity property setter, something external is setting the LinearVelocity to an invalid value. Walk up the stack at the first detected NaN to see what's passing in the bad data. Watch out for any normalizations of near-zero-length vectors or other divisions by near zero.