[ODE] test_boxstack and geom offset

[Bram Stolk]

Geoff Carlton wrote:

> What I found:
> 1.) The old creation code has a "<2" loop that looks like it should be a 
> "<GPB" loop.  I don't think it is deliberate that the last geom doesn't 
> get a dGeomSetPosition call.  I changed the old code to use GPB, since 
> it seems an obvious bug.

I agree.

> 2.) Setting up geom offsets is a bit awkward because offsets can only be 
> set after the body is attached, and current code attaches the body at 
> the end.  So I had to add a "setBody" flag since my code sets the body 
> early on.

That makes sense.
I believe that you assert/warn if the order is incorrect?

> 3.) The existing code gets it wrong!  Most obvious when GPB is set to 1, 
> but clearly noticible normally.  The geom is offset with dpos[k] and 
> Rtx, and so is the mass.  But the dMassRotate rotates dpos[k] by Rtx, so 
> the correct geom position is really (dpos[k]*Rtx).  More simply, it can 
> be fixed by moving the dMassRotate block above the dMassTranslate 
> block.  This means that the mass's offset is really dpos[k].  I left 
> this code as is, until we agree that it is in fact wrong.

I think your code nicely demonstrates this.
centre of mass is completely wrong if translate precedes rotate.

> 4.) My new code calls dMassRotate above dMassTranslate, so it gets it right.

Yep.
In both cases (trf,off) the simulation looks realistic with your
rot/xlat order.

> 5.) To aid testing, I pushed apart the geoms with a *10 offset distance 
> in both old and new code.

This exposes the problems with c.o.m. much better.

Please commit your version, (with a reversed xlat/rot for the trf case)
and for sake of aesthetics, you may want to undo the factor 10 for dpos.

   Bram


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit 
 operating system originally coded for a 4-bit microprocessor by a 2-bit 
 company that can't stand 1 bit of competition."