← Learn library

Maya & Python Scripting / Character FX & Animation / Maya / Python

Automate Creating Curve Controls for your Rigs | Python Scripting in Maya LIVESTREAM

Channel: TD Superheroes ·

Written guide

Original TD Superheroes video thumbnail
Automate Creating Curve Controls for your Rigs | Python Scripting in Maya LIVESTREAMTD Superheroes · Video hosted on YouTube

Playing loads YouTube content. YouTube processes data after activation.

Watch on YouTube

If the player is blocked or unavailable, use Watch on YouTube.

Software: Maya, Python

This livestream builds a small Maya control-shape toolbox while exposing the decisions and mistakes behind it. The instructor starts with a linear arrow, adds a window, constructs several related curve shapes, and finishes with color, alignment, zero/offset grouping and reflection tools. The useful outcome is an understanding of how small scene operations become reusable functions and how those functions depend on reliable return values.

Maya 2022 is identified during the window demonstration. Familiarity with Python functions, lists, loops and Maya’s Script Editor will help. The examples operate on simple curves and test objects; they do not build or validate a complete character rig. The recording contains extended debugging, so the stages below follow the successful dependencies while retaining consequential failed approaches.

Establish one curve before building a toolbox

During the opening twelve minutes, the instructor contrasts two approaches. Copying a manually created curve command from Script Editor history into a shelf button quickly repeats a fixed shape. Writing a Python function makes the construction easier to organize and parameterize.

The arrow begins as a degree-one curve with an ordered list of points. Keeping the Y coordinate at zero places the demonstrated arrow in a plane. Each new point extends the path; the order of those points determines the outline. The instructor repeatedly creates the curve and checks the result instead of assuming that an imagined point sequence is correct.

He then replaces repeated coordinates with a length variable. The first attempt folds back on itself for some lengths. Adjusting the arrowhead coordinates relative to the requested length preserves the intended relationship between shaft and head. This is the first design lesson: changing a dimension requires updating all dependent coordinates, not just the most obvious pair.

For rapid iteration, the recording uses a helper that selects and deletes everything in the scene. That is a destructive test convenience, suitable only for a disposable test scene. Later, the instructor removes automatic scene clearing from the shape functions. Do not copy the development cleanup into a tool that will run on a character scene.

Build a repeatable window and read its field correctly

Around 12:02–30:02, a window-building function creates a named window and shows it. Rerunning initially produces a naming error. An existence check followed by deletion of the old UI allows the function to rebuild the window.

A column layout holds the controls. A first button prints a message to test its command; only then is a button connected to arrow creation. This separates a working UI callback from a working geometry function. If the button fails, first establish whether its action runs at all.

An integer field group adds a label and an arrow-length input. The instructor first queries a generic value flag, then finds that the grouped field requires the first field’s value, value1/v1. A subsequent “not found” error comes from a mismatch in the field name. Both errors concern retrieving the UI value, not curve geometry.

The repaired callback reads the field and uses its integer to create the arrow. A default of two is demonstrated. Negative input produces an undesirable shape, and input validation is deferred. Later, the length field is removed in favor of a fixed value when the tool is integrated. The livestream therefore demonstrates both a parameter experiment and a simpler final interface; it does not finish a robust, unrestricted length control.

Combine arrows and arcs through explicit object references

Beginning around 30:02, the curved double-arrow experiment combines two arrows with two partial circles. The circles use a 90-degree sweep, radii of four and two, and a normal pointing along Y. Translations and rotations place the pieces before attachment.

The essential dependency is the object returned by each creation operation. In this recording, the circle command returns a list, while the initial curve construction returns a direct curve name. Printing those values reveals the difference. The arrow function also needs to return its created curve so that the caller can move and attach it.

The first attachment attempt creates a plausible result but still reports an invalid-input error. Around 49:00, the instructor resolves it by passing the actual circle names from their returned lists rather than the lists themselves. A visible curve is therefore not sufficient evidence that the command completed cleanly.

Attachment creates a new result while retaining the input pieces. The script then removes those construction pieces. Track the result separately from the inputs: deleting the wrong reference would remove the control you intended to keep.

The following positioning work distinguishes the curve’s geometry, its pivot and its transform values. The instructor centers a pivot, experiments with moving the curve, and freezes transforms through makeIdentity. Some attempts move the object when he intended a different pivot behavior. These are specific construction experiments, not a general recipe for every rig’s coordinate system.

Integrate the shape functions and remove test side effects

Around 58:03–01:10:01, the curved arrow is brought into the window tool. It initially fails because the integrated copy of the base arrow function does not return the object, even though the separately tested version does. Restoring that return fixes the dependency.

This is a practical integration check: a function that works in a scratch tab may differ from the copy called by the UI. Test the actual callback path after moving code. Then remove the automatic scene deletion so that creating a second control preserves the first.

Labels and separators organize the growing window. A square is constructed as a single degree-one curve, closing its path by returning to its starting point. The instructor contrasts that result with Maya’s illustrated square construction containing several separate curve objects. The relevant inspection is whether the intended control is one selectable result, not merely whether its outline looks square.

Reuse the arrow to build double and four-way controls

From approximately 01:10:01–01:34:03, the tool creates two arrows, transforms one and attaches them. Mirroring only one axis gives an unwanted connecting segment because the curve endpoints no longer meet as intended. Applying the additional demonstrated axis flip produces the desired double-arrow connection.

For a four-way control, four base arrows are translated and rotated into place. The instructor corrects a misspelled variable, attaches the four pieces, deletes the inputs and centers the result’s pivot. The curved four-way variant adds four quarter-circle arcs between the arrows. A wrong arc orientation is corrected by changing the rotation sign.

These examples teach a useful construction order: verify the individual pieces, place them, inspect their endpoint relationships, then attach and clean up. A curve can have the right pieces in approximately the right places and still connect incorrectly. Keep the pieces visible during diagnosis instead of immediately deleting the evidence.

Resolve pivots and names before making the spiral variant

The next stage separates a single curved arrow from the earlier double-ended version. Around 01:44:01–01:51:00, attempts to set the pivot through guessed arguments produce errors or move the object. The instructor performs a pivot edit manually with command echo enabled, then uses the recorded rotate-pivot and scale-pivot information to guide the script.

The transcript does not establish an audited final pivot expression, so this article does not supply a replacement line of Python. The supported lesson is the diagnostic method: observe the manual command, distinguish a Boolean flag from position values, and check the resulting pivot separately from the shape.

A shared hard-coded name then causes two curve variants to interfere. The instructor assigns distinct names and uses the object returned by creation for subsequent edits. The single curved-arrow function also gains a return value. A further list-versus-name correction is needed before four of these curves can form the spiral control around 01:59:03.

This chain of fixes explains why reusable functions need consistent outputs. Callers cannot reliably position, rename or combine a shape if one function returns a name, another returns a list and another returns nothing.

Add colors and finish the shape collection

From approximately 02:00:07, colored UI buttons call one function with a color choice. The function reads the selected controls, finds a shape beneath each transform, enables its drawing override and assigns an indexed color. The demonstrated indices are six for blue, thirteen for red and seventeen for yellow. These are the recorded tests, not an RGB specification.

The button’s background color and the curve’s drawing override are separate mechanisms. A blue button does not color the curve until its callback finds and edits the appropriate shape. The debugging includes quoted string arguments, the missing mc prefix, capitalization and extracting a shape name from a list.

The demonstrated function uses the first returned shape. It does not establish support for arbitrary multi-shape controls or non-curve selections. Inspect which shape was changed before treating it as a general scene-coloring utility.

A box control follows a single ordered path around its edges, revisiting points to make the vertical connections. A circle command completes the collection, using the instructor’s preferred Y normal. The box point list is not reliably recoverable from speech alone; check the final code on screen when reproducing that particular outline.

Align controls and add zero/offset groups

Starting around 02:25:02, the alignment function reads translation and rotation attributes from the first selected object and writes those values to items in the selection. The simple test succeeds. This establishes a channel-copy tool in the demonstrated scene, not a general world-space alignment solver for objects under different parents or joints with additional orientation information.

The grouping tool handles each selected control separately. It reads the control’s placement, creates empty zero and offset groups, parents offset beneath zero, positions zero, and parents the control beneath offset. The first empty-group attempt fails until the correct empty-group option is found. The parent argument order is also reversed once, then corrected.

By approximately 02:39:02, the demonstration has a zero group containing an offset group containing the control. The control shows zeroed channels in that example. Inspect the hierarchy and the control’s placement together: a zeroed control that jumped away from its intended location is not the same successful result.

Reflect the selected hierarchy and check the remaining limits

The final tool creates a temporary empty group, parents a selected item beneath it and applies negative scale on the requested axis. The instructor recommends selecting the zero group for the control hierarchy. Duplication is a separate action; the reflection operation itself moves the selected result rather than automatically creating its opposite-side partner.

Temporary groups initially remain in the scene. The last correction unparents the item to world and deletes the temporary group. At approximately 02:48:02, the instructor tests reflections on different axes and confirms the cleanup in his example.

That workflow does not demonstrate restoration of an arbitrary original parent, production rig naming, selection validation or safe repetition on every hierarchy. Before adapting it, inspect the resulting parent, transforms and remaining nodes in a disposable scene. The same principle applies throughout this toolbox: test geometry, returned object identity, pivot, hierarchy and UI behavior as separate outcomes. The livestream provides a working development path and specific debugging examples; it is not independent certification of a production-ready rigging package.