Normal constraints

 
 
 

A normal constraint constrains an object’s orientation so that it aligns with the normal vectors of a NURBS surface or polygonal surface (mesh). Normal constraints are useful for having an object travel across a surface that has a unique, complex shape. Without normal constraints, moving or animating the object across the surface could be tedious and time-consuming. For example, you might want to have a tear falling down along character’s face. Instead of animating the tear directly, you could constrain it to the face’s surface.

See Create normal constraints and Constrain > Normal.

Typically, you use normal constraints with geometry constraints. For more information on geometry constraints, see Geometry constraints.

Constrained object’s orientation for normal constraints

The constrained object’s orientation is controlled by three vectors: the aim vector, the up vector, and the world up vector. These vectors are not displayed in the workspace, but you can infer their effect on the constrained object’s orientation.

You do not need to understand the details of how these vectors work in order to use constraints effectively. If you are new to constraints, you can skip the rest of this section. However, if you want to exercise a high degree of control over a normal constraint, you’ll need to work with these vectors. Also, familiarity with these vectors can help you to understand how a constrained object can suddenly roll.

Note Normal constraints may have update issues if the aimVector and the upVector are colinear or if worldUpType is None.

The way that these constraints work is to rotate the object so that the aimVector points in the desired direction. Then, twist the object about the aimVector so that the upVector points as closely as possible to the worldUpVector.

If the aimVector and the upVector point in the same direction, then this second rotation is impossible. No matter how the object is rotated about the aimVector, the upVector will not get any closer to the worldUpVector.

This can be a useful effect since it allows the constrained object to aim in any direction without ever flipping. It rotates by the least amount so that the aimVector aims at the object and then it stops. However, it rotates from the current position so if you do not evaluate the same sequence of frames every time, you will not get the same answers. This can wreak havoc with your rendering and it is best to avoid this situation

Aim vector

The aim vector constrains the constrained object so that it always aligns with the target vector. The aim vector starts at the constrained object’s pivot point and then aligns with the target vector.

How the object rotates to align with the target vector depends on how the aim vector is defined relative to the object’s local space. For instance, by default, the aim vector is defined so that it points in the same direction as the local rotation positive X-axis. Consequently, by default, a constrained object’s local rotation positive X-axis will align with the target vector.

By itself, the aim vector does not completely constrain the object, because the aim vector does not control how the object might rotate about the aim vector. The orientation of the object about the aim vector is controlled by the up vector and the world up vector.

Up vector and world up vector

The up vector controls the orientation of the constrained object about the aim vector. Like the aim vector, the up vector is defined relative to the constrained object’s local space. By default, the up vector tries to point in the same direction as the world up vector, which is defined relative to the scene’s world space. The up vector orients the constrained object about the aim vector by trying to align itself as closely as possible with the world up vector.

When you move the target object(s), the constrained object’s aim vector moves to align with the target vector, and orients the constrained object accordingly. Simultaneously, the constrained object orients itself about the aim vector as directed by the up vector.

For instance, by default, the up vector is defined so that it points in the same direction as the local rotation positive Y-axis. A constrained object’s local positive X-axis will align with the target vector as directed by the default aim vector. Simultaneously, the object’s local positive Y-axis will try to point in the same direction as the world up vector, as directed by the object’s up vector. The aim vector and up vector work together to constrain the orientation of the constrained object.

By default, the up vector tries to stay as closely aligned with the world up vector as possible. However, you can control the role of the world up vector in a variety of ways. For example, instead of defining the world up vector relative to the workspace’s world space (the default), you can define it relative to some other object’s local space. Such an object is called a world up object.

Rolling effects

In certain situations, the constrained object can rapidly rotate about its aim vector. To understand why this happens, you need to understand how aim vectors, up vectors, and world up vectors work. If you are new to constraints, you can skip this section. For more information, see the previous section, Constrained object’s orientation for aim constraints.

As the aim vector approaches pointing in the same direction or the opposite direction of the up vector, the constrained object rotates more rapidly about the aim vector. When the aim vector points in exactly the same direction, or in exactly the opposite direction, the constrained object can suddenly rotate by 180 degrees about the aim vector.

These rapid rotations provide rolling effects that you might want to prevent. You can prevent rolling effects by moving or animating the world up vector. For more information, see Control motion history dependence effects for aim constraints.

Motion history dependence effects

Motion history dependence refers to how an object can provide different motion effects in situations that are identical except that the object has been previously manipulated or animated.

For instance, when you animate an object and run the animation in a loop, if the object ends up moving in slightly different ways at the same frame in each loop, the object is motion history dependent. At a certain frame, the object may be oriented differently depending on its previous orientations. In contrast, if the object moves in exactly the same way during each loop, then the object is motion history independent.

Motion history dependence effects can be a problem if you want predictable motion effects. However, if you are seeking some unpredictable motion effects, you might want to take advantage of an object’s motion history dependence.

In certain situations, a constrained object’s orientation can become motion history dependent. To understand why this happens, you need to be familiar with aim vectors and up vectors (see Constrained object’s orientation for aim constraints).

A constrained object can become motion history dependent if you define the aim vector and the up vector to point in the same direction. For example, you might do this if you define the aim vector relative to the constrained object’s local Y-axis, but do not change the default direction of the up vector, which is also relative to the object’s local Y-axis. For more information, see Control motion history dependence effects for aim constraints.

A constrained object can also become motion history dependent if you set the constraint’s World Up Type attribute to None. For more information, see Edit point constraint attributes.

Creative Commons License Except where otherwise noted, this work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License