glTF Animation Export: Read Time, Values and Targets

Why an Animation Export Needs a Structured Reading

An animation file is not a video of a machine. It is a small set of indexed references: a table of times, a table of values, a rule for what happens between them, and a pointer saying which node property receives the result. Reading those four things as one lump is how a manufacturing reviewer ends up describing motion that the file never actually contains. The glTF 2.0 specification organises this as animations containing samplers and channels, where a sampler names an input accessor, an output accessor and an interpolation mode, and a channel connects a sampler to a target node and property path (official primary reference).

That structure is the reason a review has to be split. The input accessor identifies scalar animation times. The output accessor identifies output data whose layout must be read with the path and interpolation mode. The interpolation string is a claim about the gaps. The channel target is a claim about where the value lands. Each of those can be wrong on its own, and a file can be internally consistent while still describing something the receiving application never asked for.

Input Accessors: What the Time Column Actually Says

The input accessor is the part most easily misread as a duration. It is an accessor like any other: it has a componentType, a count, a type, and usually min and max arrays. In the Khronos tutorial's single-triangle example, the input accessor is a SCALAR float accessor with five elements spanning 0.0 to 1.0, and the output accessor is a VEC4 float accessor holding the matching quaternions (official primary reference). The count of the input accessor is the number of key frames, not the number of seconds, and the min and max are the first and last key-frame times, not a measured physical interval.

A reviewer should therefore ask three questions of the input accessor alone. Is the type SCALAR, as the sampler input requires? Does the output layout agree with the declared interpolation and target path? For a non-weights LINEAR or STEP channel, the counts match; CUBICSPLINE stores tangent/value/tangent triples, and morph-target weights require their own layout reading. And does the accessor's declared range agree with the bufferView and byteOffset that back it? A count difference must be interpreted against those rules before it is called a fault. Accessor bounds and the referenced data are a separate consistency question; this article has not decoded a delivered buffer.

Output Accessors and the Channel Target Path

The output accessor carries the values, and its type is dictated by the target path. A rotation path expects quaternions, so the output accessor should be VEC4. A translation or scale path expects VEC3. The tutorial's example pairs a VEC4 output with a rotation path on node 0, which is the correct pairing for that property (https://github.khronos.org/glTF-Tutorials/gltfTutorial/gltfTutorial_006_SimpleAnimation.html). The channel's target.path is the field that decides this, and the channel's target.node is the field that decides which node is affected.

Here is where a manufacturing review often goes wrong in a way that has nothing to do with the numbers. A file can contain a perfectly formed rotation animation whose channel points at a node that the receiving scene never uses, or at a path the receiving application does not implement. The animation is valid and irrelevant at the same time. The review question is not "does the animation exist" but "does the channel target name a node and a path that the downstream process actually reads." That is a question about the target, not about the accessor data.

Sampler Interpolation Is a Claim About the Gaps

Interpolation is the sampler's statement about what happens between key frames. The specification defines the modes a sampler may declare, and the tutorial's example uses LINEAR, with the input times and output quaternions combined to produce the in-between orientations (https://github.khronos.org/glTF-Tutorials/gltfTutorial/gltfTutorial_006_SimpleAnimation.html). LINEAR is not a measurement; it is a declared method. A reviewer who writes "the motion is smooth" has moved from the file to an interpretation the file does not make.

The practical consequence is that interpolation and the input accessor have to be read together. Record the selected mode before checking the layout of the associated output. The specification gives CUBICSPLINE a different output arrangement from LINEAR and STEP. A reviewer should not turn the tutorial's one-value-per-time rotation example into a universal count rule. The target path also matters, because morph-target weights pack several values for each frame. The interpolation string is part of the export's meaning, not a cosmetic label.

A Hypothetical Animation-Package Review

Imagine a supplier hands over a glTF file intended to show a fixture arm moving through a pick-and-place sequence. The review proceeds in four passes, and none of them invents a timing or a physical result. First, the input accessor is checked for the required scalar time representation. Its relationship to the output is read using the declared interpolation and target path, rather than a universal equality assumption. Second, the output accessor is checked against the channel target path: if the path is rotation, the type should be VEC4; if it is translation, VEC3. Third, the interpolation string is recorded as a declared method, not as an observed motion quality. Fourth, the channel target node is checked against the scene's node list to confirm the animation is attached to a node the receiving process actually uses.

In this hypothetical file, suppose the input accessor is SCALAR with four key frames, the output is VEC4, the interpolation is LINEAR, and the channel targets a rotation path on a node that the scene does reference. If those specified checks are actually completed, the review can report the inspected rotation-channel relationship and the declared LINEAR mode. It should not certify the whole package from these selected checks alone. It cannot say the arm moved smoothly, cannot say a physical equipment cycle took any particular number of seconds, and cannot say the motion matched the physical cell. Those are separate questions that this file does not answer. The review records what the export declares and leaves the physical claim open.

That separation is the point of the exercise. A glTF animation is a description of how a node property is computed from time, not a record of what a machine did. Reading it well means keeping the input accessor, the output accessor, the sampler interpolation and the channel target distinct, and refusing to let a clean structure stand in for a physical result.