Handy animation test tool - but found a problem

We use this Sandcastle for our modeler to test animations in Cesium.
You can:

  • See the list of named animations
  • Verify the index order
  • Run animations individually
  • Run selected animations concurrently (if designed to do so)

If this had been in the community earlier it would have saved us some time - hope it helps you.

However, it uncovered a problem and we need some help.

We think the code is correct in that we can individually and concurrently control the Cesium_Air model’s propellers.

But our Blender models are not able to perform two animations concurrently - kinda.
We know that two animations must not share common components so we have tried to design with that in mind.

Notice the Excavator can MoveBase or MoveCab but not both concurrently.
DumpTruck 1 can MoveBase or MoveCab but not both concurrently.
We did some reductions on DumpTruck 2 and this is strange:

  • We can MoveBase or MoveCab
  • We can MoveBase and then MoveCab concurrently! Happy day!
  • But we CANNOT switch the order and MoveCab and then MoveBase concurrently. How strange.

I know its a problem with our models but we can’t figure it out.
Could someone give some suggestions on what we should research or try?

Here is a link to DumpTruck 2 if you want to load the glb. (This is licensed so do not distribute)

Any help would be appreciated.

Anyone know why animations #1 + #2 can play concurrently but starting on the other order of animations #2 + #1 cannot play concurrently?

The tl;dr is: There are some nodes that are affected by both animations (e.g. the node with index 79). Playing these animations at the same time will mess up the internal state. I guess your goal was to have the MoveBase and Dump animations to be completely separate (one moving only the wheels, and one moving only that dumping thing). You should check whether you can export the animations as really separate ones.

Details, starting with a few comparisons:

The glTF viewer from https://gltf-viewer.donmccurdy.com/ does play both animations. And they can be enabled and disabled separately. But when looking closely, the observed behavior already hints at what might cause trouble in other viewers:

glTF Animation Truck

Note that when the MoveBase animation is enabled, the Dump movement is much smaller.

The viewer from https://sandbox.babylonjs.com/ only allows you to play each animation individually, and not at the same time. (Unless you “cheat”: It is possible to play MoveBase, then select Dump in the Scene Explorer, press “Edit” in the menu on the right-hand side, and manually start the Dump animation in the Animation Curve Editor).

The viewer at PlayCanvas glTF Viewer allows you to select both animations individually, or “All tracks” to play them at the same time - but they are not really played at the same time (i.e. the wheels stop during the Dump movement)

As mentioned above: There are nodes that are affected by both animations:

This is not explicitly disallowed by the glTF specification. In fact, the example in the Animations section of the glTF specification also shows an example where animations are sharing the same nodes!

But the important point here is the Implementation Note from that section:

glTF 2.0 does not specifically define how an animation will be used when imported but, as a best practice, it is recommended that each animation is self-contained as an action. For example, “Walk” and “Run” animations might each contain multiple channels targeting a model’s various bones. The client implementation may choose when to play any of the available animations.

Or to put it that way: When two animations affect the same nodes, then the behavior of playing them simultaneously is not really specified. (In my home-brewn viewer, the result is some odd “flickering” of the Dump animation - I’ll have to fix this somehow :frowning: )

I guess that when you separate the animations properly, they can be played back by CesiumJS as expected. (If not … then this could be investigated further…)

Thanks Marco13! We knew we could not use common nodes for concurrent CesiumJS animations but gltf/Blender/CesiumJS is so new to us that, honestly, we did not know how to properly search for conflicts.
Now that you explained is so well, I’m confident we can revisit our models with a focus on common nodes and resolve this. I need to assemble a better toolbox for exploring gltf structures.

Great response!