[ODE] iterative solver: testing needed

[gl]

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

Sounds good.

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

Makes sense (I dont' support joints in my engine yet).

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

The idea was that once you have connected bricks into a wall, you assume the
wall is stable and solid, and no longer simulate it until an external force
is applied.

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

Yes, but once the constraint is broken, you can turn seperated bricks into
full-blown bodies again.  The idea is to avoid having to treat a massive
wall (or entire buildings) as seperate bricks with a full dynamics solution
until necessary.  Even with the iterative solver that may be out of the
question.

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

Not aware of those yet.
--
gl