Testbed Contact points look out of place about playrho HOT 3 CLOSED

Here's how things look like when the contacts are updated even if the demo's paused (when contact updating is done outside the context of simulating any time):

I like this view better. What I'm looking at looks more sensible to me.

Having the engine work this way changes some performance characteristics though. It means contacts get updated whether or not their associated bodies moved. I had thought of that as an algorithmic optimization. It kept some contact manifolds from getting regenerated at the expense of a conditional branch (and presumably branch mis-prediction costs). I haven't noticed any actual repeatable performance changes either way though. I suspect that's situational to the sim being benchmarked too.

Having the engine work this way also means that contact add state information isn't persistently available anymore to the Testbed when using Single Step to go through a sim a time-step at a time. The green dots for add states flash (for a refresh frame) and then go to the blue color. I don't like this behavior.

from playrho.

I think the better way to handle contact information w.r.t. the world step would be:

1. IFF the world was marked dirty, then update contact information.
2. IFF the world step is told to simulate some time, then
   1. Do regular phase handling.
   2. Do TOI phase handling.
   3. Update contact information.

This way, contact information matches the state of bodies whether the contact info is accessed by PreSolve handlers, or by user code after any world step (regardless of whether the step was to sim any time). And this should preserve the add states for single-stepping through sims in the Testbed.

Unfortunately the Collision Processing Testbed Test causes crashes sometimes (seemingly due to misuse of dynamic memory) with this algorithm implemented and Contact information being displayed. Some of the contact point information which the Test base class builds using its PreSolve method gets invalidated. This brings up another tangent consideration, getting rid of the remaining uses of naked pointers to dynamic memory and instead using RAII managed memory.

I'm putting this "better way" algorithm on hold for the time being.

from playrho.

Interesting. If I enable the display of all the Contact info in Erin's Box2D and cycle through the Testbed tests, I eventually get a SIGABRT too. For Erin's code I get a message of:

Testbed(24806,0x100197000) malloc: *** error for object 0x102b4a240: pointer being freed was not allocated

PlayRho uses RAII more for managing dynamic memory but not entirely.

from playrho.