NaN error inside GetLocalExtremePointWithoutMargin

[m.starkov]

Hi All,

The CollisionShapes.ConvexShapes.BoxShape.GetLocalExtremePointWithoutMargin function raises the NaN error. Could please somebody advise what is a possible reason for that?

I can't see any NaNs inside BEPU entities at the moment of crush. So it is not obvious that error is because of wrong input data.

How can we avoid of NaN errors in general? For now it seems like we can get a NaN error randomly. Thus it can happen even after a thourogh testing (when product will be already delivered). Is there a way (rules) which help to avoid them with 100% probability?

Here are the error details:

• 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.GetLocalExtremePointWithoutMargin
  
  (Vector3& direction, Vector3& extremePoint)
  at
  
  BEPUphysics.CollisionTests.CollisionAlgorithms.MinkowskiToolbox.GetLocalMinkowskiExtremePoi
  
  nt(ConvexShape shapeA, ConvexShape shapeB, Vector3& direction, RigidTransform&
  
  localTransformB, Vector3& extremePoint)
  at BEPUphysics.CollisionTests.CollisionAlgorithms.MPRToolbox.FindPenetrationDepth
  
  (ConvexShape shapeA, ConvexShape shapeB, Vector3& v0, RigidTransform& localTransformB,
  
  Vector3& normal)
  at BEPUphysics.CollisionTests.CollisionAlgorithms.MPRToolbox.AreObjectsColliding
  
  (ConvexShape shapeA, ConvexShape shapeB, RigidTransform& transformA, RigidTransform&
  
  transformB, ContactData& contact)
  at
  
  BEPUphysics.CollisionTests.CollisionAlgorithms.TriangleConvexPairTester.DoDeepContact
  
  (ContactData& contact)
  at
  
  BEPUphysics.CollisionTests.CollisionAlgorithms.TriangleConvexPairTester.DoExternalNear
  
  (ContactData& contact)
  at
  
  BEPUphysics.CollisionTests.CollisionAlgorithms.TriangleConvexPairTester.DoPlaneTest
  
  (ContactData& contact)
  at
  
  BEPUphysics.CollisionTests.CollisionAlgorithms.TriangleConvexPairTester.GenerateContactCand
  
  idate(ContactData& contact)
  at BEPUphysics.CollisionTests.Manifolds.TriangleMeshConvexContactManifold.Update
  
  (Single dt)
  at BEPUphysics.NarrowPhaseSystems.Pairs.StaticMeshConvexPairHandler.UpdateCollision
  
  (Single dt)
  at BEPUphysics.NarrowPhaseSystems.NarrowPhase.UpdateBroadPhaseOverlap(Int32 i)
  at BEPUphysics.NarrowPhaseSystems.NarrowPhase.UpdateSingleThreaded()
  at BEPUphysics.MultithreadedProcessingStage.Update()
  at BEPUphysics.Space.DoTimeStep()
  at BEPUphysics.Space.Update()

I've got:
1. one mesh (just a plain square built from two triangles);
2. four dynamic cylinders (mass=100) with no any user impulses or momentums to them;
3. and four boxes (mass=1) with user impulses and momentum changes applied to them.

Any help is appreciated.

[Norbo]

The most common source of NaN's is a bad velocity which propagates into the position or orientation. On the next frame, the NaN is used by the collision detection system and it explodes.

In most cases, the bad velocity is something computed externally that has a chance of dividing by zero or something similar. It can also occur when something isn't set up properly, and results in a NaN calculation internally. The latter can sometimes be caused by constraints with improper setup. Degenerate geometry may also cause it (though I don't explicitly recall encountering one of this kind; there are quite a few safeties that try to avoid such issues).

If you'd like to nail down a specific cause, download the latest version (http://bepuphysics.codeplex.com/SourceC ... evelopment) and turn off multithreading. This will let the engine run deterministically, assuming identical initialization conditions. Try pushing the system into situations where NaN's are more likely (which depends on the specifics of the simulation). If you find a configuration where it happens enough to reproduce, I can take a look at it to find the specific cause.

[m.starkov]

Thank you for the fast reply.

Could you please clarify: do I need to compile the latest version of source code or is it enough to use the v0.15.2 library?

And... how can I disable multithreading?

[Norbo]

The v0.15.2 precompiled library is an older version which lacks a couple of necessary changes present in the latest development version. If you want to use the latest version on that fork (which is v0.16.0 in development), you'll have to compile it from source.

To disable multithreading, simply do not enable multithreading When threads are added to the space's thread manager, it will run in multithreaded mode. If no threads are given to the space's thread manager, it will run in single threaded mode. Each multithreaded processing stage also has an AllowMultithreading boolean, but you don't have to mess with those for these purposes.

[m.starkov]

Hi,

I,m using 0.16 library and it seems that now it allows me to debug the source (to be honest I don't know what is the difference with previous version in this term).

When error appeared I've found in MPRtoolbox.cs that it is because v2 become equal to v3 and starting from line 309 of MPRtoolbox.cs we can see that it brought us to the cross of equal vectors and then normalization of zero vector gave us NaNs.
MPRtoolbox.cs Line 309,310:

Code: Select all

Vector3.Subtract(ref v2, ref v1, out v1v2);
Vector3.Subtract(ref v3, ref v1, out v1v3);

v2 == v3 is true

I'm not sure I'm able to find why it was happened. I can only suggest that may be it is because my mesh contains several vertices at the same point - I'm gonna fix it and try again.

Is my source still needed to investigate on this?

Regards

Mikhail

[m.starkov]

Hi again,

I've changed Y component by this way: vertices[j].Y = j * 0.000001f;
Not sure if it made any changes to its behaviour.
However for now I'm getting the similar issue at another line (767) of MPRToolbox.cs

Code: Select all

                    
                    Vector3 v1v2, v1v3;
                    // Compute outward facing normal of the portal
                    Vector3.Subtract(ref v2, ref v1, out v1v2);
                    Vector3.Subtract(ref v3, ref v1, out v1v3);
                    Vector3.Cross(ref v1v2, ref v1v3, out n);
                    n.Normalize(); // 767

n is zero at this point

Could you please say if there any suggestions about this?

[m.starkov]

I've found that Box shape have non-zero collision margin attribute but triangle shape does not (all its radiuses are also zero).
May be I have not initialized something?

[m.starkov]

Does anybody knows is there a method of disabling NaNs?
I mean to make system reporting on division by zero immediately.

[Norbo]

I,m using 0.16 library and it seems that now it allows me to debug the source (to be honest I don't know what is the difference with previous version in this term).

The main reason for moving up to the new version is determinism to allow reproducible debugging. There was a problem in v0.15.2 where even single threaded simulations would not repeat their results in some circumstances.

I'm not sure I'm able to find why it was happened. I can only suggest that may be it is because my mesh contains several vertices at the same point - I'm gonna fix it and try again.

That error does indeed imply a degenerate configuration. Obviously, it would be better if it were handled more gracefully.

Is my source still needed to investigate on this?

A reproduction case would still be extremely helpful. This type of error is likely triggered by a relatively unique degenerate configuration. It probably causes problems in multiple areas. If I had something I could look at that reliably reproduces the problem, I could fix the full error rather than a myriad of symptoms.

I don't necessarily need your entire game/simulation code, but anything that reproduces the error would be great. A stripped down demo in the BEPUphysicsDemos project, for example, would be particularly easy for me to plug in and check.

I've found that Box shape have non-zero collision margin attribute but triangle shape does not (all its radiuses are also zero).
May be I have not initialized something?

That's intended; triangles are a bit special and thus do not have margins by default.

[m.starkov]

Ok,

Don't think my stuff costs something at this point.

I'm uploading compilable project for VS 2010 Express (XNA 4).

Please don't forget to put the dll to "External" folder (removed due to file size restrictions).

If you will have nothing in two-five minutes then just restart it.

Almost 100% reproducable.

"c" - to change view
"f" - to free the camera

Hope it will help.

[Norbo]

At a glance, it appears that there are some severe scale issues. The triangles that I'm seeing are over a million units long. That will cause problems even if it doesn't crash- single precision floating point numbers simply can't handle those sizes given the needs of collision detection.

The engine likes individual shapes to have dimensions between 0.5 and 10 units or so. This is a soft range; usually you can get away with sizes outside of those bounds, but the further it's pushed, the higher the chance that numerical problems will start showing up. There's also tuning constants which are designed for that range (see here: http://www.bepu-games.com/forums/viewto ... 139&p=7016).

It appears that if you scale everything down by a factor of 100, and then further tessellate the mesh on top of that so that it's closer to the recommended per-triangle dimensions, things should work substantially better. The crashes should stop, and behavior should be a lot better.

That said, I will try to prevent the hard crashes completely. The relevant system is currently being rewritten.

[m.starkov]

Thank you Norbo,

I've got the point. There is just one question regarding this.
I'm not fully sure that is the full scope of these scales issues... what if we will have normally scaled objects (0.5-10) however placed with large distances between them (let say two cities in airsimulator). Will these huge distances cause a problem?
If yes then can we solve it by simple shifting coordinates so having zero point near to the active objects and also deactivating distant objects?

[Norbo]

Will these huge distances cause a problem?
If yes then can we solve it by simple shifting coordinates so having zero point near to the active objects and also deactivating distant objects?

Absolute positions of objects can indeed be a problem, but far less so than the scaling issue. Collision detection is performed locally between pairs of objects, so the imprecision will only be in computing the relative position. If you try it and see issues, then you can try a solution like shifting coordinates. Having the origin nearby will certainly help.

[m.starkov]

Yes, rescaling it seems to be solved the problem.