[ODE] iterative solver: testing needed

[david@csworkbench.com]

> gl <gl@ntlworld.com> wrote:
>> Small problem compiling the test on MS VC:
>>
>> ode/test/test_crash.cpp(205) : error C2086: 'i' : redefinition
>>
>> simply remove "int i" at line 172.
>
> I can't seem to make test_crash.exe display anything except
> the ground-plane and the ball-in-the-sky -- though it's
> simulating something because it gets slower when I add more
> cars or wall blocks!

weird.... Were you in debug mode?  Any error messages?

> Additionally, dWorldStepFast() does funny things to my simulation's
> friction, as if mu were being scaled differently (or is now timestep-
> dependant?), because objects are continuing to slide around for somewhat
> longer than they used to (possibly related to David's problem
> -- don't know), even factoring in the fact that I had to disable
> the auto-disabling of near-stationary bodies in my simulation
> because dWorldStepFast() erronously continues to apply gravity
> to disabled bodies.

Hmmmm, I thought I had the friction matched up pretty well.... at least in
drawstuff, with variable framerates.  I guess the higher speed of the
iterative solver masked the differences.

> Speedwise it lives up to its promises -- from some perfunctory
> benchmarking it's never appreciably slower than dWorldStep() in
> the easy cases, and does indeed scale much better performance-wise in
> the many-contact-joints cases (I haven't tested for non-contact joints).

All joints are solved the same way... it should scale the same way with
tons of hinge joints as it does with the same number of contact joints
(well, there'll be a little variation due to the number of DOF's limited
by a hinge, but that's only a small part of the solving process now, not
THE solving process).

> In terms of memory usage I haven't benchmarked it at all, though
> importantly it survives all the stress cases in which dWorldStep()
> segfaults (presumably from extreme stack usage).

Theoretically, it's O(n) instead of O(n^2) in space, though there are a
few more linear arrays in this solution.  So it should run about the same
in space in simple cases, but scale much better with larger systems.

> Stability-wise I find it better than anticipated; I was expecting
> that inaccuracies in constraint satisfaction with too-few iterations
> would lead to objects gradually sinking through each other (or,
> the ultimate horror, 'exploding') but even when reduced to a
> single iteration the worst that my 'enormous pile of objects'
> does is slowly ripple gelatinously.

It does tend to err on the side of Jello :)

> --Adam
> --
> Adam D. Moss   . ,,^^   adam@gimp.org   http://www.foxbox.org/   co:3
> ... but his bosses didn't like him so they shot him into space.
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode