Camera Rig Manager for Maya
A broadcast-grade camera rig in one click, with the export contract built in from frame zero.
timewarpScale attribute
STEP 2
TimeWarpController.py
Authors the slow motion and bakes speed onto timewarpScale
STEP 3
CamRigBake.py
Exports a clean world-space camera carrying timewarpScale to Unreal
Every studio rebuilds the same camera rig, badly, once per project. Someone hand-builds a hierarchy, someone else adds a focus control that does not match the lens, nobody locks the channels, and three shots in an animator has rotated a group that was never meant to rotate. Then export breaks, because nothing about the rig was ever designed to leave Maya.
Animators should spend their time framing shots, not rebuilding rigs or repairing views. I wanted a one-click rig that an animator could pick up and shoot with, stable every single time. And I wanted to build it the way I now build tooling: by directing an AI against a precise spec and testing every result myself.
Full rig, one button. Eleven named controls from world container down to camera shake, each a NURBS curve shape-parented onto its own transform, color coded by function, scaled to read at shot distance.
Separated concerns by design. Root position, root yaw, and root pitch place the tripod. Truck and dolly move the body. Yaw, pitch, and roll are the operator's head. Shake is handheld and noise. Every tier does one job, so nobody fights over a channel.
Channels locked to intent. Each control exposes only the axes it is supposed to drive. Roll offers rotateZ and nothing else. Truck and dolly offer X and Z. Everything else is locked, hidden, and unkeyable, so the rig cannot be broken by accident.
Lens control in one place. Focal length, focus distance, fStop, and a depth of field toggle all live on the world container and pipe directly into the camera shape. Film back auto-syncs to the render aspect ratio, so the frame you compose is the frame you render.
Focus you can see. A dedicated focus control drives focus distance through a distanceBetween node, and a live focus plane draws itself at the correct size by solving true vertical field of view from film aperture and focal length. Pull focus by moving an object in space, not by guessing at a number.
Blendable look-at, from 0 to 100. A weighted orient constraint blends between free aim and a look-at target, so you can ease into a lock-on and back out again.
A viewport you can trust. Every rig opens a floating 960x540 window driven by a hidden viewer camera that is parent-constrained to the shot camera, with its lens attributes slaved live. Transforms are locked, and NURBS curves and locators are hidden in that panel. It shows the shot, only the shot, and it cannot be tumbled out of alignment.
A manager, not just a builder. The UI lists every rig in the scene, selects any control by name, and switches to the correct manipulator as it does. Click ROLL and you are in the rotate tool. Click TRUCK_DOLLY and you are in move. Closed a viewport by mistake? Reopen it from the same panel.
Every decision below exists because someone tested this rig inside Maya. Some were specified before the first line was written. Others came from builds that worked exactly as specified and still broke in use.
Roll and shake survive a full look-at lock. They are parented below the look-at blend group, not above it. A naive aim constraint eats operator roll and handheld shake the moment the blend reaches 100. Here the aim resolves first, then roll and shake apply on top, so your handheld character is still there at full lock-on.
Rigs are namespaced and auto-incremented. CameraRig, CameraRig_01, CameraRig_02. Unlimited rigs per scene with zero name collisions, which is what makes multi-camera shots and A/B framing passes practical.
timewarpScale is added to the camera transform, not the shape. That single decision is what makes the export step work at all, because CamRigBake duplicates the transform and the attribute rides along with its baked animation, straight onto the exported CineCameraActor.
Designing a professional, high-performance camera rig is a difficult task, even with AI. It requires a working knowledge of camera-rig workflows and pitfalls: hierarchy, control axes, viewport safety, and lens math, and those decisions have to exist before the first prompt, written down as spec. This one took roughly twelve hours: write the spec, generate, test in Maya, diagnose what broke, re-prompt, repeat.
The look-at hierarchy is the clearest example of why the testing half matters. In the first working build, roll and shake sat above the look-at rotation blend. The rig was correct by the spec and correct on inspection. It was also broken: at full blend the aim resolved last and ate the roll completely, so I could animate ROLL and watch absolutely nothing happen in the viewport. The fix was to reparent both groups below the blend. Nobody finds that bug by reading code. You find it by canting the frame on a lock-on and noticing the frame does not cant.
Two other features took multiple passes to reach a method that survived real use, because Maya's API offers many ways to do each and only a few that hold. The focus plane only became reliable once I specified it must compute field of view from focalLength and verticalFilmAperture from first principles, rather than reading a computed attribute. The locked viewport took the longest, because Maya's panel commands are inconsistent here, and I kept steering until the hidden-viewer-camera approach held.
The artifact most portfolios never show: the actual production spec. It reads like an engineering ticket because that is what effective AI direction is.
Create a Python script for Maya 2026 that generates a complete, professional-grade camera rig, self-contained in a single function. Build the hierarchy in this exact parented order: WORLD_CONTAINER_GRP → ROOT_POSITION_GRP → ROOT_YAW_ROTATION_GRP → ROOT_PITCH_ROTATION_GRP → TRUCK_DOLLY_GRP → YAW_GRP → PITCH_GRP → ROLL_GRP → SHAKE_GRP → Camera. Set film fit to Overscan, enable Display Frustum, default focal length 35mm, and synchronize film aspect ratio to the render device aspect ratio... Focus plane visualization must use a stable, expression-based system that calculates field of view from first principles using focalLength and verticalFilmAperture... Lock and hide all non-essential axes so the only keyable attributes are the intended ones per control... Create a floating viewport driven by a second, hidden viewer camera parent-constrained to the rig camera, with all its transforms locked and NURBS curves and locators hidden.
(The full spec runs to eight numbered sections. It is a requirements document, not a wish.)
Built and tested for Maya 2026. Sets render resolution to 1920x1080 on build. cycleCheck is disabled during construction and restored afterward. The focus plane is expression-driven, so it evaluates every frame. Initial keys are set on frame 0 for every unconnected keyable channel, giving you a clean baseline to animate from.
I directed; the AI wrote code. The value was not in generating a rig, it was in the decisions: which controls exist, how they nest, what the viewport must refuse to do, and which single attribute has to exist for the rest of the pipeline to work. A lot of that time went into three things: prompts specific enough to be buildable, explaining test failures in language the model could act on, and verifying every result inside Maya rather than trusting the code on its face. Twelve hours, mostly direction and diagnosis, not generation.
A rig is a set of decisions about what an animator should and should not be able to do. The AI can write the hierarchy fast. Knowing that the viewport must be impossible to nudge came from twenty years of watching shots get knocked loose.
The script as it runs. Maya 2026, Python, no external dependencies.
Written by AI under my direction. Read it; that is the point.
Hands TimeWarpController.py a rig with a discoverable shot camera and a keyable timewarpScale attribute waiting at 1.0.