Test future glTF exporter version

I invited you to test a big refactory on glTF exporter.


The initial version of the exported was created during 2.7x time. Most of recent technologies created during 2.8x and 3.x are not correctly managed. Especially collections.

This refactoring tries to handle correctly scene objects and collection. It was not the case with current 3.1 exporter version.

What should not change in the new version?

  • Materials and textures
  • How animation are managed in NLA

What change can I expect?

  • Collection and collections instances, on local or via linked libraries
  • Nested linked collections
  • Transformations : To be able to handle every cases, all animations are now baked based on world matrix from objects and/or bones. This have multiple consequences:
    • Constrains should now be handle correctly
    • Exporting only selection is now possible, without having to export the parent hierarchy. Animation is recalculated based on selection.

What about performance

  • Unfortunately, baking animation can lead to longer export times in some situation. The worst case is to have a lot of objects , with multiple actions on each.
  • Armature animation performance should not be affected so much.

How to test it?


  1. During next 2 weeks, please test using the experimental build (see link above)
  2. Starting mid-February (date to be confirmed), you will be able to test in Blender 3.2 alpha from builder.blender.org
  3. Stable version to be expected: 3.2

We are currently in step 1. (this line will be edited later in case of changes)

How to report bugs?


Hi @JulienDuroure
Isn’t only Python about this exporter ? No Github dedicated with this addon ? Or it’s request to be we Blender 3.1 ? Thanks for your work, it’s really interesting !

Yes, this importer/exporter is only python. Here is the official repository : https://github.com/KhronosGroup/glTF-Blender-IO

It is simpler for users to download an entire build than manage delete/copy/paste some directory in preferences path.
If you want to do it anyway, it will of course work too. But the current version of the addon use some API only available in 3.1 or newer.


Alright, thanks for your answer :slight_smile: .

@JulienDuroure Thank you for your efforts. Does your changes effects also the .glb export?

Hi, I’m trying to import a simple scene with collections into unreal but the resulting import is just individual assets with their materials in the content browser. How do I reproduce blenders structure insisde Unreal?


Ok, just solved my issue… I was using the standard gltf importer and not the datasmith one.

@ChristophWerner Yes, glTF is the name of the specification. You can export both .glb or .gltf
Refactoring affects all export, whatever the exported format glb or gltf

1 Like

Is it possible that the gltf once is imported into unreal/unity gets its intanced collections transformed as prefabs/blueprint class? Or that is something to be done on the import phase?

Prafabs/blueprint are specific to Unity/Unreal. Nothing related to glTF specification or Blender export.
You should ask team responsible of importer in corresponding game engine.
Please focus this thread about any potential regression linked to the refactoring, no general pipeline or glTF support.

Hello Julien,

I was about to launch my series of tests but I notice that since the 3.1 branch, but also from the 3.2, that my behavior of the Material Output has changed.

It’s strange, I don’t want to say that it’s a bug, but in 3.0.0 and 3.0.1 when I select different “Material Out”, it’s visible in the 3D viewport, but not with the 3.1 and 3.2 versions of today.

On 3.0.0 and 3.0.1


And on On 3.1.0 and 3.2.0


Do you think this is a new feature or a bug?

But the good news is that the glTF exporter uses the selected Material Output.

And thanks again for the great job you are doing with the exporter.


I can confirm this.

Not related to glTF exporter, you should report it on https://developer.blender.org/
Not sure if this is intentional or not, I never head about that.

1 Like

Done :anchor: T95664 “Material Output” change is not visible in the 3D viewport, it’s my first bug report :partying_face: on developer.blender.org

I know this is slightly offtopic, but I just can’t help myself since Julien seems to know about glTF (maybe even works for Khronos).

I just can’t understand why Khronos group picked glTF as the name for this standard. Just the ugly, “syntactic” glTF label itself, with it’s inconsistent letter case, made me think for like 2 years straight that glTF is some library for programmers, not actual 3D data transfer format supposed to be interacted with and utilized by the end users - artists, without any programming experience.

It’s all the more jarring given the fact that glTF is the only Khronos standard which doesn’t have aesthetically pleasing, or at least reasonable name, in terms of letter capitalization:

I mean, Khronos is a “standards” company yet it fails to standardize the names of their own standards. Even in OpenGL, the GL is capitalized.

I mean what the hell, even the explanation of the abbreviation uses the uppercase:

And why does it have to be glTF? Graphics Library Transfer Format? I mean it can transfer 3D data which may not even be displayed in any software which uses some “Graphics Library”, but perhaps in some software ray tracer…? Why isn’t it just something like OpenTF (Open Transfer Format)?

It may seem quite petty to complain about this, but I think that the weird name alone, and the weird way it’s written is harming the popularity of this transfer format, since most of the average CG artists will just glance over reading something about “glTF”, because the name alone makes it look like it’s some programming library, not something they are actually expected to use.

It’s almost as if Khronos group had a meeting dedicated to coming up with the best idea on how to sabotage the new transfer format standard by finding as poor of a name as possible :slight_smile:

1 Like