Warmup for tomorrow's integration

pTymN · Post by **pTymN** » Fri Jun 29, 2007 9:25 pm

Hello,

Tomorrow, the Chipmunk guy and myself are going to start working on a cross integration of our code. His physics solver with my swept collision detection.

I was reading through the wiki faq, and thinking about issues that could crop up. Chipmunk basically a glorified and optimized version of Box2D. My collision detection truncates time down from the given interval until objects are no longer going to penetrate during the their motions. It cannot handle penetration, so it works hard to avoid the possibility.

Any tips or questions? I'm unsure about some of the parameters used in the Box2D solver, specifically the bias impulse. The routine that scales back the motion of an object and tries again has the option to not allow time to scale back and instead apply some sort of position correction, even though the position that it is correcting is a position that the object hasn't technically moved to yet. However, in order for the collision detection phase to let an object move, that object will have to agree not to move, or fix its new position so that it doesn't overlap anymore.

How does Box2D deal with penetration, and do you think that I could reorder how it does things without breaking it? Chipmunk (Box2D based) looks really good, and I hate to spend a bunch of time trying to plug our code together with bad results. Looking forward to answers!

raigan2 · Post by **raigan2** » Sat Jun 30, 2007 2:22 am

This might be a fairly involved job -- Box2D's collision/contact allows objects to slightly penetrate so that the contact is persistent.

I'm quite interesting in hearing how this works -- I've tried to add swept-collision to our solver and it never really worked well, when objects stacked together there would always be penetration (due to the approximate solver), which would screw up the sweep tests.

Erin Catto · Post by **Erin Catto** » Sat Jun 30, 2007 4:44 am

Every mainstream engine I know of deals with penetration, even those with CCD. I think the idea is to only apply CCD to objects that are not touching. For objects that are touching, just use the static collision test (preferably the SAT for Box2D).

Frank Labuschagne · Post by **Frank Labuschagne** » Sat Jun 30, 2007 4:49 am

I've used swept collision with a solver made to handle penetrating situations with relative success a few years ago, although i only tested some basic box vs tri mesh linear sweeps. Anyway, if you have a collision at a fraction of 0.3 for the timestep, use the velocity of the remaining 0.7 as penetration depth.

Erwin Coumans · Post by **Erwin Coumans** » Sat Jun 30, 2007 5:16 pm

Indeed, penetration depth (PD) is still useful even when you have CCD, so hybrid solutions are/have been popular. There are a few exceptions of 3d physics engines that purely rely on CCD without PD , like Doom 3.

>>I think the idea is to only apply CCD to objects that are not touching.

Another idea is to not apply CCD for objects with velocity below some threshold. On high impact collisions make sure to reduce/damp the velocity so eventually all high velocity objects will be below the threshold.

There are shortcuts/approximations you can consider: if you are only interested in high velocity objects against static environments (to avoid objects leaving the worls, and ignore CCD between dynamic versus dynamic) you can simply clamp the positional integration to avoid missing collisions.

Erwin

pTymN · Post by **pTymN** » Thu Jul 05, 2007 2:30 pm

So the integration between ToyBox swept collision and Chipmunk is halfway done. I need to reactivate spatial hashing, because the performance sucks right now! I have been passing 0 as the penetration depth to the cpContacts that I create. It looks like the integration is going to work, although I'm using my own position correction, so I'm not using the bias impulse stuff. The position correction has to happen during the swept collision detection phase, because that phase does not exit until all objects' motions successfully do not cause penetrations. It remains to be seen what it will take to stick the bias impulse code in a callback from my collision detection. Otherwise, it looks really good, although my collision detection is significantly slower than O(n), which is about what chipmunk's is.

pTymN · Post by **pTymN** » Thu Jul 05, 2007 9:37 pm

The bias impulse would be better than my current position correction scheme. Is there any problems with applying the bias impulse completely separately from the regular physics solver impulses? I have a callback that will adjust objects' positions during the collision resolution phase, and my collision detection won't succeed unless all objects have been moved to valid positions. The second question is, how are these bias impulses generated?

Erin Catto · Post by **Erin Catto** » Fri Jul 06, 2007 4:31 am

Yes, you can split off the bias impulses. I have an example of this in:

http://www.gphysics.com/files/Box2D_SuperSplit.zip

Search this forum for a discussion of the algorithm.

If you cannot allow overlap, then you must use a _negative_ slop factor. You also need to iterate on the position correction until all overlap is removed. I have not tried this. YMMV

pTymN · Post by **pTymN** » Fri Jul 06, 2007 2:48 pm

Updated info here:

http://www.gamedev.net/community/forums ... _id=454623

Real-Time Physics Simulation Forum

Warmup for tomorrow's integration

Warmup for tomorrow's integration

Swept collision