The gPhysics Engine
Back in 1999 I wrote a physics engine using joint coordinates (Featherstone) and a direct LCP solver (Lemke). By no coincidence, the engine was called gPhysics.
The Lemke solver sucks. It is slow and has numerical problems. However, I am now again interested in joint coordinates. So I dusted off my old code and came across these demos.
The gPhysics engine proves that you can extend Featherstone’s algorithm to simulate trees, detached bodies, and contact. Now I just need to hook it up to a better contact solver.
January 25th, 2007 at 10:05 pm
they dont work
January 29th, 2007 at 5:20 pm
They work for me, Erin!
February 15th, 2007 at 7:58 am
They work =)
June 18th, 2007 at 9:36 pm
“Now I just need to hook it up to a better contact solver.”
Well, yes, that’s the hard problem, of course.
Our Falling Bodies system, from 1997, did that quite well. It’s basically a Featherstone algorithm with spring/damper contacts, using some new techniques (see U.S. Patent #6,067,096) to get good stability. The motion looks better than what you get from impulse-based system. In impulse-based systems, everything goes “boink” - all bounces take zero time. With spring-damper collisions, heavy objects collide more like heavy objects. (Videos here: “http://www.animats.com/topics/videos.html”
This was the first ragdoll system that worked.)
This approach also yields much better handling of friction than impulse/constraint systems. The static indeterminacy problem, and the jittery effects that come from it, go away. We used to simulate a rattleback as a demo, and it would actually transition from spinning to rocking to rotating in the reverse direction.
Back in 1997, this took too much CPU power for game use, so we sold it as a tool for high-end animation. We licensed the technology to another company and went on to other things, but five years later, that deal is complete and we have the rights back. It may be time to look at that approach for games again, now that consoles have enough CPU power.
June 18th, 2007 at 9:43 pm
(The videos on the Animats site are encoded with the Intel Indeo codec, which few have any more. See
http://www.youtube.com/animats
for the YouTube versions.)
September 10th, 2007 at 6:41 pm
http://groups.google.com/group/comp.games.development.programming.algorithms/browse_thread/thread/cae6efa836f33fde/707794d6ee8dc2e4
September 11th, 2007 at 9:49 pm
Also see http://cs.ucla.edu/~dt/papers/siggraph87/siggraph87.pdf for 1987 SIGGRAPH prior art (predating this patent by more than a decade) using exponential springs for collision response (equation 13 page 208). Demetri Terzopoulos, John Platt, Alan Barr, and Kurt Fleischer, “Elastically Deformable Models”, Computer Graphics, Vol. 21, No. 4, July 1987, pp. 205-214.
October 30th, 2007 at 1:57 pm
Those early elastically deformable models were neat. That was from the early, “jello” era of simulation. You could simulate soft bodies, but not hard ones. If you cranked up the stiffness of the materials, the equations became too nonlinear and stiff to solve, and the simulations went wildly unstable. (Anybody remember Hypermatter, or Alex Pentland’s superquadric system?)
People are still having trouble with instability in spring/damper systems. Today’s usual solution is “projection”, which means making a nonphysical move to fix the model when the forces become big and the integration goes unstable. The enthusiasts for Verlet integration do this. It’s a hack good enough to get a game back on track, but it doesn’t get right answers. Good enough for blowing up stuff; not good enough for legged locomotion sims.
It takes careful error control and monitoring to make spring/damper systems behave well. It uses more CPU time during tough situations. But honest simulations are possible, and for robotics work, they’re needed.