[ODE] PosR - a better way?

Jon Watte hplus-ode at mindcontrol.org
Thu Nov 11 18:33:59 MST 2004


How is this materially different from just keeping the GeomTransform?

Cheers,

			/ h+


-----Original Message-----
From: Geoff Carlton [mailto:gcarlton at iinet.net.au]
Sent: Thursday, November 11, 2004 5:37 PM
To: Jon Watte
Cc: ode at q12.org
Subject: Re: [ODE] PosR - a better way?


Ok, I've had another look at it (and read through Jon's comments a few 
times), so how about this suggestion.

Currently Body aggregates a PosR, and Geom has a ptr to either its own, 
or the Body's.  We keep all that, but Geom has an extra ptr to an offset 
PosR or null (I'll call it offset_ptr below).

Case 1: Geom by itself  (As we have now)
Geom ptr to a PosR.  Geom offset_ptr is null.

Case 2: Geom on body, no offset (As we have now)
Geom ptr to body's PosR.  Geom offset_ptr is null.

Case 3: Geom on body, with an offset (Replaces GeomTransform)
Geom ptr to a PosR (the final position).  Geom offset_ptr to another 
PosR.  Thus in this case the geom has 2 extra PosR, in addition to the 
body's PosR.

Case 4: Geom by itself, with an offset
Not allowed?

In the ComputeAABB, if the geom's offset_ptr isn't null, we update the 
Geom's own PosR using the body and offset.  Or we could  have a seperate 
"dirty" flag, rather than merging with the aabb flag.

If we change whether a Geom has an offset (via dGeomSetOffsetExists or 
whateverwe'll alloc or free the extra PosRs.

There is no copying of PosR around the place, and no redundant 
recalculations.  Its identical in the current cases, except for one 
additional pointer which is null, and an occasional dirty flag check (in 
computeAABB, and probably GeomGetPosition etc).  Thus, it doesn't avoid 
allocs/frees, and its actually very similar in implementation to 
GeomTransform.  I think however that its nicer than having a seperate 
geom just for the offset.

We wouldn't need the collide check of pretending the geom is the 
encapsulated one or the transform itself, we'd just have the straight 
geom.  The interface could be nice and simple: dGeomSetOffsetExists(), 
dGeomSetOffsetPosition(), dGeomSetOffsetRotation() etc.

So to my mind, its seems just as good as the current implementation in 
terms of efficiency, but much nicer to actually use.  Its pretty easy to 
do, because its just shifting the tiny amount of transform code into a 
common function.

Geoff







More information about the ODE mailing list