[ODE] Geomgroups vs composite

[skjold@cistron.nl]

> I think so.  I don't see how ODE could reasonably be ahead
> of you on this point because I don't think it would stoop
> to caching the uber-aabb for the body's geoms on the body
> itself (being the only common place to logically store it),
> since the aabb is collision business and bodies are just for
> simulation purposes.

Makes sense. That is exactly why I expected my callback to receive geom pairs that belonged to the same rigid body. But it just doesn't happen, I tried this with test_boxstack, at the start of nearCallback: if(b1 == b2) {puts("Bingo!"); return;}
There I thought to have a nice performance gain, but I never got to see Bingo in the first place :P The only way this could be prevented, the way I figure it, is if ODE purposely skips the callback for cases where the geom pair is tied to the same body (or, like you suggested, if the composite was implicitly kept in a new SimpleSpace - in which case the benefit for dSpaceCollide should already be there, automatically). In short: I expected indeed for collisions and dynamics to be strictly separate things, but if that is so then there would be no way to know for ODE which geoms belonged to a single composite (right?)


> 
> Thinking about it, it might actually make sense for ODE to
> keep an implicit SimpleSpace on each body for the geoms
> attached to it, if there wasn't an effort to keep simulation
> and collision distinct.  Also a lot of ODE seems to me to still
> be oriented around making life easy in the case where
> each body just has a single geom centred on it, with some
> quite large hoop-jumping needed for the more complex cases
> (geometry transforms, the centre-of-mass bug, and having to
> explicitly put a body's geoms into a space if you wish to benefit
> from an aggregate bounding box).

Exactly. Also, aside from the reason of keeping collisions and dynamics separate, I'm not sure of what overhead would be involved when creating a new SimpleSpace for each and every composite. Shouldn't be much though, but that's just a guess.


> 
> > I wouldn't mind being able to set user data on spaces
> 
> I haven't tried it, but since IIRC a Space just a subclass
> of a Geom, you should be able to just use dGeom{S,G}etData
> 

Heheh, I haven't delved too deep into the ODE source yet, but the first thing I noticed is that there are two definitions for dxGeom (a regular struct in geom_internal.h, and a struct being used as a class which derives from dBase in collision_kernal.cpp). That confused me enough to stay a way from it for a while longer :P. Anyway, as far as I could tell, dxGeom derives from dBase, and dxSpace also derives from dBase. Thus, dxSpace is not a subclass of dxGeom, but then again I could be wrong about the whole thing. :P