Question: Animation Sampler Input

[Siccity]

Hey, I'm working on an importer over at https://github.com/Siccity/GLTFUtility

One contributor suggested we add an adjustable framerate import setting. My question is, does this make sense for GLTF? As far as I understand it, animation sampler input are second values, not bound to any specific framerate.

At specification/2.0/README.md#animation-sampler you define the property like this:

The index of an accessor containing keyframe input values, e.g., time.

Now the e.g. part confuses me, because that means storing time as input is just one option. Are there other options? Would a proper exporter store anything that is not time in the input accessor?

[javagl]

The more detailed description explicitly refers to the values as time, in seconds:

The values represent time in seconds with time[0] >= 0.0, and strictly increasing values, i.e., time[n + 1] > time[n].

^{I don't know where the "e.g." comes from (maybe it should have been "i.e."?).}

The main point is that when you open the file in a viewer, and press "play", then the animation will by default be played with the assumption that the key frame input values are seconds. So the point about the frame rate is also correct: The frame rate is implicitly given by the number of key frames when they are interpreted as being "time in seconds".

---

Wild thoughts:

Exporters could export values that are not "seconds" in the strictest sense - consider an animation of plate tectonics ;-) Also, depending on the hardware capabilities, viewers could (or maybe have to) skip frames, or they could do some interpolation, but that's not part of the specification. Imagine a complex animation of a complex object that is supposed to be rendered with 200 FPS.... on a cell phone. This raises questions. Not that specifying the input as "time in seconds" answers all of them, at least it clearly defines at which point in time which state should be rendered.

[emackey]

Just adding my own thoughts on this. As you know, the input values are intended to be time measured in seconds, so for example a glTF animation that is 10 input units' long would be expected to play for 10 seconds in a typical glTF viewer before ending or repeating.

But consider, glTF just offers animation storage, it does not tell the host application when to play any of the available animations. Some host apps can do interesting things with the input time, for example play an animation at 2x speed or half speed, or even play the animation backwards. A host app could start playing an animation forwards, and then pause halfway through, hold there a while and then turn around and play backwards.

So in such cases, it's hard to say what units the input values are, as they are controlled by the host application. But we can say that if you treat them as seconds, then the animation should play forwards at 1x normal speed.