If only the “rotateZ” is present for a node’s animation, then what are the values for X & Y rotations? Or do I just concatenate a z-rotation matrix to the node’s matrix-stack specified in the “library visual scenes” area?
Also, pertaining to animation data…previously I thought rotations/scales/translations contained only one field(x,y, or z). I just saw how in the animation data I can get a “translate” stream that specifies ALL 3 values (x,y, and z). Can this occur with rotations and scales as well? Can you think of any other cases for data streams that I might be missing?
You cannot animate something that does not exist in COLLADA, since you cannot target it.
Also, pertaining to animation data…previously I thought rotations/scales/translations contained only one field(x,y, or z). I just saw how in the animation data I can get a “translate” stream that specifies ALL 3 values (x,y, and z).
Can this occur with rotations and scales as well? Can you think of any other cases for data streams that I might be missing?
yes, same for rotation where you can the ANGLE (single value), or the float4 vector (if targeting the object without the postfix). You can also target an element of the axis (X or Y or Z) - for example when animating the axis from a key-frame, using 3 channels.
Regarding your answer to my first question, “You cannot animate something that does not exist in COLLADA, since you cannot target it”.
I might be misinterpreting something here, but I just wanted to rephrase this. The joint in question definitely exists as I can see it in the library-visual-scenes section in the dae-file. In the animation section there’s only 1 stream for this node(or joint) and it is of type rotateZ. With this said, what values do I use for the translational(x,y,z) and rotate(x,y) if I were to try to animated this joint? Or maybe I just take the node’s animation stack specified in the library-visual-scenes section and multiply that by a rotateZ matrix?
This is not a type, this is an identification. You will have to look up the corresponding element to know its type.
Most probably you will find a <rotate> element in this particular case.
“With this said, what values do I use for the translational(x,y,z) and rotate(x,y) if I were to try to animated this joint? Or maybe I just take the node’s animation stack specified in the library-visual-scenes section and multiply that by a rotateZ matrix?”
You will replace the values in the animated element (here the <rotate> element) and evaluate the matrix stack again to know the position of the <node>.
“You will replace the values in the animated element (here the <rotate> element) and evaluate the matrix stack again to know the position of the <node>.”
Can you describe how I evaluate the stack with the animated node values? The only time I’ve evaluated the stack is when I am going through the actual visual-scene-nodes.
Please disregard the last post. I think I get it now – substitute the node’s animated key-data in the order it appears in the node’s matrix-stack.
Now, in our engine we collapse these Collada matrix-stacks for each joint leaving just one matrix for a base-pose per joint. If I do this substitution process for each joint in real-time the calcs are going to add up quickly. Any ideas on trimming the # of matrix multiplies down? I know in max you can reset transforms – does this help the matrix stack to be scaled down?
Have you tried to collapse a <node> transform stack into 3 pieces like this?
C1 * A * C2
where C1 and C2 are const and precomputed; A is your animated transform. For example if you have a node with a complex transform stack and only the rotate is animated:
Another way of implementing the same idea, is to write a conditioner that does this off-line, creating multiple <node>
This way you can prepare the data for the run-time. You can mark the constant transforms with type=“Constant” and the animated ones with type=“Dynamic” (or similar conventions) for example:
