[ODE] Boxes floating in a plane

[Martijn Buijs]

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.
> 
> christoph

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.


Martijn

(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.)