The Timewarp Camera Pipeline
Author slow motion in Maya. Ship it to Unreal. Three tools, one contract, no manual re-timing.
Slow motion is one of the hardest things to move across a pipeline. Maya wants to stretch time. Unreal wants to dilate it. Between those two ideas sits a camera that has to be animated in one time space, reviewed in another, and exported in a third.
Each stage has a tool that does its own job well. What breaks is the hand-off between them. Timing authored in Maya's scene time-warp lives in special nodes that do not travel, so the information a downstream engine needs is trapped where downstream tools cannot read it. Every hand-off becomes an opportunity to lose the exact thing you were trying to preserve.
This suite closes that gap.
Each is a working tool on its own. Together they are one path from an empty scene to a shot running at the right speed in Sequencer.
Every tool in this suite agrees on exactly one thing: a single keyable double named timewarpScale, living on the shot camera's transform. Default 1.0 is full speed. A 16x slow-motion beat bakes in at 0.0625.
The rig creates it. The timewarp tool writes per-segment speed onto it with stepped tangents. The export tool carries it onto the FBX. Unreal reads it to drive global time dilation.
One attribute is the entire interface between three tools. Anything that can find a camera can join this pipeline.
A warped Maya scene has two clocks running at once. Warped time is what the timeline reads and what the shot feels like. Normalized time is real time, and it is where every animation curve actually lives.
The camera is animated in normalized time. The shot is reviewed in warped time. timewarpScale is baked in normalized time, which is why the export must be normalized too, and why CamRigBake clamps its bake range to the last speed key rather than trusting the playback range.
Understanding that split is the difference between a slow-motion shot that lands and a week of chasing camera drift you cannot explain.
I directed; the AI wrote the code. Thirty-two hours across three tools, and the hours themselves are the most useful thing I can tell you about working this way.
What separates four hours from sixteen? How much I understood before the first prompt, not the size of the code. When my decisions were already made, the model produced usable work almost immediately. When they were not, it guessed, and the guesses cost hours.
Specifying the contract first is what made three separately authored tools interoperate. timewarpScale was named before any of the three existed, and because it was one keyable double on a transform, it was small enough to restate at the top of every session without drift. Three tools written weeks apart agree about time because the interface between them fit on one line.
That is the part that transfers. AI-written code composes when the interface between tools is decided before the code is written. An interface that fits on one line leaves the model no room to reinterpret it. The scarce skill is not prompting; it is knowing which decision must be made before anything gets written.
All three scripts, as they run. Maya 2026, Python, no external dependencies. Target engine: Unreal, CineCameraActor via FBX.
Written by AI under my direction. Read them; that is the point.