利用者:Aligorith/Constraints 246

Introduction

The Constraints System in Blender has been refactored to be more easily extensible, have cleaner code, and be more powerful while increasing usability. Along the way, a number of constraints have been added. Also a few notable architectural changes have taken place, which have enabled a number of powerful features to be added.

Highlights of the new system include:

• Space Conversions for All Constraints
• Multiple Target support (only exposed for relevant constraints)
• New constraints - ChildOf, Transformation, and Script (i.e. PyConstraints)

Constraint Evaluation

The way constraints are evaluated has been cleaned up, so that everything is done in a single pass. All constraints (except IK and Rigid-Body-Joint constraints, which merely act as the interface for solvers which work after all constraints are done) are evaluated in the order they appear in their stack.

That means that each constraint is evaluated using the results of any constraints that preceded it, and that influence of each constraint blends between the result of that constraint and the result of those which preceded it.

Space Conversions

To enable constraints to be evaluated in order, while allowing for more control over which 'space' the constraint gets it's owner and target matrices for evaluation in, a space-conversion system has been devised. Before a constraint is evaluated, all the relevant matrices are converted to the right space (from World-Space) for the constraint to work on. They are then converted back to World-Space, ready for the next constraint.

On constraints where Space Conversions are relevant, settings to specify which space is used for the owner and (where applicable) target matrices are to be in for constraint evaluation.

The spaces available depend on the type of owner/target in question.

• For Objects:
  • World-Space - location is relative to the world-origin, and rotation/scaling are orientated according to the world axes
  • Local (Without Parent) - location is relative to the parent, and rotation/scaling are orientated with the parent's rotation/scaling factored out

• For Bones:
  • World-Space - same as for objects
  • Pose-Space - the effects of the Armature Object's transforms in Object Mode are ignored (Transform Properties shows this)
  • Local with Parent - 'pseudo'-local, except the parent bone's effects are still kept
  • Local - 'true'-local transform (relative to the bone's rest-position)

These settings can usually be found at the bottom of a constraint's panel (i.e. above the slider for influence). They are presented as one (or two where necessary) combo-boxes, with the left one for the Target, and the right one for the Owner.

Multiple Targets Support

The system now supports constraints which have an arbitrary number of targets. In the past, the system assumed that a constraint could have at most one target. This was severely restrictive, and prevented the ability to have multiple targets for PyConstraints. Another beneficiary of this improvement is the IK-Constraint, which uses parts of this support to ensure it's Pole-Target is treated properly.

Head/Tail (for Bone Targets only)

For constraints that require the location of the target as input, there is an extra Head/Tail option (it can be animated). It is only available for bones, as it defines what percentage (as a decimal) along the line formed between the Head (fat end) and Tail (pointy end) of a bone. The default value of 0.0 targets the Head, while 1.0 targets the Tail. Values outside of this range are possible too.

This allows certain (previously complex) setups become much easier to setup. For example, it is now possible to make one bone target the midpoint of another without requiring a few helper bones parented to various parts of the target bone.

Vertex-Group Targets

For Meshes and Lattices, there is now the option to specify a Vertex-Group to define the target of a constraint. The location and orientation of the 'target' is derived from taking the average location and normal of the vertices in the group. The target object's transforms are taken into account when doing so.

This reduces the need to Vertex-Parent some empties to groups of vertices, and then add Copy Location constraints to bones which use the empties as targets, in order to have bones affected by the vertices.

New Constraints

Several powerful new constraints have been added. These add some functionality that had been planned but missing from any releases, and also some often-requested functionality.

Script (aka PyConstraints)

This constraint allows constraints to be coded by the user in Python. For a script to be usable as a PyConstraint, it must be included in the file (to prevent problems with version incompatibilities).

PyConstraints can have multiple targets (as many as the script requires). They can also have their own set of settings, which are stored as ID-Properties and are also defined by the script. These settings can be accessed from the 'Options' button (if the scripter included code to do so).

To start creating a PyConstraint script, open a Text Editor window, and select the PyConstraint script template. This will create a new script with the necessary bare-bones code and instructions on what to do from there.

ChildOf

This constraint allows for animatable/multiple parenting relationships. It was part of the original design for constraints, although it was never implemented.

When creating a new parent relationship using this constraint, it is usually necessary to click the 'Set Offset' button after assigning the parent. This cancels out any unwanted transform from the parent, so that the owner returns to the position + orientation it was in before the constraint was applied.

There are also toggles to enable/disable individual transform channels from the parent affecting the owner. In practice, it is usually best to leave them alone, or disable all of the toggles for a particular transform.

Transformation

This constraint allows transforms to be converted from one type to another, and also from one range to another. Typical uses for this include gears, and rotation based on location setups.

The user-interface for this is a bit complex, but can be broken down quite simply:

• Left = Source (from Target) Transforms, Right = Destination (for Owner) Transforms
• Controls on Left: Ranges for each axis (x,y,z) of source transform
• Controls on Right: Which source channel (x,y,z) to read from for each channel, and range to map input range to
• Loc/Rot/Scale toggles control which transform to affect
• Extrapolate toggle is used to specify whether values outside of ranges should be extrapolated instead of just clipped

Limit Distance

This constraint defines a 'sphere-of-influence' around the target, which the owner is limited to being inside, outside, or on the surface of.

One of the uses of this constraint, is making an IK-effector 'stick' to the chain it controls. To do so, a helper-bone located at the base of the chain will be needed (to prevent cyclic dependency problems), and the chain should be parented to it (but not form a chain with it). The IK-effector should use this helper bone as the target for the constraint.

The recommended way to add this constraint is by using the Ctrl-Alt-C hotkey, as that will properly initialise the distance between the target and the owner. It is possible to do this by hand, but it is more difficult to get it right.

Improvements to Existing Constraints

Many of the existing constraints have undergone some changes which have made them more useful. This was in addition to a major restructuring of constraints code (which affected all existing constraints), which was needed to make it easier to add new constraints and maintain the code for existing ones.

Action Constraint

The Action Constraint has been rewritten to work in more situations, and also to use the new Space Conversions instead of devising its own set of calculations.

The most notable change is that the Location or Scale of the target can be used instead of being limited to just using the Rotation of the target. This has proved to be a powerful addition, which has been a crucial to the functioning of the rigs for the Peach Open-Movie Project.

Space Conversions mean that there can be more control over what values are used to drive the owner. However, they also highlighted the buggy nature of 'Local' option that has now been removed. As a result, rigs which depended on the buggy 'Local' option (i.e. the jaw of the 'Mancandy' character by Bassam Kurdali) broke.

Another notable change is that now Action Constraints can be used by Objects as well as Bones.

Copy (Loc/Rot/Scale) Constraints

All of the Copy Constraints now have an 'Offset' option, which allows the owner's original transform to be applied on top of the transform from the target. This allows the result to be tweaked.

Space Conversion support is used extensively by these constraints, allowing for more powerful combinations of copying. It is generally advisable to use the same space-type for both owner and target in order to receive sensible results, although other combinations can yield interesting results too at times.

Limit (Loc/Rot/Scale) Constraints

All of the Limit Constraints now have a 'For Transform' option. This option makes the constraint be used directly on the owner's transform results when transforming them, thus stopping the values in the Transform Properties panel from changing once the limit (in the right space) has been reached.

Space Conversion support is also used extensively by these constraints. As they have no targets, it's only available for the 'owner' space. They give more control over how the values are limited.

Crazy-Space (TM) Correction for Transform

Constraints such as Follow-Path, Clamp-To, and Child-Of can now be transformed without suffering from crazy-space problems. This is because an inverse correction for them is now applied when transforming an Object/Bone that has them.

Proxy Integration, UI tweaks, etc.

Proxy Integration

When a constraint exists on a bone that is proxy-protected, it is now possible to add a constraint to that bone that exists 'locally'. Previously, any constraints that were added would have been cleared away by the proxy-syncing that occurred when loading a file.

Constraints which are added in such a way, are tagged as being 'local' to the file. They will always be added to the end of a constraint stack, and will not be allowed to move above a proxy-constraint. This is to avoid the confusing situations when the constraints from the proxy-file change or when problems resolving the order of constraints on file loading.

In the UI, proxy-protected constraints can now not be renamed, moved, or deleted. In place of those controls, the name is drawn as a label, and a pair of icons (a ghost and a lock) are drawn. These have been used to indicate that they are proxy (ghost) protected (lock). Also, trying to change any of the settings of the constraint will simply result in a popup warning informing the user that the constraint is proxy-protected, and therefore cannot be edited.

Up/Down Buttons

In situations when a constraint cannot be moved either up, down, or both, the relevant buttons are hidden. This is a substitute for greying them out (this is not possible with the current UI toolkit), and helps to stop the user from doing what they shouldn't do.

Such situations include:

• Constraint is at top of stack
• Constraint is at bottom of stack
• Constraint is the first one after proxy-protected constraints