Creating an IK FK Skeleton in Maya with Python

This lesson duplicates the existing generated skeleton into IK and FK versions, gives their joints distinct names and organizes the copies for later rigging. It prepares the joint structures needed by a future switch. It does not build IK handles, animation controls or a working IK/FK blend in this recording.

The starting tool already creates a movable proxy, mirrors its placement and converts it into a parented skeleton. This extension depends on that tool’s names and hierarchy. The exact Maya release is not established.

Add a new build stage and inspect duplication

During 00:00–05:02, the instructor adds a Create Control Rig button and a corresponding function. The first implemented action duplicates the pelvis hierarchy.

Giving the duplicate a new root name does not rename all its children. The instructor sees matching child names in the two hierarchies, which would make later name-based script operations ambiguous. He enables the duplicate command’s rename-children behavior, producing distinct child names in the example.

Inspect the entire duplicated hierarchy rather than just its root. A new pelvis name is not proof that the descendants now follow an IK or FK naming convention.

Apply names, then reuse the operation

Around 05:02–13:02, the script selects the duplicated hierarchy, stores its joints and loops over them. A string replacement prepares an IK-style name from the automatically suffixed duplicate name.

The first test changes no scene names because it only constructs the replacement string. Adding the actual rename operation makes the intended names appear. This is a useful distinction in scene scripting: computing a name and assigning it to an object are separate actions.

The code is moved into a helper with arguments for the source and the search/replace naming rule. The instructor works through leftover parameters and variable references while refactoring, then calls the helper again for the FK version.

The example assumes the particular numeric suffix produced in its test scene. It does not implement robust naming for repeated runs, existing collisions, namespaces or arbitrary long paths. After duplication, inspect the actual returned or selected names before relying on a suffix-based replacement in another scene.

Separate the IK chains before removing unwanted branches

From approximately 13:02–17:00, the IK copy is divided into the intended sections by unparenting the pelvis, hips and shoulders to world. The instructor then removes selected IK-copy branches at the clavicles, palms and balls of the feet, leaving the sections he intends to control separately later.

The order matters. The required shoulder and hip chains must be separated before removing surrounding branches. Inspect which skeleton copy and which descendants are affected; this is destructive hierarchy editing within the duplicated IK structure.

A deletion initially fails because the script uses a shortened ball-of-foot name that does not exist. Updating it to the actual name resolves that error. A plausible anatomical label is not a substitute for the identifier used by the generator.

Group the chain roots without flattening the hierarchy

Around 17:00–21:04, the instructor tries grouping everything matching an IK name pattern. That gathers too much of the hierarchy and produces an unwanted parenting result. He replaces it with explicit grouping of the intended chain roots.

This is the key organization lesson: selecting every descendant and grouping them is different from grouping the roots that already contain those descendants. Inspect the internal elbow/wrist and knee/ankle relationships after an organizational change, not just the presence of a group named IK.

The FK version keeps its complete hierarchy and is grouped from its pelvis root. The IK and FK groups are then placed in the existing joint organization. The two copies intentionally have different structures even though they began from the same generated skeleton.

Verify what the lesson actually finishes

In the closing section, the instructor inspects the copies and reports that the earlier orientation information has been retained. He also acknowledges a joint whose orientation will need attention in a future lesson. The copies therefore preserve the source skeleton’s limitations as well as its useful setup.

Review three outcomes separately: the joint copies exist, their identifiers distinguish IK from FK, and their hierarchy matches the intended chain organization. This source does not show them driving the original skeleton or switching between two animation systems.

The reusable technique is to duplicate an inspected base, rename its full hierarchy and organize the copies according to their later purpose. A button called Create Control Rig is only the entry point to that developing workflow; at this checkpoint it produces skeleton preparation, not a finished control rig.