[ODE] PosR - a better way?

Jon Watte hplus-ode at mindcontrol.org
Fri Nov 12 09:29:54 MST 2004



> 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 

I find that I never need to actually get the thing it's holding, because 
the ODE information is inadequate to do anything real -- as it should be. 
The crucial piece of information is the user data of the geom, and the 
body of the geom (and ITs user data). These can easily be had from the 
GeomTransform. In fact, I don't understand why the info mode is there at 
all; it serves no logical purpose.

> 2.) Simpler to set up and understand

This may be true; I can't tell, because I think the current method is 
fairly natural and a good abstraction for the different cases. I've found 
that putting if()-s inside implementations usually lead to massive swiss 
army objects; it's generally better to factor implementation in different 
interface classes. GeomTransform accomplishes exactly this!

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

Why would you detach it in the first place? If you want to offset geoms, 
just put all such geoms in a GeomTransform in the first place. In fact, 
you likely have a wrapper on top of ODE, which can do that for you. 
Meanwhile, using the vtable to figure out that you want to perform a 
matrix multiply is faster than mis-predicting an if() branch half of the 
time, which is what you get with an additional, optional pointer.

> The interface I'm thinking is the following:
>     dGeomSetOffsetPosition()
>     dGeomSetOffsetRotation()
>     dGeomSetOffsetQuaternion()
>     dGeomClearOffset()
>     dGeomIsOffset()
>     dGeomGetOffsetPosition()
>     dGeomGetOffsetRotation()
>     dGeomGetOffsetQuaternion()

You think adding 8 new functions to the API of a geom is an improvement 
in the API clarity? I disagree. There's already perfectly fine functions 
for setting positions, orientations, and all that stuff. They operate 
polymorphically either on a stand-alone geom, or on a GeomTransform. This 
is proper object interaction design and decomposition. Your proposed 
solution feels like bloat to me.

Cheers,

			/ h+




More information about the ODE mailing list