[ODE] test_boxstack and geom offset
bram at sara.nl
Tue Sep 12 01:30:56 MST 2006
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.
> 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.
In both cases (trf,off) the simulation looks realistic with your
> 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 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."
More information about the ODE