NEW IN R20
This value represents the position of the object in relation to the world coordinate system, or the parent coordinate system if the object lies within a hierarchy (see also Coordinate Manager).
This value represents the scale of the object in relation to the world coordinate system, or the parent coordinate system if the object lies within a hierarchy (see also Coordinate Manager).
Modifying the scale of the object using this value equates to scaling in Use Object Axis mode, i.e., the object’s axis system will be modified (see also The difference between the Use Object Tool and Use Model Tool modes).
This value represents the angle of the object in relation to the world coordinate system, or the parent coordinate system if the object lies within a hierarchy (see also Coordinate Manager).
This selection menu is only relevant for animators. The options in this menu can minimize the feared "gimbal locks".
Take a look at the following example problem:
We have a character set up for animation with complex hierarchies. Let’s say you want to animate the shoulder joint of the right arm in the front view with a presumably simple downward rotation. So we create keyframes for the fingertips in the up position and in the down position. If we now play the animation back and view it from the top, we will see that, instead of the expected downward movement only, the arm swerves slightly as well (at the top right of the image above). This is an example of the "gimbal lock" effect. Here it is relatively weak; but in extreme cases it can result in completely abnormal, corkscrew-type movements.
How can the proper rotation order help reduce this effect? All you have to do is have a look at the joint axes PRIOR to animating to determine which of the axes will rotate the least during the planned animation. In our example it’s the X axis marked on the left. Now select one of the Order options in which the X axis is on 2nd place. A very minimal and barely noticeable swerve still takes place but the result is far better than before.
Another option that helps determine which rotation order is correct is the Gimballing Rotation option. Enable this option and activate the Rotate tool:
Using the rotation bands you can see directly (PRIOR to animating) whether or not the planned animation will work in a given direction. At the left of the image above you can see red, green and blue rotation bands arranged in a manner that appears to make a rotation (red arrow) impossible (none of the bands lies on the rotation plane). This animation will have problems with gimbal lock.
Simply flip through the various Order options until one of the bands lies on or near the rotational plane (in the image above: blue). When you create the animation now you will have very few problems with gimbal lock.
A few additional comments regarding gimbal lock:
It’s always risky if you set the 2nd (center value in marked range below) value to approx. 90° (or 270°) in correlation with the rotation order:
It’s best to always set the corresponding value at or near 0°.
Traditionally, this problem can also be circumvented by animating a Parent Null Object.
Frozen selections, which can be found farther down in the dialog window, can also be helpful.
Surely you’ve heard of the feared Gimbal Lock in conjunction with character animation, for example - or have even experienced it personally!
Gimbal lock occurs when the rotational value has P +/- 90°, at which point heading H and banking B have the same effect. The result is that one of these dimensions is lost altogether and large rotational jumps occur even with the smallest of rotations.
The Quaternion function, which works only on rotation animations, can help.
By default, Cinema 4D uses the Euler Rotation to interpolate objects’ rotations (Euler: gyro-system for decoupled rotation (HPB), interpolation in Euclidian (right-angle) 3D space).
The Euler rotation’s individual components are interpolated individually, which means that the mean value from HPB (0, 0, 0) and HPB (60, 60, 60) would, for example, be HPB (30, 30, 30). The fact that a swing from 0, 0, 0 over 30, 30, 30 to 60, 60, 60 is not necessarily the shortest path can be tested in the Viewport.
What is needed is an interpolation that takes the shortest path from A to B, which is also what the user would do if the path had to be animated manually.
This is exactly what Quaternions do. A Quaternion will take the path from 0, 0, 0 to 60, 60, 60 via 35.104 °, 22.83 °, 35.104 °.
The Quaternion creates no unnecessary motion and thus avoids Gimbal Lock.
You might wonder why a Quaternion animation is not in principle applied to all objects. The reason is that Quaternion interpolation also bears disadvantages. The Quaternion works fine as long as the change in rotation is less than 180°. Beyond this, problems can occur due to the fact that the Quaternion will always look for the shortest possible path.
Take a look at the following example:
Enabling the Quaternion Rotation option activates the Quaternion animation for that object (the keyframe values will be identical Euler values and only the interpolation between the values will change accordingly). If this option is disabled, the Euler animation method will be used.
Note that Quaternion interpolation only works on local rotation tracks and not on frozen coordinates (see Freeze All).
A separate Quaternion Interpolation option is available in the keyframe properties that can be used to affect the interpolation temporally.
The following differences to Euler animations will result:
Quaternion animations should be used if:
Quaternion animations should not be used if:
This function will primarily be used for animations only.
In 3D, the freezing of objects is also referred to as "zeroing out" (or also "dual transformation") because the local coordinates Position and Rotation will each be set to 0 and Scale to 1 without changing the object’s position or orientation (in the following we will only refer to Position and Rotation). The same is achieved when you create a Null Object, position and orient it exactly as the object and make the object a Child object of the Null Object. This is the method that was used prior to R12 as a workaround.
You can picture the freezing of objects as follows: Internally, a Null Object with the coordinates of the selected object will be created. These coordinates will be copied to the Freeze Transformation tab and will function as an offset to the null coordinates, i.e., any modifications made to the primary coordinates will be taken into account by the frozen coordinates.
So what can this be used for? To explain we have to begin with the basics:
This scene contains two objects: Arm 2 has the local coodinates shown in the image above and is a Child object of Arm 1. The coordinates shown in the Attribute Manager are always local coordinates (they reflect the coordinate system of the Parent object in the hierarchy). So far so good.
We now want to animate Arm 2 so it rotates 45° around the X axis. Normally we would rotate the object using the rotation bands and set two keyframes:
The result can be seen at the center of the image above. Even though the rotation took place around a single axis all three axes were modified. This is due to the fact that the Parent object’s coordinate system (Arm 1) has a different orientation from the local coordinates. Often, this behavior cannot be avoided. And in the Timeline, three F-Curves, that may have to be modified, don’t make things any easier. In addition, our example also suffers from animation Gimbal lock (see Quaternion Rotation), which results in a subsequent rotation of the arm.
All of these adverse effects can be avoided by freezing the transformation PRIOR to animating. This will copy the Position, Scale and Rotation values to the subordinate values of the same name and set the initial values back to 0 and 1, respectively.
This bears the following advantages:
The Freeze All command will freeze all coordinates (Position, Scale, Rotation), i.e., all primary coordinates will be set to 0.
The main coordinates will be offset with the frozen coordinates. Subsequently all frozen coordinates will be reset to 0.
These are the frozen coordinates that are taken over from the parent hierarchy.
These buttons can each be used to individually freeze the three primary coordinates: