[ODE] Re: center of mass

[Geoff Carlton]

Nagymathe Denes wrote:

> I agree. I had to make my own as well. It's just a few lines of code, 
> but having a 'standard' version would make life simpler for many 
> people. :o)
> I've also added a new flag to the geoms to show if it's inside a 
> geomtransform. This allows some sort of automation as i can simply 
> call dGeomGetFinalPosition() for example, without having to care if 
> the given geom is an independent one or not.

If there are any changes to the core geom/body code itself (such as the 
addition of flags), it would be worth considering just supporting 
offsets properly.  I posted the idea way back when, with a fair amount 
of agreement and a small amount of disagreement.  I'll repost the 
concept below.  Since that time, I've implemented it on my local 
version, with some of the interface I suggested.  I never made a patch 
up though - its a rather large change mainly because currently geoms 
store a separate pointer to R and pos, but this change also tidies it up 
to storing a single posR pointer instead.  That reduces a pointer, which 
makes up for the addition of another posR pointer below.

------------------------------------------------------
Re: [ODE] PosR - a better way? [12/11/04] 12:36pm
------------------------------------------------------
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.


------------------------------------------------------
Re: [ODE] PosR - a better way? [12/11/04] 2:01pm
------------------------------------------------------
Well, in terms of the ode implementation its not that different at all, 
so its really a question of ease of use.

1.) Collision and queries are easier.
Instead of the collision being set up to return either the transform 
container or its geom (with caveats about its position), you get the 
actual geom itself.  No need for the "SetInfo" switch.  No need to 
special case "oh, if its a transform container, get the thing its 
holding".  Also its easier to iterate through a body's geoms, since you 
don't have the container geoms to worry about.  For a given geom you can 
simply query its offset (if it has one) from the body.

2.) Simpler to set up and understand
If you want to offset a geom, you don't need to detach the geom, attach 
a transform container, and point the container to the geom.  Instead, 
you just call a function on the geom itself.

The interface I'm thinking is the following:
   dGeomSetOffsetPosition()
   dGeomSetOffsetRotation()
   dGeomSetOffsetQuaternion()
   dGeomClearOffset()
   dGeomIsOffset()
   dGeomGetOffsetPosition()
   dGeomGetOffsetRotation()
   dGeomGetOffsetQuaternion()
Where the SetOffsetXXX() functions create the offset PosR if necessary.
I believe this way of dealing with offsets would be a substantial 
improvement to the ode interface.

Geoff