MirrorJoints and IK Handles | Maya Python Tutorial

Building one side of a skeleton saves placement work, but a rig builder still needs a predictable way to create the opposite side and its IK handles. This lesson adds both operations to the existing Maya Python tool. Its most useful decision is the order: mirror the joint chains first, then create explicitly named handles for both sides.

The recording begins with an already constructed left-side skeleton and its naming convention. It does not rebuild that prerequisite or identify an exact Maya release. The endpoint is a set of working arm and leg handles in the example scene; animator controls, pole-vector placement, and a complete IK/FK system are outside this lesson.

Translate the manual arm operation into named endpoints

At 00:02–04:01, the instructor creates an IK handle manually by selecting the shoulder and wrist. The Script Editor history exposes the command, and the command reference is used to identify the start and end flags.

The script uses ikHandle with sj for the starting joint and ee for the chain endpoint supplied in this example. The arm call identifies the shoulder and wrist by name. Explicit names make the intended chain inspectable in the code instead of relying on whichever objects happen to be selected when a broader build function runs.

Priority and weight are inspected in the reference but left at their defaults. The lesson does not establish a custom solve-order strategy or explicitly choose a solver. Keep those omissions visible when extending the script: the demonstrated endpoint assignment is not evidence that every solver setting has been selected for a production character.

First test the arm in isolation within the controlled rebuild. Confirm that the handle exists and that moving it affects the intended chain. A handle appearing in the Outliner is a useful structural check, but its movement is what confirms that the named endpoints describe the intended limb.

Name each handle and adapt the leg call

During 04:01–07:10, the arm handle receives a deliberate left-arm name. The same operation is copied for the leg, replacing the shoulder with the hip, the wrist with the ankle, and the handle name with the left-leg equivalent.

These are three separate substitutions. Changing only the handle’s label would leave it operating on the old joints. Changing the joints while retaining an ambiguous name would make later control-building code harder to read. Check the inputs and the created name together.

The lesson repeatedly clears the test scene, recreates the skeleton, and builds the rig. After the leg call is added, it verifies two distinct handles. This gives the script a known left-side result before mirrored chains complicate the setup.

The names belong to this project’s convention. Retain the semantic roles—start, endpoint, and handle identity—when adapting the lesson to a different skeleton rather than copying literal names that do not exist in that scene.

Mirror the intended joint roots across the character’s center

At 07:10–10:04, the instructor uses Mirror Joints with the YZ plane, behavior mirroring, and a search-and-replace pair that changes the capital L_ prefix to R_. The resulting chains are inspected for right-side names and mirrored orientation.

The arm operation begins at the clavicle, while the leg operation begins at the hip. Choosing the root determines which descendants participate. It also explains why the early manual experiment does not reproduce the existing handles consistently: the lesson observes a different result when mirroring the leg root than when mirroring from above the arm handle’s start joint.

An attempt to mirror both selected roots together does not produce the intended operation, so the lesson applies the mirror separately to each root. The scripted version follows that explicit pattern rather than assuming one selected batch will behave identically.

The chosen plane and prefix replacement depend on the example character’s layout. Before copying the operation to another asset, verify that the character is arranged across that plane and that L_ actually identifies its left-side joints. Naming replacement does not by itself establish that a chain is anatomically on the expected side.

Mirror before creating any of the final handles

During 10:04–15:02, the build order is revised. A mirror-skeleton function runs before the IK-handle function. It calls mirrorJoint separately for the hip and clavicle roots, with mirrorYZ=True, mirrorBehavior=True, and a two-item searchReplace value containing the source and replacement prefixes.

This removes the need to depend on the differing handle-copy results observed during the earlier mirror experiment. Once both joint sides exist, the handle function can address each chain directly. The skeleton operation establishes the available joints; the handle operation establishes the IK relationships between named endpoints.

Verify the mirror stage before advancing: right-side joints should exist, their names should follow the expected convention, and the hierarchy should correspond to the left-side structure. If a right-side handle call later cannot find an endpoint, inspect this stage first rather than changing the IK call to whatever name happens to be nearby.

The recording uses a clean rebuild for these checks. It does not implement duplicate detection or a safe repeated-build strategy for an already completed rig.

Create and inspect the four explicit handles

At 15:02–16:15, the left-arm and left-leg calls are copied for the right side. The instructor chooses two explicit additional calls rather than introducing a loop or another helper for this small set. That is the implemented approach; a generalized side iterator is not part of the recorded result.

The final test recreates the skeleton and rig, then checks handles on both arms and both legs. For your own verification, inspect each created name and move one handle at a time. Confirm the corresponding limb responds, return it to its starting state, and repeat for the next handle.

This is also the point to distinguish joint mirroring from usable animation controls. Four responsive IK handles establish the solver connections demonstrated here. They do not yet provide a polished control interface, reliable elbow/knee steering, or switching between IK and FK. Those later layers can now be built against explicitly named handles and a predictable two-sided skeleton.