[ODE] Locators - Center of mass

[Remi Ricard]

Hi,

> selwakad at comcast.net wrote:
>   
>> having the center of mass not equal to the body origin is a great idea.
>> it will make it possible to integrate keyframe animations with physics.
>>     
> Two main problems are:
> 1.) There is nothing gained except a bit of convenience.
>   
I think it can be alot of convenience.


> 2.) It would add overhead to all users.  (I think).
>   
Yes there could be some overhead, this is possible but:
1- if I do it I will try to decrease the overhead as possible.
2- We can enclose the overhead between #ifdef #endif
   So if someone want it. it can be enabled.


> If you look back on discussions with geom offsets, you will see that 2 
> is a killer.  It means it just won't happen.
>
> Now, consider a 1m high barrel sitting on the floor, with some liquid in it:
>   geom pos = cylinder centre = (0, 0, 0.5)
>   body pos = centre-of-mass = (0, 0, 0.35) 
> But you might want to measure entities from their "feet".  Well, you'll 
> need to store an offset and do this:
>   my pos = geom.pos + geom.R * (0, 0, -0.5)
>
> But then you might have a panel on the side that is generating sparks.  
> That is a second point, one with rotational significance.  Perhaps a 
> crane picks up the barrel near the lid, requiring a third location point.
>   

My point is, you should let the user decide where to set it  Body frame 
w.r.t the center of mass (Only one frame)
Usually the user knows which one will make its life easier.  You will 
still need to keep some internal data
(radius of barrel, length of barrel but this can be outside ODE.

What you are talking about is more about Scenegraph and Scenepath and 
this does not "touch" the physics part.



> Well, if we are going to make it easier to do one of these, we may as 
> well support them all.  One way would be for a new type of geom, a 
> "locator" or "location" type.  You'd create these in a null space, 
> attach them to the body, and not collide them with anything.  Using 
> existing geom offsets it would then make it trivial to get their real 
> world position.  The advantages of this are:
>
> 1.) Supports more than one "special" location point.
> 2.) Supports rotation as well as position.
> 3.) Supports dynamic adding and removing of locations.
> 4.) Shares much of the same offset API and has all the support functions 
> for world/offset getting/setting.
> 5.) It is a very simple change, as it hooks into the existing offset 
> code and is a pure addition.
> 6.) Fairly CPU efficient, it only recalculates orientation when dirty, 
> also returns position etc by reference.
> 7.) Fairly memory efficient, it stores the offset+final posr as well as 
> some extra geom housekeeping.  For cases where the locator is at the 
> body's origin it doesn't even store the transforms.  Unfortunately it 
> does store the rotational part even for pure positional locators.
> 8.) Zero overhead for other users.
>   
> The only issue with this is it doesn't make things "just work" (I want 
> my barrel at (0,0,0) dammit!).  But for real world cases, it seems 
> pretty useful.
>   

If someone wants to do it I have nothing against that.

Talking about the memory used. There should be no change since dMass has 
already the position of the center of mass.
We should just use it.



Remi