I would like to combine Mixamo animations from glTF source into a single animation and export it (glTF) for game engine usage.

I grabbed 3 different animation sequences (robot, robot-talk, robot-dance) and imported it into Blender. Everything seems fine. I found a tutorial that tackles the same task but with FBX source. Unfortunately, when I follow the step my new NLA tracks don't animate.

What is the issue, how can one solve this task? Thank you!

  • $\begingroup$ Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking. $\endgroup$
    – Community Bot
    Oct 6, 2021 at 13:47
  • $\begingroup$ I would like to create a single glTF file with multiple animation tracks. Here's an example. It can be loaded into Blender and is working properly. I have multiple animations with the exact same mesh, saved in glTF format in separate files. I would like to combine these into a single glTF file, using Blender. $\endgroup$
    – Toorop
    Oct 6, 2021 at 14:33

1 Answer 1


The first thing to notice is the "Walk" model does not have the same bone names as the other two (the bones are named "Armature_X", not "ArmatureRobot_X"), so it will need to be fixed to be compatible with them.

Here's how you can do it (starting from your attached .blend).

  1. First do "Delete Hierarchy" on the "Armature_Main_Dance" and "Armature_Main_Walk" armatures, so you only have one armature+model left.

  2. Now select the armature, open up the Dope Sheet and switch to the Action editor. Pick the "Anim_0_Dance" action. You can scrub the timeline to see it works. Click "Stash" to stash it onto your arma. Do the same thing for the "Anim_0_Walk" action even though it doesn't work (we'll fix it later).

    Stashing actions tells the glTF exporter to export them. (The "Anim_0_Talk" is already stashed so you don't need to do it.)

  3. Now switch to the NLA Editor. You should see this:

    NLA tracks

    This will export, but the names suck. Rename the tracks like this so the exporter knows what name to use for each animation:

    Renamed tracks

    At this point you can star the tracks to see them play.

  4. We need to fix the walk animation. You could rename the fcurves one-by-one in the Dope Sheet but its easier to use a script:

    import bpy
    ac = bpy.data.actions["Anim_0_Walk"]
    for fc in ac.fcurves:
        fc.data_path = fc.data_path.replace("Armature", "ArmatureRobot")

    (Put it in the Text Editor and hit run.)

    You can now star the Walk track to make sure it works.

  5. You're done! Export. You can reimport or test the file in a viewer like https://sandbox.babylonjs.com/ to check it.

  • $\begingroup$ Thanks a lot for the detailed, step by step answer, you nailed it! A quick question: the newly stashed tracks ("dance", "walk") start from 0, "talk" starts from 1. What is going on and is there a best practice in this situation, like always aligning to 1. I noticed that some imported gltf files have an active action starting from 0, and multiple nla tracks below it from 1. If I import the newly created gltf, there's an active action above the nla tracks - I guess Blender creates one automatically. $\endgroup$
    – Toorop
    Oct 7, 2021 at 14:39
  • $\begingroup$ And if you can have a quick look: are the json animation files (samba.json, thriller.json, walk.json) in the original repo custom saves, or is this some sort of animation data that can be loaded into Blender. Thx! $\endgroup$
    – Toorop
    Oct 7, 2021 at 14:40
  • $\begingroup$ The importer shifts stashed strips to the Start frame (from the Timeline, it's 1 by default). I don't know why. I also don't know how the exporter handles shifted strips. $\endgroup$
    – scurest
    Oct 7, 2021 at 15:24
  • $\begingroup$ Testing in Blender 2.83, exporting glTF animations that start at frame 1 result in glTF animations starting at non-zero time, regardless of what the Start Frame is set to in Blender. (For 24fps, the first keyframe is at 1000/24 = 41.66ms) The best practice, at least in 2.83, is to ensure animations start at frame 0. Perhaps in v3 they've fixed the exporter to subtract the Start Frame value when calculating keyframe times? :shrug: $\endgroup$
    – Phrogz
    Jul 11, 2022 at 21:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .