Spec very ambiguous about multiple animation support.

[reduz]

I'm very disappointed, I implemented 100% of the spec in Godot. Spent 4 days on it. At the time I'm done with it, I realize that, unlike what it proposes through the whole spec, glTF does not support multiple animations.

Guys, It's 2017 and all DCCs and game engines support multiple animation clips, so it should be perfectly possible to export all character animations in a single file without relying on cheap tricks like segmenting a timeline or having to export one animation per file (with the whole scene cloned on it). Collada and FBX support this perfectly.

In the spec, the term animations, plural, is used through the whole thing. It totally makes sense, any animation works on a number of channels. By reading the spec it becomes obvious that multiple animations can be stored in the format.

Yet, when I go try the demos.. every demo I find uses an animation for a different node. For example on this demo:

https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/BoxAnimated

To get the animation to look like in the gif, you have to play all animations together.
In this other demo:

https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/CesiumMan

Each bone has an animation of it's own. you must play all animations together in order to see the guy walking.

So, please change the spec to make it very clear to implementers that, in 2017, a new format does not support multiple animations for real, or that there is a strict requirement for them to be played at the same time for everything to look properly. Please also urgently add an official extension to support REAL multiple animations, so this format can be used for 21st century workflows.

I suggest: KHR_actual_multiple_animations or similar.

[darksylinc]

+1 to this.

Juan is trying to convince me to support glTF in Ogre as well, and this is a deal breaker.

If popular exporters default to exporting animations as one node per track which is further encouraged by the official samples, the format is useless to us.

The specs should be very strict on that animations should be done by having multiple nodes being animated in one track; so that each animation is independent of each other.

[donmccurdy]

Hi @reduz, this is an issue with our sample models, and (related) the Blender Exporter is missing support for exporting actions separately (KhronosGroup/glTF-Blender-Exporter#39). However, the glTF spec itself very much does support what you're asking for here, there is no extension necessary.

We will certainly work on updating the sample models to be more in line with expectations here.

Thanks!

[reduz]

@donmccurdy Oh I'm very glad this is a misunderstanding then. My fear is that this behavior of exporting every track in a separate animation becomes the "de facto" standard, even if not mentioned in the spec. This kind of ambiguity is, in my opinion, what doomed Collada because every implemetor did whatever they wanted with it.

gltF2.0 is pretty much the best exchange format i've ever seen and worth pushing it to be supported by every DCC and game engine. As an industry we need this, given the high reliance on libfbx and it's very restrictive usage license.

At Godot we maintain a small Blender exporter that supports the full Collada specification, including multiple animations (because the built-in one from Blender sucks). If you need it as reference please let me know.

I would really appreciate if the test models could be updated at some point in the near future, so I can call my implementation complete and start pushing the format as much as we can from our side.

[javagl]

^{Part of this was originally written in response to KhronosGroup/glTF-Sample-Models#108 , but applies here nevertheless}

It could help if you described more clearly what you refer to. There may be multiple animation objects. Each animation object may have multiple animation.channel objects. This leaves some degrees of freedom for "mix and match", i.e. how you structure the data for your particular use case.

(A side note: Remember that glTF is supposed to be a transfer format. A format that is only consumed by clients. To put it that way: The actual structure of the animation data in the file "does not matter", as long as it is capable of representing all sorts of animations that might be created with any authoring tool)

So, for example, regarding the particular example of the "BoxAnimated" that you referred to elsewhere: This was created from a COLLADA file that someone created as an example. And although I don't know for sure, I could imagine that he intentionally created two separate animations, to make the sample less trivial, and to show that multiple separate animations can be created.

(Another side note: The spec is indeed a bit quiet about playing the animations - particularly, about the animation loop behavior - I opened #573 a while ago, but there had been different priorities in the meantime).

As mentioned in KhronosGroup/glTF-Sample-Models#108 (comment) and KhronosGroup/glTF-Sample-Models#107 : There should indeed be more test models for different animation configurations (and personally, I'd once more prefer "simple" ones that only show the different ways of structuring animations in the JSON file, conceptually).

If you think that an extension is necessary, it would be good if you could roughly sketch a few lines of JSON that could encode the type of animations that cannot be represented in glTF right now, but as already mentioned by donmccurdy : This is probably not necessary.

[reduz]

@javagl All samples have animations exported like this, I think probably due to how Collada2GLTF works. Still, it's great that @donmccurdy said they will be fixed.

Specification and demos need to be as strict and unambiguous as possible, otherwise we end up with the same problems Collada had.

[donmccurdy]

@reduz @javagl Definitely there are some changes and additions that would be beneficial for the sample models. I've written up my suggestions in KhronosGroup/glTF-Sample-Models#108.

For the spec itself, I think it is fine that the spec is quiet about playback/looping behavior; no need to change that. Although the spec does not need a technical change, I do suggest we add an implementation note along these lines in the Animations section:

Implementation Note: While content authors may use animations as they please, common practice is to group channels into a single animation if they are intended to be played back as a unit. For example, "Walk" and "Run" animations might each contain multiple channels targeting the model's bones. The viewer or engine may choose how and when to toggle or crossfade between the two animations.

[javagl]

According to the discussion at KhronosGroup/glTF-Sample-Models#108 (comment) , the main point seems to be that there could be several ways of structuring animations, and the outcome is not covered by the spec:

• Individual animation objects that have to be played simulatneously to achieve the desired effect. (This could be covered and be made unambiguous by converting them into one animation with multiple animation.channel objects)
• Individual animations that may (at the discretion of the user) be played simultaneously or separately
• Individual animations that must not be played simultaneously. The obvious problematic case here is when two different animations refer to the same animation.channel.target. From a quick glance at the spec, this does not seem to be covered there at all. I cannot imagine that this was not yet discussed, and I'll probably do some issue-archeology to check this, but maybe one of the spec-masters ( @lexaknyazev ) knows more here.

[donmccurdy]

Individual animations that must not be played simultaneously.

I don't think this last case is necessary; and it would be hard to define. For example, "dance" and "walk" animations are distinct, but even so the viewer might choose to play them both for a brief period of time while crossfading from one to the other.

[darksylinc]

Of course, "anything goes". But too much lenience makes the format useless if the exporter only supports the most useless method of exporting animations.

In most game engines, animations are structured as independent single chunks of animations. For example:

• Run
• Walk
• Jump
• Idle
• etc...

Now, some more advanced games may chose to follow its own convention and define more specific set of animations:

• Run_Torso
• Run_Legs
• Walk_Torso
• Walk_Legs
• Idle_Torso
• Idle_Legs
• etc

In this case the game will have to run both Run_Torso & Run_Legs at the same time. "_Torso" will animated everything that belongs to the "upper side" of the body from the wrist, while "_Legs" animate the lower side. But gamedevs may also want to mix Idle_Torso with Walk_Legs and do more interesting animation combinations.

Other games may define even more thorough conventions for splitting up animations (rather than splitting everything just in 2).
This is normal.

However this is not what's being criticized. What we're criticizing is that right now all the models in the sample repository are doing the following:

• Walk_left_hand_finger0
• Walk_left_hand_finger1
• Walk_left_hand_finger2
• Walk_left_hand
• Walk_left_elbow
• Walk_left_shoulder
• Walk_torso0
• Walk_torso1
• Walk_torso2
• Walk_torso3
• Walk_waist
• Walk_left_quadriceps
• etc...
• [repeat with right side of body]

That is, one animation track per node. That's what reduz & myself are complaining about.

This is completely useless, and only puts a much bigger burden on us importers, who must implement code to convert all of these animations separated back into one; and also ask the user which animations go into each set.

Why is it useless? Because if I'd wanted to animate with the granularity of a single bone, I'd disable the keyframes for that particular bone, rather than having +20 different tracks and no way of knowing what goes with each.

Not to mention that all major content creator tools (e.g. Maya, Blender, 3DS Max, etc) group animations in sets. So it is to be expected an animation exported from these packages to be grouped in the same hierarchy that it was defined by the artist.

And if somebody actually wants to do this (exporting one track per node/bone), he or she can do that. But it should definitely not be the default behavior.

And because the default samples are encouraging this behavior, some implementors may even become convinced glTF only supports one track per node, causing a nightmare of compatibility issues.

[javagl]

I don't think this last case is necessary; and it would be hard to define.

This may go beyond the core of this issue (the animation "grouping", which is for itself a valid point), but I think that the spec should at least mention the case of two animations that use the same animation.channel.target. (I don't even say that it has to dictate a certain behavior for this case. It could also say that the behavior of playing these animations simultaneously is unspecified. But I think it is important to at least create awareness that such a case could happen...)

[alugarius]

+1
This is very important