Arithmetic Exception

[Zelxin]

I'm getting this exception when a Kinematic object, collides with some dynamic objects. It should be noted that the Kinematic object is moved by changing the position. and a few of the dynamic objects are as well(some dynamic objects are being moved via multiple gravitational fields).

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.CollisionShapes.ConvexShapes.BoxShape.GetBoundingBox(RigidTransform& shapeTransform, BoundingBox& boundingBox)
at BEPUphysics.Collidables.MobileCollidables.ConvexCollidable`1.UpdateBoundingBoxInternal(Single dt)
at BEPUphysics.Collidables.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.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:

I solved the problem by making all the objects I was moving by changing their position directly kinematic.
Thought I would still post it incase some one else runs into this.

[Norbo]

A couple of notes:
-Moving an object, kinematic or dynamic, by changing its position alone will make collision response with that object 'squishy.' Collision response operates on relative velocities plus a bias term for penetration resolution, so if the velocities don't match the motion, you might end up relying solely on the springy penetration resolution.

-Changing entities to kinematic to avoid a NaNsplosion implies that there's something in the simulation or in the control of the simulation which is introducing bad values. If kinematic entities are immune to it, then chances are it's something force-based- perhaps the gravity fields. For example, if the gravity fields have an unprotected singularity, dynamic objects which venture too close to the center will end up being corrupted with NaNs or infinities. Those invalid values will propagate through the simulation, eventually causing a crash- usually in the bounding box updater.

To catch the crash earlier, you can compile the library with the CHECKMATH compilation symbol. It may assist in finding the source of the invalid data sooner, before it propagates. I would recommend looking into it even if it appears fixed right now, because it's probably just hiding

[Zelxin]

With the CHECKMATH symbol I get this exception the first time space.Update() is called, this only happens when my planets are dynamic, making them kinematic prevents exceptions even after 5 minutes of running.

System.NotFiniteNumberException was unhandled
Message=Invalid value.
Source=BEPUphysics
OffendingNumber=0.0
StackTrace:
at BEPUphysics.MathExtensions.MathChecker.Validate(Vector3 v)
at BEPUphysics.Entities.Entity.ApplyLinearImpulse(Vector3& impulse)
at BEPUphysics.Constraints.Collision.SlidingFrictionTwoAxis.SolveIteration()
at BEPUphysics.Constraints.SolverGroups.SolverGroup.SolveUpdateable(EntitySolverUpdateable item, Int32& activeConstraints)
at BEPUphysics.Constraints.Collision.ConvexContactManifoldConstraint.SolveIteration()
at BEPUphysics.SolverSystems.Solver.MultithreadedIteration(Int32 i)
at BEPUphysics.Threading.ParallelLoopWorker.Work()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:

Ok so after a bit a tweaking I decided that the reason it was crashing was that I was assigning the same mass to the entity as I was the gravitation field(a really big number) and that is what was breaking it.
I think I'm going to scale down the mass for the gravitational field as well as leaving the entity kinematic.


On another note.
What would the best way to make an entity 'orbit' another. Is the best place to start looking for what I need the PathFollowingDemo?

[Norbo]

What would the best way to make an entity 'orbit' another. Is the best place to start looking for what I need the PathFollowingDemo?

Other than the pure dynamic simulation approach (which makes it nearly impossible to guarantee orbital stability over long periods of time), it just comes down to controlling the velocities of the objects in such a way that they go where you want them to go.

The PathFollowingDemo does indeed demonstrate some of that through its use of the convenience classes EntityMover and EntityRotator. For kinematic entities, those classes simply compute the velocity required to move to the goal position within one time step. For dynamic entities, they use a motor which pulls the dynamic entity to the target. (The reason it uses a motor is for robustness; you could just set the velocity like with kinematic entities, but then the 'pull' would not be persistently felt within the solver like it is with a motor. It works pretty well anyway.) You don't have to use those convenience classes, though- the LinearVelocity and AngularVelocity properties are public, and motors can be created externally.

[Zelxin]

Out of curiosity is there any noticeable between changing linear velocity and angular velocity and using EntityMover and EntityRotator. Since I already have all the movement implemented in a way that I can easily convert to EntityMovers/Rotators.

[Norbo]

For kinematic entities, EntityRotator and EntityMover just set the LinearVelocity and AngularVelocity directly to values which will scoot the entity to the goal state by the next time step. There's absolutely no difference there.

For dynamic entities, the motors used by the EntityRotator and EntityMover will have a slightly different effect than just assigning LinearVelocity and AngularVelocity. You can think of setting the LinearVelocity and AngularVelocity every time step as applying a little push repeatedly, but with a little time between each push. Something which comes along and interacts with the object in between the pushes will not feel the pushes- it will only be aware of the current velocity of the object. This is often sufficient. In contrast, using a motor behaves more like a continuous push; objects which collide will feel the motor's influence during the collision response solving process. Given comparable tuning on the motor, the difference is difficult to notice, but the motor does have a stability advantage when difficult configurations occur (e.g. tons of competing constraints and collisions).