Updating to v1.2 help

[LostMachete]

I recently tried to update from v0.16 to v1.2 and have run into a couple issues I can't figure out.

One object I made is a directional force field that allows players to move through one way but not the other, like a jump through platform. In 0.16 I checked what side of the field a player was on in the CreatingContact event and then if the player was on the one side I set the pair's CollisionRule to NoNarrowPhaseUpdate and it did what I wanted. When I updated to 1.2 that bit of code stopped working as expected. I can see that it changes the collision rule, it just seems to be getting changed back at some point.

I tried moving the position check to the PairTouching event and that seems to work like before. However, that leads into my second issue, it occasionally crashes when a player moves through the field with an ArithmeticException Function does not accept floating point Not-a-Number values.

The stack trace points to:
at System.Math.Sign(Single value)
at BEPUphysics.CollisionShapes.ConvexShapes.BoxShape.GetLocalExtremePointWithoutMargin(Vector3& direction, Vector3& extremePoint)
at BEPUphysics.CollisionTests.CollisionAlgorithms.MinkowskiToolbox.GetLocalMinkowskiExtremePoint(ConvexShape shapeA, ConvexShape shapeB, Vector3& direction, RigidTransform& localTransformB, Vector3& extremePoint)
at BEPUphysics.CollisionTests.CollisionAlgorithms.GJK.GJKToolbox.AreShapesIntersecting(ConvexShape shapeA, ConvexShape shapeB, RigidTransform& transformA, RigidTransform& transformB, Vector3& localSeparatingAxis)
at BEPUphysics.CollisionTests.CollisionAlgorithms.GeneralConvexPairTester.GenerateContactCandidate(ContactData& contact)
at BEPUphysics.CollisionTests.Manifolds.GeneralConvexContactManifold.Update(Single dt)
at BEPUphysics.NarrowPhaseSystems.Pairs.StandardPairHandler.UpdateCollision(Single dt)
at BEPUphysics.NarrowPhaseSystems.NarrowPhase.UpdateBroadPhaseOverlap(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()


That same error did come up sometimes in 0.16, but I didn't know what was causing it before. I'm still not entirely sure because it’s pretty rare, although it seems to happen more often in 1.2. It seems to happen more when a player is walking through as oppose to dashing but I really have no idea what’s causing that one.

So anyway, is there something happening after CreatingContact that would reset the CollisionRule and is there anything I can do to avoid that error?

Any help would be appreciated!

[Norbo]

There was indeed a change in collision rules management in v1.2.0. To make on the fly collision rule changes more robust, the collision rule computed by the broad phase is passed to the associated narrow phase pair before every pair update. Using PairTouching to set the collision rule will run every single update that there is a contact, so it still works. Using NoNarrowPhaseUpdate won't stop the narrow phase from running (since that's where the PairTouching event is called from), but it will stop subsequent collision solving for that pair, letting the object through.

Compiling BEPUphysics with the CHECKMATH symbol defined might be helpful in tracking down that crash. It should find the NaN earlier in its propagation. Going by the description, it sounds like it's at least encouraged by something in the event handler (since it happens more often with more frequent event handling).

Another possible option is using a one-sided mesh (Sidedness set to either Counterclockwise or Clockwise).

[LostMachete]

Thanks for the help!

I downloaded the source code and put that in my project and made sure CHECKMATH was defined and tried to track down that crash. It took most f the day for it to throw the error again but I think I know what the issue is now. Apparently I was occasionally passing invalid orientations to my players at some point when they passed through because I wanted them to reorient to the platform's surface. Anyway, I added some extra error checks and a bit that forces the player through so they can't move too slow and haven't had it happen again since.

Thanks again! This is a great engine.