InitializeVelocityConstraints exception

Topics: User Forum
Aug 4, 2012 at 3:43 AM
Edited Aug 4, 2012 at 3:46 AM

My project was working in farseer v2, but I upgraded to the newest stable v3 because I am a weak willed programmer and needed that all important major version increment to make me feel alive. All appeared well, but after physics initialization for a new level, I immediately get non-fatal exceptions in ContactSolver:196, the line that reads:

Debug.Assert(kNormal > Settings.Epsilon);

I don't know what that means. Thoughts? Some relevant information: In previous versions, I was setting MomentOfInertia to float.Max. Can one still do this to what I assume was a shorter variable name Inertia? Surely this is the same... I only mention because kNormal appears to take inertia into account.

If I make it go past this debug assertion exception, after a few steps (depending on how much I move my character) I get fatal exceptions in World.Step. Briefly the stack trace is World.step -> world.solve -> body.synchronizefixtures -> Fixture.synchronize -> DynamicTreeBroadPhase.MoveProxy -> DynamicTree<FixtureProxy>.MoveProxy -> DynamicTree<FixtureProxy>.RemoveLeaf. The final exception point is DynamicTree:623, and I'm sorry, that's too deep for me to understand at first glance. If I remove my being's OnCollision handler things work until I start moving around, then down the drain - this seems tangential to the real problem though.

I have only added physics objects, no removals yet, and I called world.ProcessChanges after each addition. Thoughts? It has been stumping me recently, and I think it'd be nice to have farseer 3 rather than 2. It is 1 better, after all.

Thanks for the help!

Edit1: FYI at first debug.assert failure:

kNormal = 0.00000004431198


Aug 4, 2012 at 4:12 AM

Hmm interesting debugging sessions + changes later. 

1.) Change density (to mostly 0s) and set weight after making body dynamic. This fixed first issue. (Which caused ArrayIndexOutOfBounds seemingly in world.step)

2.) I have a destructor being mysteriously called. Body.Dispose() is much happier than world.remove, and doesn't mess up broad phase collision's tree.

3.) world.processchanges was unnecessary as it occurs quickly in world.step.