louis-langholtz
Testbed Contact points look out of place
Expected/Desired Behavior or Experience:
Users don't get confused.
Actual Behavior:
Enabling the display of contact information (contact points, normals, impulses) looks odd given where they appear in a dynamic simulation like the Tumbler demo. Here's an example of this apparent misalignment:
This is not a bug however. Just an artifact of when PlayRho updates contact related information.
I can modify Erin's Box2D to only update contact information the same way and then see a similar display:
Steps to Reproduce the Actual Behavior:
Run the Testbed Tumbler demo with the contact information displayed. Zoom in to a busy region with lots of contact info being shown. Pause the simulation. Dots don't appear located where I'd expect them.
Initial Recommendations
Not sure what's the best to do about this.
Documenting that the dots shown are the locations impulses are applied, while locations of bodies are the results of applying those impulses and any accelerations (like gravity) is one possibility.
Pulling the contact updating back outside the context of the step simulating any time is another option. This may appear less confusing to someone that's used Erin's Box2D before but then the display loses the ability to show where impulses were applied and the results; instead showing where impulses will next be applied.
Which Is preferable or less confusing to someone completely new to a physics engine? Is there another way to address this oddity? I'd like to hear from others on this.
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.
I think the better way to handle contact information w.r.t. the world step would be:
- IFF the world was marked dirty, then update contact information.
- IFF the world step is told to simulate some time, then
- Do regular phase handling.
- Do TOI phase handling.
- 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.
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.