[ODE] Boxes floating in a plane
buijs512 at planet.nl
Mon Nov 6 18:01:35 MST 2006
Christoph Beyer wrote:
> *Kyle Hubert wrote:*
>> I just bumped the mass up really high, that's all.
> Yes you're right. It happens with all heavy objects.
> It happens with all kind of geom: heavy objects
> ( affected by gravity, or other forces/velocities ) are floating into
> other objects!
> It seems to be a "bug" of the correction-forces.
> disabling soft_cfm and incrementing the soft_erp value reduces this problem,
> but it is never solved.
> I hope, that someone has an idea how to solve this.
> Because i need cfm to avoid jittering (i.e. in boxstacks),
> but high cfm makes small objects with more than 5000 mass
> floating/bouncing into walls.
It is just the way ODE deals with penetration. If the velocity (dependent on mass) is great enough,
the boxes will penetrate the plane and sink. When the penetration correction force becomes large
enough it 'floats' up to the surface, only to sink again. The only way to reduce this is to lower
the mass (or smaller timestep and tweaking all ERP, CFM, joint settings etc).
Although you can get close to zero penetration with ODE you usually blow up the rest of the
simulation doing so. This behavior is one of the reasons I moved away from ODE, it was unacceptable
for what I was doing.
In my own physics engine I've fixed this problem by not allowing any penetration at all. Even two
bodies with infinite mass will never ever penetrate, neither will they explode and fly in opposite
direction which happens very easily with ODE.
It does makes the systems a bit more jittery (objects take longer to settle) but these issues are
generally much more acceptable and easier to fix/workaround.
A big bonus is that you can work with real world mass values. While tweaking is unavoidable, it is a
_lot_ more intuitive to work with real world numbers than with abstract values.
One thing I also incorporated is a per surface density property that allows intentional penetration
(0.0 == allows full penetration, 1.0 == solid) which can be used to simulate water and other (semi)
penetrable surfaces (pillow, foliage, mud, snow, quicksand). It also works great to solve stability
issues for complex systems -- just like ERP and CFM do -- except it does not affect the forces on
the object (since there is no correction force) so it will never increase instability in other
situations. Also very handy for vehicle tires and making FPS player avatars feel less 'rigid'.
A disadvantage of this way of fixing penetration is that there may still be some unwanted
penetration in some situations. For example if the bottom crate of a stable stack is moved upward
(to fix ground penetration caused by gravity), it will penetrate the one above. This is not an issue
if the above crate is updated _after_ the one below, but it will in any other order (i.e. is
deterministic but not really consistent). There are many methods to reduce this, for example by
sorting clusters of potentially intersecting objects by their force vectors (this works great for
stacks) or 'smart' iterative approaches.
In the end it does reduce penetration a great deal plus addressing a load of stability issues
directly caused by it. And it works more like nature, which in general is a good sign. To me this
seems the way to go for ODE. Be it addition, not necessarily replacement.
So the main issue is that ODE 'pushes' (dBodyAddForce) the objects out of each other instead of
'moving' (dBodySetPosition) them.
There has been a patch ( http://q12.org/pipermail/ode/2005-April/015705.html ) around for a while
which seems to do exactly that. What's the status? Did anyone look at it after recently? Does it
also work for joints types other than contact joints? Or is there something else in the works that
covers this problem?
If the patch is adopted, would it be a global compile option? Perhaps it would be ideal to make it
configurable per world and per body (like CFM & ERP), allowing you to switch (or even lerp) between
the two methods where wanted.
(Note: Please correct me if I'm wrong. I'm not an authority on solvers and most of my experience
comes from small experiments with ODE and my own little physics engine.)
More information about the ODE