Box2D Demo & Tutorial

[John Schultz]

Hey Dirk,

Yes, you must adjust the old position to update the velocity (see setTotalKineticEnergy() ). One of the comments regarding Jacobsen's tetrahedral rigid body idea is that it's hard to model controllable restitution. Thinking about just a particle system modeling a tetrahedron, when you project the particle out of the surface, you can adjust the constraints (restore the tetrahedral shape), then restore the kinetic energy (taken before the adjustment) as outline above. Now the tetrahedron will never lose energy and bounce forever (float/round error can allow energy leakage or gain...). To model an inelastic collision (energy is lost), just scale back the energy that is restored a desired amount.

When modeling a rigid body with an embedded Verlet tetrahedron, you'll need routines to convert Verlet particle momentum to and from rigid body momentum. Thus, you can compute standard impulses for a rigid body, update the momentum, then set the Verlet particle momentum to the new rigid body momentum (see my website: I added more source code).

Note: my current rigid body implementation for stacking only uses linear momentum/velocity changes from the Verlet tetrahedral system (in addition to linear and angular position changes). It's been some time since I worked on the code- probably done this way for stability (energy error (to be corrected) primarily from potential energy gain due to gravity).

[Erin Catto]

John,

Thanks for the info. I'm still not sure how your algorithm is an improvement in the inelastic case. Perhaps you could try running this test:

- 4 1m^3 boxes in a vertical stack
- time step 1/30
- gravity 9.8 m/s^2
- friction 0.3, restitution 0.0
- no damping or sleeping
- small vertical offset (say 5 cm)
- some random horizontal shifting (~ 10 cm)
- max of 5 iterations

[John Schultz]

John,

Thanks for the info. I'm still not sure how your algorithm is an improvement in the inelastic case. Perhaps you could try running this test:

- 4 1m^3 boxes in a vertical stack
- time step 1/30
- gravity 9.8 m/s^2
- friction 0.3, restitution 0.0
- no damping or sleeping
- small vertical offset (say 5 cm)
- some random horizontal shifting (~ 10 cm)
- max of 5 iterations

Erin, I won't have time to do new experiments for a while, though I did have versions that were stable with (effectively) the above settings (for damping- I take it you mean artificial/hack damping, as friction and restitution=0 are major dampers ). The KE corrector caps energy growth (prevents KE gain from effective PE gain), but allows energy loss via the tetrahedral distortions (only), though this is more like a restitution of 0.0 behavior (realistic energy loss through compression/heat).

The current version (in my game demo) does not require iteration: it is 1-pass stable at 100Hz (game has been tuned for 100Hz). Additionally, stacks are fairly stiff; see the .mp4 video earlier in this thread- see how when the box stack compresses together, the reaction is stiff, and not springy (8 boxes).

When I have the time to change the code to non-reset-tetrahedron form, I believe a 4-stack will be stable with the above settings @ 2-3 iterations.

Is it possible to run your simulation with the above parameters at 100Hz and no iteration (1-pass)? It may be the case that ~3.33 iterations at 30Hz behaves the same as 1-pass at 100Hz...

[Erin Catto]

I don't have a 3D code available right now, but I was able to modify Box2D to these settings:

- 1m^2 boxes in a vertical stack
- time step 1/100
- gravity 9.8 m/s^2
- friction 0.3, restitution 0.0
- no damping or sleeping
- 5cm initial vertical offset between all boxes
- 5cm initial vertical offset between the lowest box and ground
- some random horizontal shifting (~ 10 cm)
- max of 1 iterations

I got 8 boxes stacking stably with about 5-20 seconds of sway.

In my experience, halving the time step is much more effective than doubling the iterations. So I would expect a time step of 1/100 with 1 iteration to have a different result than 1/33 with 3 iterations. At the latter setting, I could not reliably stack 5 boxes.

[LonelyStar]

Hello,

How do prevent objects from jittering? Is it just your algorithem, that does not have the bad side-effect of jittering or is there something you do about it?
Thanks!
Nathan

[Erin Catto]

Nathan,

Is it your own simulation that is jittering? Do you have something I can run?

[LonelyStar]

Hello Erin,

Thanks for you response!
Yes, my own simulation is jittering. I am on a linux system and currently trying to get the cross-compiler to work. As soon as I am done with that, I will upload "somthing to run".

But my simulation has not (yet) much to do with Box2D, other than that it's impulse based.
I am working with convex polygons.
In every timestep I am calculating all collisions that will happen in the next dt (using seperating axis). The contact points are calculated (getting 2 for edge-edge collision and 1 for vertex-edge collision) and impulses are applied to them.
I want to get stacking to work, but before that I have to get rid of the jittering.

Jittering in my case means, that something lying on the ground always rotates a little.

Nathan

[Dirk Gregorius]

Do you use a stabilization term? You should only correct a small fraction of the position error. Usualy around 10%. You should also try to allow some penetration instead of trying to resolve the whole penetration. This will give you better coherence if you use warmstarting...


Cheers,
-Dirk

[Erin Catto]

Nathan,

It sounds like you changed the formulation a bit by computing impulses for future contacts. Do you still get jitter if you use the original Box2D algorithm?

[DanEE]

@Erin or all the others :
Sorry in advance if my question is completly ridiculous, I'm still a beginner with physic based animation...

My ultimate goal is to implement a 3D-Demo based on the ideas on Erins Slides. I am digging through the source-code of Box2D and I think I begin to understand it more or less.

But I have still a conceptual question with the collision detection:
Why do you make a clipping in the box-box test. What do we actually gain in this clipping step, what we don't already know from the "normal" SAT-Test?
Therefore I don't really understand additionally what is meant on slide 14:

- Clip incident face against reference face side planes (but not the reference face).
- Consider clip points with positive penetration.

Another thing is on the slide with the 3D-issues:

Align the axes with velocity if it is non-zero.

I hope you can help me, and that I am able to implement something with your help! (That I am really able to implement it is not sure at all though... )

[Erin Catto]

- Clip incident face against reference face side planes (but not the reference face).
- Consider clip points with positive penetration.

SAT can only tell you the features involved in the collision. You need to do clipping to get contact points. If you don't clip then you will get contact points where the two boxes don't even touch.

Align the axes with velocity if it is non-zero.

In 3D, friction occurs in a plane. Since it is a plane, friction occurs in two directions (axes). If you align the friction axes with the sliding motion, then you will get more realistic friction.

The problem with using fixed directions for friction is that those directions will have weaker friction than diagonal directions. Thus sliding boxes will steer towards the axial directions. This is bad.

My advice to you is to start simple. First try modifying Box2D. Add a circle shape. Add a distance constraint. When you go to 3D, start simple. For example, just do spheres and planes.

[coderchris]

In 3D, friction occurs in a plane. Since it is a plane, friction occurs in two directions (axes). If you align the friction axes with the sliding motion, then you will get more realistic friction.

The problem with using fixed directions for friction is that those directions will have weaker friction than diagonal directions. Thus sliding boxes will steer towards the axial directions. This is bad.

Ahh...so thats what that align axes with velocity meant...That clears things up and explains the wierd motion I was getting. It happened to go off in the axis directions just like you said

One question about aligning the axes with velocity:
if an object is, for example, sliding across a plane, there will only be one axis in which friction will act since velocity only works in one direction, correct? If so, why would we even need the other axis for friction?

You also mentioned in the slides something about using a single point for friction by combining all the others, but would require a "twist friction"
How is this computed?

[Erin Catto]

if an object is, for example, sliding across a plane, there will only be one axis in which friction will act since velocity only works in one direction, correct? If so, why would we even need the other axis for friction?

This is an open issue. Initially the friction is aligned with the velocity, but as the constraints are iterated, the velocity might steer away from the initial direction. I'm hesitant to adjust the friction direction during iterations because it might affect convergence. However, it might work.

Twist friction is modeled by requiring the relative angular velocity about the contact normal to be zero. The twist friction impulse torque needs to be clamped by:

max_friction_torque = mu * lever_arm * accumulated_normal_impulse

You should pre-compute the lever_arm as the average distance of all contact points on the manifold from the center of the manifold.

[LonelyStar]

Hello,

It's me again. I posted a question a few posts back and never came back. That was very rude of me, I moved and did not have internet and no time. I am sorry!

I am looking through the source of Box2D, trying to understand it, and I have a question:
If I see correctly, you find the arbiter (which are something like contact-point manager) once in the Broad Phase. Then you iterate a few times over the arbiter making sure there needs are met.

But what is with this scenario:
We have lot of boxes (B) lying on the ground (-) side by side and another Box (A) coming from the right with speed:

A -> BBBBBBBBBBBBBBBBBBBB
-------------------------------------

Now A collides with the first B, a arbiter is created between them. The impulse should propagate through all the B's, but there are no arbiters between the B's.

How does this work in Box2D?

Thanks!
Nathan

[stbuzer]

I think that if there was no collisions between B's at the moment of the A and first B collision there will no impulse propagation, but since the first B got some velocity new collisions will be detected during the next time step and so on.