If you've ever tried to make a complex self-balanced system in SL, such as a car with real physical axles and wheels, when you turn on the physics you've probably seen it start to shake wildly and then explode apart across the sim.
I've been doing a little research, and it seems that this is not specifically a flaw in the design of Second Life, but is really a problem that is common to many other physics simulations.
What follows here are a number of references to discussions and research papers that talk about the problem of exploding objects, and why this problem occurs in the first place. Go to the URLs to see much more information.
-Scalar
- - - - - - - - - - - - - - - - - - - - - - - -
http://opende.sourceforge.net/ode-latest-userguide.html
Open Dynamics Engine v0.5 User Guide
Russell Smith
Thursday 23 February, 2006
ODE uses a highly stable integrator, so that the simulation errors should not grow out of control. The physical meaning of this is that the simulated system should not "explode" for no reason (believe me, this happens a lot with other simulators if you are not careful). ODE emphasizes speed and stability over physical accuracy.
[.....]
3.3. Integration
The process of simulating the rigid body system through time is called integration. Each integration step advances the current time by a given step size, adjusting the state of all the rigid bodies for the new time value. There are two main issues to consider when working with any integrator:
- How accurate is it? That is, how closely does the behavior of the simulated system match what would happen in real life?
- How stable is it? That is, will calculation errors ever cause completely non-physical behavior of the simulated system? (e.g. causing the system to "explode" for no reason).
ODE's current integrator is very stable, but not particularly accurate unless the step size is small. For most uses of ODE this is not a problem -- ODE's behavior still looks perfectly physical in almost all cases.
- - - - - - - - - - - - - - - - - - - - - - - -
http://www.cs.wisc.edu/graphics/Courses/cs777-2004/p2.htm
Course CS777 - Project 2
University of Wisconsin Computer Graphics
Phase 2: stiff systems
In this phase of the project, we'll improve on what you did in phase 1 by implementing better integrators.
Make a chain of 10-20 partcles, connected with springs and a little bit of damping. Nail the top one in place, and let this "rope" swing. Make a graph of the total length of the chain. Notice how it stretches and compresses. The ability to measure this stretching will be useful as we explore different integrators.
Try to raise the stiffness of the springs to prevent stretchiness. At some point, the equations will become too stiff and the string will explode.
- - - - - - - - - - - - - - - - - - - - - - - -
http://www.gamedev.net/community/forums/topic.asp?topic_id=289699&whichpage=1
Forums » Math and Physics » Why Verlet more stable than Euler
GameDev.Net Discussion Forums
the problem with Euler is that it's a linear approximation. There are some webpages that describe problems you can have with Euler. Problems with Euler occur in orbital motion and spring motion, where the simulator can explode because you overshoot the position each time, thus accumulating errors.
- - - - - - - - - - - - - - - - - - - - - - - -
http://vorlon.cwru.edu/~prm8/eecs466/gelatin_poster.pdf
The Modeling of Interactive Gelatin
By Paul Mecklenburg and Christian Miller
"It's worth noting that under certain circumstances (i.e. various combinations of spring stiffness, point mass, and pressure constants) the Euler integrator becomes extremely unstable, causing the cubes to violently explode. While entertaining for a short time, this is obviously not correct behavior. Stability problems are not trivial to solve, and they are best dealt with in this case simply by avoiding unstable configurations."
- - - - - - - - - - - - - - - - - - - - - - - -
http://vr.kaist.ac.kr/~redmong/Files/Oh_Garment_VSMM2002.pdf
Collision Handling for Interactive Garment Simulation
Seungwoo Oh, Hyungseok Kim, Kwangyun Wohn
Virtual Reality Laboratory
Department of Electrical Engineering & Computer Science
Korea Advanced Institute of Science and Technology (KAIST)
Integration methods include explicit Euler integration, Runge-Kutta integration, implicit Euler integration, simplified implicit Euler integration[4][9], etc. From these we choose explicit Euler integration since it’s computing time is the shortest. Using explicit Euler integration is the same as assuming that acceleration and velocity are constant, thus the position at the next time step is computed as following.
(equation in PDF)
Using this integration, as the time step gets larger or exerted force gets higher, the integration error gets larger and the system is likely to explode. Therefore it is hard to apply to the interactive garment simulation[6][4]. We use the length-correction method[6] that shortens the over-lengthened springs after the integration to tackle this problem. Velocity is not computed until the correction process is finished.
(equation in PDF)
where xcorrection is the position after the length-correction process.
It is unclear whether this method converges or not, however, it can rapidly propagate the deformation and remarkably decrease the oscillation of springs. For this reason, this method has been used in many real-time garment simulations[4][9]. The length-correction method results in more stable simulation than Vassilev’s velocity-correction method differently from the contents in his paper[12].
- - - - - - - - - - - - - - - - - - - - - - - -
This article from six years ago is particularly interesting, since many of their Havok physics tests exactly describe other weird physics behaviors I've seen happen in SL:
http://www.gamasutra.com/features/20000913/lander_pfv.htm
Product Review of Physics Engines, Part One: The Stress Tests
By Jeff Lander and Chris Hecker
Gamasutra.com, September 13 , 2000
