i’ve gone over the spec many times, and no where does it say in what coordinate system the mass_frame and velocities are defined in rigid_body and instance_rigid_shape.
There is a small vague comment on instance_rigid_body:
Defines the center and orientation of mass of the rigid-body relative to the local origin of the “root” shape.
What is the “root” shape?!?
What is the coordinate system of a rigid body?!
The COLLADA book on page 159 says this:
The ‘parent’ is a reference to a <node> in the <visual_scene>, using its id. This allows a physics model to be instantiated under a specific transform node, which will dictate its initial position and orientation…
So does that mean that all the ‘target’ attributes in <instance_rigid_body> do not set the initial position and orientation of the rigid_body? do all rigid_body instances start with the identity transformation?!
any help would be most appreciated, since we don’t want to get this wrong
For the accurate answer read the above pages. For the short answer:
The local space where the center of mass of the object is at the origin.
Momentum calculations are done in this space so picking axes and scaling or skewing them can effects how external force and torque is applied to the rigid body.
>>> What is the “root” shape?!?
>>> What is the coordinate system of a rigid body?
I think that the physics scene description is like an overlay onto the normal scene hierarchy where the graphics is. So when you define your stuff it is always either relative to what you are attaching to in that other scene, or relative to the parenting container you are in. When you attach to something in the other scene you gain their world space and you define your matrices(frames) relative to those, just like in graphics each animation node is defined in local space relative to their parent’s world space (and where world space is computed by the series of local spaces). So the mass frame is relative to the world space of the nearest parent container…just like graphics. It is done this way so that you can move an ancestor’s local space and affect your world space and all child world spaces without having to touch tons and tons of objects.
I’m afraid if that isn’t enough you’ll want to read a book like Real-Time Rendering. http://www.realtimerendering.com/ or research more on scene graphs and scene hierarchy.
COLLADA declares most everything in local object coordinate systems so that they are flexible and resuable. In the case of mass_frame, it’s in the local origin of its rigid_body, as stated on pdf page 234 of the 1.5 spec…
This statement is phrased differently then that for rigid_body (unfortunately), however it is meant to convey the same meaning. The child elements that instance_rigid_body shares with rigid_body are overrides. This is stated on pdf page 214 in general terms.
The root shape is the union (total volume) of all the shapes of the rigid_body. Since the shapes are in the rigid_body’s local coordinate system, the local origin is that coordinate system.
This is defined by the instance_physics_model in which the rigid_body is ultimately instantiated, as you surmise later in this thread. The physics_model by itself has a local coordinate system that through any defaulted instantiation is the visual scene’s (world) coordinate system. The parent attribute provides the means to place the physics_model in a node’s coordinate system. Please reread the rules for this on pdf page 211.
No, these targets are unidirectional from physics to visuals.
thanks for the answers. in that case, are we understand that:
all instance_rigid_body objects of the same instance_physics_model will share the same coordinate system? however with the visual node hierarchy, child nodes have their own coordinate system different from their parent node.
in that case assume that we have a node1->node2 relationship where node1 is at the origin and node2 is at (0,0,10) in node1’s coordinate system. then we also have two rigid bodies: ‘body1’, ‘body2’. ‘body1’ targets ‘node1’ and ‘body2’ targets ‘node2’. Both body1 and body2 belong to a instance_physics_model whose parent node is node1. Therefore, body1 and body2 start with node1’s coordinate system. And once the physics simulation starts, body2 will set the visual node2 to (0,0,0)?
Yes. See pdf page 212 of the 1.5 spec for details. It’s possible to kinematically move the physics model indirectly via its parent attribute.
If … body2 is dynamic, and its mass frame is [0,0,0], and the physics simulation hasn’t compensated wrt body1, then yes I think that would be expected behavior from the declarations in the .dae document.