Creating Text Curves | Maya Python Rigging Tutorial

An editable skeleton is easier to place when the user can see what each joint represents. This lesson adds text-curve labels to the placement stage of a Maya auto-rig, makes the labels follow their joints, and removes them when the final hierarchy is built. It also releases the temporary center-joint placement restriction and clears the selection at the end of each action.

The tool already creates center joints and later parents them into a rig. The recording extends that workflow rather than supplying the complete builder. Its exact Maya release is unidentified, and the generated text-node naming shown in the example should be inspected before being reused in another environment.

Create the label alongside its joint

At 00:01–03:01, the instructor proposes labels for the placement joints so that users do not have to infer each joint’s role while moving it. A separate text-creation function is considered, but the implementation places the work directly in the existing per-joint creation code.

That location already has the information needed to label the joint. The long expression that builds the joint name is first assigned to a variable, then reused where the joint is created. A clean test confirms that this small refactor still builds the original skeleton before text generation is added.

This is a useful sequence for extending a working tool. First make the existing data easier to reuse, verify that behavior remains unchanged, then add the new operation. If joint creation and label generation were both changed without an intermediate check, a later error would have more possible causes.

Keep the readable label separate from the generated node name

During 03:01–07:01, the lesson uses textCurves to create the label. The first version includes more of the internal naming convention than the instructor wants to show. It is revised so that the visible text is a readable part name, such as “hips,” while the generated node name retains a text_ prefix for code and cleanup.

This separates two audiences. The artist needs a short label that communicates a joint’s role. The script needs an identifiable scene object. A long internal name can be useful for the latter while making the former harder to read.

The instructor also adds an underscore at the naming boundary after inspecting the generated text objects. In this recorded setup, the subsequent lookup is constructed using an appended Shape suffix. That is an observed naming dependency in this script, not a universal guarantee that every textCurves result will have the same hierarchy or suffix.

Inspect the created objects before adapting the lookup. A curve label can exist visibly while a later command still addresses the wrong generated node name. The transcript does not provide a general return-value-based replacement for this naming approach.

Parent the text, then zero its local translation

At 07:01–09:00, the generated label object is parented under its joint. Its local translation channels are then set to zero so the label sits at the joint’s location in that hierarchy.

Parenting and zeroing have different jobs. Parenting establishes that the label follows the joint. Zeroing the local translation places the label at the intended local origin instead of retaining an offset from where the text was originally created.

The lesson tests the result in the viewport: the text appears beside the joint and accompanies the placement setup. Clearing that setup also removes the labels because they are children of the joints being cleared. This is a useful benefit of matching the temporary label hierarchy to the temporary placement hierarchy.

Verify the label’s association by moving a placement joint and checking which text follows it. A label that looks nearby in the initial pose can still belong to the wrong joint if a copied reference was not updated.

Remove placement labels and release the center restriction

During 09:00–12:01, the build stage is extended to delete the temporary text and unlock the center joints. The label deletion uses a wildcard matching names that begin with text_.

That works within the demonstrated test scene, but the pattern expresses a naming convention rather than ownership. Before using it in a larger scene, inspect what it matches. The lesson does not implement a registry that distinguishes this tool’s labels from unrelated text objects with the same prefix.

The unlock-center function is copied from the earlier lock-center logic, then changes the relevant settings: lock becomes false, keyable becomes true, and Channel Box display becomes true. These are separate properties. The purpose is to remove the temporary restriction used during center-joint placement, not to leave the final hierarchy constrained by the placement interface.

The instructor builds the rig and checks that the labels have disappeared and the previously restricted joints can move. Both results matter. Removing labels does not prove that the channel states were updated, and an unlocked joint does not prove that all temporary guides were cleaned up.

Leave both actions in a clear final state

At 12:01–13:23, the lesson adds a clear-selection call to the end of both Create Skeleton and Create Rig. The user can then see the result without a leftover selection implying that one particular object is still the next required input.

The final test runs the complete placement-to-rig sequence. For the placement stage, check that every intended joint has the correct readable label and retains the intended temporary center restriction. For the rig stage, check that the hierarchy is assembled, labels are removed, the relevant channel states are released, and nothing remains selected.

This completes a small but concrete usability layer. The labels are temporary guidance for positioning, and the build action is responsible for removing that guidance while restoring the final joints’ intended behavior. Broader naming robustness and full-rig animation validation remain outside the recorded change.