Why glTF Cubic Spline Animation Needs 3x Memory

In glTF 2.0 animation tracks, utilizing cubic spline interpolation results in exactly three times the memory footprint of equivalent linear or step tracks. This footprint expansion occurs because the glTF specification structures cubic spline data as Hermite splines, requiring three distinct data points—an in-tangent, the actual keyframe value, and an out-tangent—for every keyframe timestamp. Consequently, an animation track storing cubic splines must allocate three times the buffer space compared to standard linear interpolation, which only requires the keyframe value itself.

How glTF Stores Animation Samplers

An animation in glTF relies on an animation sampler, which pairs an input accessor containing time values with an output accessor containing the animated property values (such as translation, rotation, or scale).

In linear (LINEAR) and step (STEP) interpolation modes:

  • For each time entry in the input array, there is a single corresponding element in the output array.
  • If a translation track has 10 keyframes, the output accessor holds 10 three-component vectors (VEC3), totaling 30 floating-point numbers.

The Hermite Spline Data Structure

glTF implements cubic interpolation via cubic Hermite splines. To mathematically define a smooth cubic curve between two adjacent keyframes \(k\) and \(k+1\), the runtime engine needs to know not only the values at both points, but also the arrival direction (in-tangent) and the departure direction (out-tangent).

To accommodate this mathematical model, the glTF specification dictates that for every keyframe in a CUBICSPLINE animation track, the output buffer must supply three sequential values:

  1. In-tangent vector (\(a_k\)): Represents the incoming slope or velocity of the property arriving at keyframe \(k\).
  2. Keyframe value (\(v_k\)): The actual target property value (e.g., position, orientation, or scale) at keyframe \(k\).
  3. Out-tangent vector (\(b_k\)): Represents the outgoing slope or velocity of the property departing from keyframe \(k\).

These three elements share identical data types and dimensions. If animating a standard 3D position vector (VEC3), all three components are stored as individual VEC3 elements within the underlying buffer view.

The Memory Footprint Comparison

Because each timestamp associates with an in-tangent, a value, and an out-tangent, the number of stored components scales directly:

  • Linear Track: \[\text{Elements per Keyframe} = 1 \ (\text{Value})\] For a 10-keyframe VEC3 track: \(10 \times 1 \times 3 \text{ floats} = 30 \text{ floats}\) (120 bytes).

  • Cubic Spline Track: \[\text{Elements per Keyframe} = 3 \ (\text{In-Tangent} + \text{Value} + \text{Out-Tangent})\] For a 10-keyframe VEC3 track: \(10 \times 3 \times 3 \text{ floats} = 90 \text{ floats}\) (360 bytes).

Even the first and last keyframes must store all three values, where the first in-tangent and the last out-tangent are typically set to zero or ignored by the evaluator.

Why Tangents Are Explicitly Stored

Rather than having the runtime compute tangents dynamically (such as through Catmull-Rom splines, which infer tangents from neighboring points), glTF mandates explicit tangent storage. Explicit Hermite tangents allow digital content creation (DCC) tools to export precise, customized curve handles, including broken handles for sharp directional transitions. Storing these vectors directly guarantees that animations render identically across all conformant engines, trading buffer capacity for visual consistency and predictable runtime evaluation costs.