Biped Character Rig Part 25 - Space Align Switch

A space switch changes which part of the rig a control follows. This lesson builds two related examples: a head control that can align with the chest or the world, and an IK hand control that can follow the pelvis, chest, head, or world. The head example changes orientation behavior; the hand example uses a parent constraint to change its positional and rotational reference.

The work starts from the existing biped rig, including its controls, offset groups, and bind joints. The exact Maya release is unidentified. This is a demonstration of discrete space choices, not a completed system for matching the current pose when switching during animation. The opposite side’s setup is also left for work between lessons.

Make a head reference that follows position without following rotation

At 00:00–02:03, the instructor locates the head control in the Outliner, duplicates the head joint, and unparents the duplicate. Descendant joints and the copied constraint are removed so that only the intended reference joint remains. It is renamed to identify its world-alignment role.

The bind head joint becomes the target of a point constraint on this reference. Select the bind head first and the reference second, then create the point constraint. The demonstrated result is a reference that stays at the head’s position while retaining its world-relative orientation as the chest rotates.

Position following and rotation following are deliberately separated. A reference that inherits the chest’s rotation would not provide the alternate orientation needed for this switch. Inspect the reference while rotating the body: its location should follow the head, but its axes should retain the intended world alignment.

The recording starts from a prepared joint orientation. It does not show a general procedure for normalizing an arbitrary duplicate’s orientation. Confirm the reference’s actual axes rather than assuming that a new name makes it world aligned.

Apply the orientation relationship to the head’s offset group

During 02:03–03:02, the reference drives an orient constraint on the head control’s existing world-offset group. The constraint is not placed directly on the animator’s head control.

This gives the parent group responsibility for the selected alignment while leaving the control as the animator’s input. In the recorded test, enabling the constraint keeps the head aligned with the world as the chest turns. Disabling its contribution returns the head to the ordinary inherited chest behavior.

Test both states before adding the interface attribute. If the constrained group or reference is wrong, an attractive menu will only hide the wiring problem. The source demonstrates the result in this rig; it does not test every possible hierarchy or constraint configuration.

Expose the two head states as an enum

At 03:02–05:00, the instructor adds an enum attribute called Align Space to the head control. Its entries are ordered Chest, then World, corresponding to values zero and one.

The Connection Editor connects that attribute to the orient constraint’s weight. In this demonstrated arrangement, zero leaves the head following the chest and one enables the world-alignment relationship. Because there are only two states and one controlled weight, the enum values can be used directly.

Switch to Chest and rotate the chest; then switch to World and repeat. The expected difference concerns head alignment, not whether the head remains spatially attached to the character. The point-constrained reference supplies that positional continuity.

After checking the head, the instructor organizes the reference with the rig’s joints. Recheck the behavior after organization, since putting a world reference under a rotating parent could change the relationship that was just established. The transcript does not fully describe every organizational node’s transforms.

Build and test the hand’s three constraint targets

During 05:00–08:10, the pelvis, chest, and head become targets of a parent constraint on the IK arm control’s offset group. The recorded operation explicitly has Maintain Offset turned off. Inspect the starting placement when following that choice; the lesson does not establish that the same option is appropriate for differently placed controls in another rig.

Before connecting a menu, the instructor tests the target weights manually. Only one target contributes at a time. With all three weights at zero, the hand remains in the demonstrated world-space state.

Hand space	Pelvis weight	Chest weight	Head weight
Pelvis	1	0	0
Chest	0	1	0
Head	0	0	1
World	0	0	0

These are the endpoint states demonstrated in the lesson. World is represented by removing the three target contributions in this particular hierarchy; a fourth world target is not created.

Check the dependency of each selected target, rather than expecting every other control to be irrelevant. For example, when following the head, a chest movement that also moves the head can still move the hand. The instructor contrasts that inherited relationship with pelvis movement that is independent in the prepared rig.

Use driven keys to map four choices to three weights

At 08:10–11:24, the hand receives an enum with Pelvis, Chest, Head, and World in that order. Unlike the two-state head attribute, the values zero through three cannot directly represent the three separate constraint-weight settings. Set Driven Key supplies the mapping.

Load the hand control as the driver and its alignment enum as the driver attribute. Load the parent constraint as the driven object and select its three target-weight attributes. For each enum choice, set the complete weight combination shown in the table and key it.

The instructor starts with World and all weights zero, then keys Pelvis, Chest, and Head. When changing from one target to another, the previous target must return to zero as the new target becomes one. Leaving a previous weight enabled creates a blended state instead of the intended single reference.

The recording briefly considers making World the default but retains Pelvis as the first enum entry. It does not demonstrate a successful default change. It also does not establish an animation workflow for interpolating or matching poses between the discrete choices.

Verify the menu through actual control movement

During 11:24–13:33, each hand-space choice is tested by moving or rotating the relevant body control. Pelvis follows the pelvis, Chest follows the chest, Head follows the head, and World remains in place while the body controls move in the demonstrated tests.

Inspect the resulting motion as well as the displayed menu value. A menu can change while driving the wrong constraint, and an unkeyed target weight can leave two spaces contributing. The earlier manual tests provide a known comparison for diagnosing either problem.

The lesson ends with one side ready for the corresponding setup on the other side. It does not show no-pop switching in an arbitrary animated pose, a pose-matching command, or tests across the full animation range. Keep those production requirements separate from the verified endpoint behavior of this space-alignment lesson.