Box2D Forums

Alright well good luck with your hang. Mine is definitively caused by the Box2D step function, but I might be doing something stupid before the call. Anyone feel like they could explain to me what the above For loop is? Thanks!

I have looked over this code many times. I will not be able to fix any problems in it without a reproducible test case.

The code is (gasp) calculating time of impact for two moving shapes, iterating using numerical techniques. Reaching 50 means it is not converging at all (it rarely goes above 5 iterations in normal use).

Makes sense, I will try to give you a good repro

In the meantime, do post if you can think of potential situations that could cause this loop to not converge!

Hi again,

I think I've found the fix here. The problem for the SolveTOI function is that the first fixture's body position X and Y values are NaN. I can imagine how this prevent SolveTOI from converging

Now the question became: what is setting that body's position to NaN? So I looked into all the instances where b2Body:m_xf.position was changing, and found that the position is changed within the step() as well. Here's the callstack:



Turns out m_sweep.c values were set to NaN.

I started to look everywhere for b2Vec2 classes being set to NaN, and I realized I was multiplying the position of a mouseJoint attached to that body by a NaN value (1 divided by 0). So! My understanding is that by setting the b2MouseJoint:SetTarget to a NaN vector, I caused this hang.

I'm not sure where, but it sounds like we would want to add an assert somewhere to make sure no one hits that hang again. The SolveTOI part is the part that hangs, but the cause of the problem was really earlier. It was a stupid bug and really my fault, but it would help if Box2D could detect that problem before hanging.

Thanks for your help on this, I can now sleep properly

It's not my policy to put in a bajillion asserts. A NaN pretty much anywhere in the system is a problem, and naturally people need the earliest warning, or else it's about as useless as the error you actually got. Given the choice between checking everything, and nothing, I'll go with nothing.

I do have vague intentions of throwing in some cases where Box2D C++ silently ignores, at least.

Hi,

Is there a definitive fix for this? I've got a basic game engine running (Bike game :-) and when travelling at speed a collision causes box2d to hang and it times out...

From some debugging it appears to be the same problem occuring within b2TimeOfImpact

Thanks,

Mal

I would check if you have any value (position, velocity or anything else) in your objects that are set to NaN. That was my problem, and it is unfortunately hard to find where you might be doing this. Box2D doesn't assert to make sure the values we feed it are valid.

Thanks for the info, but after a mammoth effort to test everything it didn't seem to be a NaN issue.

It turns out I was passing in too low a figure for "positionIterations" into world.Step(...)

A figure around 10 was fine for normal collisions, but upping this to 50 as velocity increases handles fast collisions much better.

Thanks again

50 is a ridiculously high quantity. Something is wrong if that is necessary.

To be fair I haven't tried much lower figures yet, and the impact was happening at great velocity.

I'll try lower numbers >10 and post again when I've done that...

Cheers