The curve you drew is on screen.
It is not in the file.

A key always carries three numbers, whatever the track is for. Position uses all three as X, Y and Z. Rotation uses them as euler angles in degrees. Scale uses them as factors. And a Float track — a single scalar, like an opacity or a blend weight — uses only the first, carrying two unused numbers alongside it.

That is worth knowing mainly so the other two do not confuse you when you read a file: on a Float track, Y and Z are noise.

The last row is the trap. With no slash there is no bone name to take, and the two code paths resolve that differently: the preview substitutes the rig's hips so that something moves and you can see your curve, while the export writes the name out verbatim as the bone.

Both behaviours are reasonable on their own. Together they mean an unrenamed track animates the hips on your screen and ships addressed to a bone that probably does not exist. Nothing warns, at either end.

What a track actually does is decided by its Type dropdown, and the two are never cross-checked. A track named Hips/Rotation but typed Position exports as a position track carrying three position numbers — verified — and the name sits there saying otherwise.

This is a comfortable mistake to make: you rename a track to describe what you want, without changing the dropdown that decides it. The clip then moves the right bone in the wrong way, and the name in the timeline reassures you every time you look at it.

Rotation is resolved at export. You author euler degrees, and the file carries a quaternion — four floats — so whatever reads it applies them directly and does no euler-order guessing. A 90° yaw comes out with y = 0.7071, as it should.

That matters because euler angles only mean something alongside an order, and this one is fixed: X, then Y, then Z. Resolving it at the boundary means the order is Motion's problem and never the game's.

The setting is genuine authoring data, and it is worth saying so before the rest of this page: it saves to the project file and comes back unchanged on reload — verified by saving an all-Cubic clip, reloading it, and finding every key still Cubic.

So it is not decorative. It is a real property of your keys, correctly stored. The question the rest of this page answers is who reads it.

One cubic key anywhere on a track makes every key on that track cubic in the preview. Twenty linear keys and one cubic one is a fully cubic track, and there is no combination of settings that produces a track which is cubic in one place and linear in another.

A per-key transition hint is passed alongside each key — a value of 0.5 for cubic keys against 1.0 for linear ones — which softens the result slightly but does not restore the distinction. The track-level choice is what governs the shape.

Byte for byte the same. The exported key format has a time and a list of values and no field for a curve at all, so there is nowhere for the setting to be written even in principle. The file does not mention interpolation, cubic or linear anywhere.

Which produces the exact inversion this page is named for. That one cubic key is the most powerful setting on the track in the preview and the least powerful in the file — it changes everything on screen and nothing at all in what you ship.

That is the whole contract. Everything the game does with your animation is built from times and values on a named bone — which means the way to control the feel of a move is to control the keys themselves, not the curve between them.

Concretely: if you want a movement to ease, put the easing in your key timing and spacing. Keys bunched near the end of a move produce a deceleration that survives export, because it is made of times and values. A cubic setting produces a deceleration that does not.

The index pass is deliberately generous about what counts as an animation: an entry is taken if its type says animation or if its output filename ends in a glTF extension. Other asset types are ignored entirely — a texture in the same index contributes nothing, verified.

So the clip list you see on opening a mod is Refinery's inventory of animation files, with your own work laid over the top of it.

The glTF is never parsed for its animation during this pass. Its duration is not read, its bones are not read, and the 2.0 is a constant that has nothing to do with the file. The tool's own source calls it a stub.

That would be harmless if such a clip could not leave the tool. It can. Exporting a project of nothing but stubs produces a runtime file with a named clip and an empty track list — verified — so the game receives a two-second animation that animates nothing, and nothing anywhere between the index and the file says so.

Because it is a replacement rather than a merge, the index's paths do not survive the override — verified: an authored clip that replaced an indexed one had an empty output path afterwards. Your file is the whole truth about that clip.

The second row is the trap. Rename an authored clip — to Walk_v2, say, while iterating — and the join by name silently breaks. You now have your real animation and the two-second placeholder it was meant to replace, both in the list, both exporting.