There's also some ongoing discussion in the spec repo: KhronosGroup/glTF#1778

For the sake of documenting this somewhere, I'm going to go ahead and assume this is how it should be done:

// Javascript sample code
let animBufferView = new BufferView(ComponentType.FLOAT, DataType.VEC3);
let keyframeTime = 0.5;
let keyframeValue = [1,2,3]; // x,y,z
let interpType = "CUBICSPLINE"
if (interpType == "CUBICSPLINE")
{   
    let inTangent = [1.1,1.2,1.3]; // intangent values for x,y,z
    let outTangent = [0.2,0.3,0.4]; // outtangent values for x,y,z
    let data = [inTangent, keyframeValue, outTangent];
    for (let d of data)
        for (let j = 0; j < 3; ++j)
            animBufferView.push(d[j]); // aaavvvbbb, a=inTangent, v=value, b=outTangent
} else {
    for (let j = 0; j < 3; ++j)
        animBufferView.push(keyframeValue[j]);
}

Someone please correct me if I'm wrong. Or if there isn't a standardized way yet, shouldn't we try to define it and stick to one?

The spec is unclear about whether we should write this out as aaavvvbbb or avbavbavb.

EDIT: actually the spec says this:

 tangents (ak, bk) and values (vk) are grouped within keyframes:

a1,a2,...an,v1,v2,...vn,b1,b2,...bn

although it's a little unclear if "n" refers to the number of morph targets or the number of keyframes.

ThreeJS has this in GLTFLoader.js

// Layout of keyframe output values for CUBICSPLINE animations:
//   [ inTangent_1, splineVertex_1, outTangent_1, inTangent_2, splineVertex_2, ... ]

@prideout I think the section you reference is marked as being for "sparse accessors" only, implying that sparse accessors use a different storage from the standard. The ThreeJS one is correct (for non-sparse accessors at least).

There's a little more info in the glTF Tutorial on CUBICSPLINE, and that tutorial references Appendix C of the spec. But it would be great to update the core spec to be a little more clear on this formatting of CUBICSPLINE (inTan, value, outTan). ThreeJS, BabylonJS, CesiumJS, Windows Mixed Reality, Blender import/export, and many other ecosystem participants agree on this formatting.

Thanks @emackey, this is helpful.

@emackey, a couple more notes, thanks for discussing this:

(1) The ThreeJS comment that I quoted could be misleading since it refers to the consumption of a transient "results" buffer which seems to be generated at run time.

(2) The tutorial that you linked is helpful, but the part about scaling tangent vectors with deltaTime seems odd since many types of animation values (e.g. morph weights and rotation) are not vectors. (FWIW, I can't find any deltaTime scale in the ThreeJS loader.)

The tutorial that you linked is helpful, but the part about scaling tangent vectors with deltaTime seems odd since many types of animation values

An aside: This issue here is in the glTF Tutorial repo. Asking an implementation question here is in some way not the perfect fit, but makes sense when people are looking for hints about implementations that they are trying to create based on the tutorial. In the best case, this can help spotting points in the tutorial that are not clear enough, or plainly wrong.

The latter might even be the case here, but from a quick glimpse: The Appendix C mentions "m1 = (tk+1 - tk)ak+1" as the resulting tangent, and the difference between the t's should correspond to the deltaTime in the pseudocode of the tutorial.

Does that make sense?

(I'd need a refresher for the maths to be sure, and maybe compare it more closely to the actual implementations, but if someone can say that it's definitely wrong, I'd fix it ASAP)