Erin Catto wrote:John,
I'm curious about your algorithm. Here are a few questions:
1) What is the particle model used for (just for correcting KE)? How do you compute contact points (RB or particle)? How do you integrate velocities (RB or particle)? How do you handle overlap resolution?
2) What does it mean to correct KE when collision and contact are inelastic?
3) Do you solve one contact at a time?
4) How stable is a vertical stack of 4 1mx1mx1m boxes at 30 Hz with 9.8m/s^2 gravity and no damping? Use a friction coefficient of 0.3. Can you start the boxes with a small vertical offset and some random horizontal shift?
5) Do lower boxes feel the weight of upper boxes? Will a diagonal stack fall over correctly?
Erin, Dirk:
The particle model was originally used for the complete simulation of rigid bodies. Using Jacobsen's concepts, a tetrahedron is embedded in a rigid body. All four particles have the same mass, 1/4 of the total RB mass. The tetrahedron is iteratively scaled in x, y, and z until the particle inertia tensor matches the desired 'ideal' inertia tensor (off diagonals zero). We now have enough information to integrate a rigid body using either the Verlet tetrahedron, or via a standard Baraff style momentum-based integrator (Note: in the current system, the tetrahedron is uniform and not scaled to match the actual RB inertia tensor (Verlet particles are not used for the integration step). This was required for long, thing objects to be stable).
I use only convex hulls in my simulation, where vertices, edges, and planes are stored. Terrain contacts can use just the vertices, while RB-RB contacts use just the edges and planes. Overlap results in 'virtual' points being found inside a convex hull, which are projected to the proper surface.
The displacement required to move the virtual point to the collision hull surface is applied to the tetrahedron using a weighted barycentric method (see Jacobsen's paper). Since the virtual points are computed in barycentric coordinates of the tetrahedron, each projection+distortion effects how far subsequent virtual particles must be moved. These concepts are explained in more detail in Jacobsen's paper. One contact is solved at a time. Impulses are applied to the RB sequentially, whereby the total momentum is updated after each contact is processed. The same concept is used for friction.
Before the displacements are applied, the total kinetic energy of the particles are computed using the following methods from
http://www.brightland.com/Physics/index.htm :
getTotalKineticEnergy() is called and the total KE(before) is stored before displacement.
After displacement, getTotalKineticEnergy() is called again KE(after), followed by setTotalKineticEnergy() to correct the KE. Note in the example code on my website, I allow energy to be lost between RB?s (even gained slightly), which helps with stability. The current code also does no KE correction for objects on the terrain. The current implementation works reasonably well at 100Hz with the objects in my game (9.81m/s^2 gravity, ~1m^3 boxes, etc.). Older versions that did not reset the tetrahedron each step were stable at 30Hz (though slightly springy unless iteration was used).
The lower boxes do feel the weight of the upper boxes, and if the base box is shot on edge (in my demo), the upper boxes will rotate realistically.
http://www.brightland.com/ac/video/KE_mod.mp4 (h.264)
The demo isn?t perfect (note a box sleeping when it should not be, some jitter between boxes (OK as no iteration is used)), but it?s good enough for my game. Since I have not seen much discussion on kinetic energy tracking/correction/modification, I figured it might be helpful to put the ideas out there and see if others can improve on them.
Using KE correction, a bouncing Verlet tetrahedron can be made 100% elastic. KE correction for cloth could be applied using the same principles. Tracking and modifying KE can help debug and stabilize a physics engine. The 'perfect' physics simulator would be Energy Accurate: no energy is arbitrarily lost or gained. It's relatively easy to make a single bouncing rigid body Energy Accurate (
http://www.brightland.com/ac/amazingcur ... s_prev.htm ); creating Energy Accurate stacks, constraints, etc., is much harder.