[ODE] iterative solver: testing needed

[Adam D. Moss]

david@csworkbench.com wrote:
>>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?

I wasn't in debug mode, and there was nothing printed except
the startup help-text.

I just tried with debug-mode and I get /lots/ of these:
ODE Message 2: vector has zero size in dNormalize4()

(The allocator reports no leaks.)

Both of those are with PRECISION=SINGLE
I just retried with PRECISION=DOUBLE and this strange problem
still happens.

This is gcc3.1.1 under linux/x86.

Ah, using dWorldStep() instead of dWorldStepFast() makes everything
appear properly, and the above ODE Messages not appear.

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

It looks like I **may** have been confusing a friction problem
with your Erroneously Sliding Things bug -- since a similar thing
can be seen in test_boxstack using dWorldStepFast(), with just a
few or as many as 40 iterations!  (About 1/4 of the bodies micro-
jitter along the ground, looking like they're slowly sliding.)

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

Well I look forward to using non-contact joints in my sim then. :)

>>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 :)

That sounds like one of the golden rules of program design!

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