[ODE] iterative solver: testing needed

[david@csworkbench.com]

>> As far as the micro-jitter/driving around problem goes, I imagine all
>> code that employs the iterative solver will have it's own way of
>> resolving that through the use of body disabling (which should work
>> now, I'm about to start testing it).  I'll put an example into
>> test_crash for people to use as a reference point (and see how big a
>> wall I can build then :).  I figure I'll go through after each step
>> and disable all bodies who's velocity components (angular and linear)
>> are all less than .01 (probably be tweaked).
>
> I think auto-disabling should live straight in the ODE source.
> Tweakable is a must, as different setups require different numbers, and
> it's useful to have the option to clamp things early for ultra-low
> computation times, especially in cases where things are resting on each
> other arkwardly and constantly re-enable one another.

I would tend to disagree with you, since disabling bodies can probably be
done most efficiently with a priori knowledge of the system.  However,
from your other message, it seems we both came up with the exact same
method of auto-disabling (I came around to the "stay disable-able for n
steps before actually disabling" idea when boxes would hit the ground on
two points and swing up, then freeze at the top of their swing.... when
the velocities were all zero).  Since this is a logical method and easily
tweakable, I don't see why it shouldn't be added to the source, where
there is direct access to body internals.  I'll see if I can't squeeze
this in the stepfast files.  I guess a new body flag will need to be added
to disable auto-disabling for that body.

>>  Then any time I add power to a joint, if I set the velocity
>> != 0, I'll enable the bodies that are connected to it.  Is that pretty
>> much what those who have disabling bodies in their code are doing?
>
> Well, at the moment ODE automatically re-enables disabled bodies
> (islands?) when they're touched by another.

Right, but if you automatically disable bodies accross the board, when a
car is stopped, it gets disabled.  When you then up the velocity on the
joint motor, it's acting on a bunch of disabled bodies, so nothing happens
until the car gets run over....  So I'll need to re-enable any bodies that
were auto-disabled if they are connected to a powered joint.

>> I'm trying to think of a
>> good way to only activate the part of the wall that would be affected
>> by the collision.
>
> Hmm, it seems to me that for this you don't really want to simulate a
> bunch of bricks _resting_ one each other once a wall is built.  What you
> really want is bricks 'glued' to one another.  In other words, you would
> want them to be (in effect) all connected with breakable fixed joints,
> right?  You would then radiate the impact force outwards, disconnecting
> and enabling affected bricks, until you no longer violated the joints -
> with strong joints this would happen quickly.  Of course you still have
> to decide what happens when bricks from the bottom are missing - at what
> point does the wall need to collapse?

Well, if you implement these "glue" constraints as fixed joints with a
settable fmax, which destroy themselves automatically the first time their
fmax is breached.... it might just work.  The problem is, the contact
joints generally do the job of holding the wall up, but it's generally not
a good idea to collide stuff that's connected by a joint.  So the "glue"
joint would have to hold up the weight of all the blocks above it, forcing
you to vary fmax by how high in the wall it was....

> Come to think of it, isn't this really a cloth-like problem?
> --
> gl

Cloth-like problems generally deal with particle based systems.  Since you
want the blocks to roll around like blocks when they hit the ground, I
think it would be better to simulate them as rigid bodies.  On the other
hand, the best approach to the destructible wall problem may be Finite
Element methods, but I haven't read up on them enough to tell just how
feasible they are for a real-time engine.

> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode