Utils: Deprecate Exporters (Blender, 3DS Max and Maya)

[Mugen87]

I'd like to suggest the deprecation (removal) of the Blender, 3DS Max and Maya JSON exporters for two reasons:

• The exporters are not really actively maintained. There is a long list of non-trivial bugs, feature request and suggestions no one cares about (see the Blender issue list). Because all exporters are based on different APIs (Blender, 3DS Max...) and written in different programming languages (not JavaScript), it's very hard to maintain this stuff.
• The more important point is that the quality and maturity of certain loaders (e.g. FBXLoader and GLTFLoader) were greatly improved over time. In other words, it is much more likely to load FBX or glTF files with proper results. Besides, these loaders are actively maintained by project collaborators.

So instead of exporting to the JSON format, users should focus on other formats like FBX or glTF. And in context of asset delivery, especially glTF is a much better format than (uncompressed) JSON.

[looeee]

+1 for this - the existence of poorly maintained and out of date exporters in the repo is a unnecessary point of confusion for newcomers, especially since as @Mugen87 points out there are now much better options.

[Usnul]

Note: official GLTF Blender exporter (https://github.com/KhronosGroup/glTF-Blender-Exporter) doesn't currently allow proper animation export (only 1 animation per object is supported currently).
KhronosGroup/glTF-Blender-Exporter#112

[looeee]

@Usnul how does that compare to the Blender JSON exporter in this repo?

[Usnul]

@looeee
Blender JSON exporter exports animations just fine. There are some weird glitches with UVs or vertex normals in certain conditions which are not present in GLTF exporter, but that's another story.

[looeee]

OK, I don't use Blender so I won't comment further on that.

However I can say from experience that trying to use the 3DS Max exporter, which hasn't been updated in several years, is an endless headache and I would strongly support removing it from the repo in favour of the FBX format.
Nearly everything exported by the 3DS Max FBX exporter is now supported by the FBXLoader and since that exporter is maintained by AutoDesk we can count on it staying up to date.

Similarly with the Maya FBX exporter, although the FBXLoader still needs to be updated to properly support pivots points there.

[Mugen87]

When i remember correctly, Blender does not export animations when you select BufferGeometry. There is definitely a problem with morph targets, see #10932. Besides, the exporter uses the "old" animation hierarchy format and not the one of the current animation system.

[looeee]

I think we should remove the Revit exporter README too - it just links to a separate repo which looks like it's barely been touched in last couple years.

There are probably hundreds of three.js tools we could link to like this, but unless we are willing to make sure that they are actively maintained and working correctly, I don't think we need to include links to them here.

Googling for "three.js revit exporter ' finds the repo just fine anyway.

[Mugen87]

I think we should remove the Revit exporter README too - it just links to a separate repo which looks like it's barely been touched in last couple years.

👍

[Mugen87]

the existence of poorly maintained and out of date exporters in the repo is a unnecessary point of confusion for newcomers

I just want to highlight this statement because i think it's very important for three.js. When users encounter these exporters, they expect tools that just work. But in most cases they get confused and maybe a bad impression of the entire project. That's no good. 😢

[wolfgangvonludwigsburg]

As an innocent user, may I dare to give a comment ...

Concerning Blender:
If three.js would have a native .blend format importer,
there would obviously be no need for an exporter.

No installation effort on Blender side,
no compilation from blender API/structs to javascript through python code ...

There were tremendious efforts to write the JSON exporter in python,
I wonder why you collaborators did'nt choose this way ... ?

[Usnul]

@wolfgangvonludwigsburg
It's a fairly simple question to answer. Blend format is not very close to three.js internal representation, so some conversion is necessary. JSON format of three.js is very close to internal representation, so job of conversion from blender representation to three.js is there either way, whether you choose to call it Exporter or Loader. That being said, .blend is not a common transfer format, nothing except for blender really supports it, so having a Loader for it would satisfy fairly small audience, since even people who use blender prolifically tend to use other software also, and .blend is not a format of choice as an exchange format. Usually it's obj, fbx or some open standard like gltf or collada.

[looeee]

@wolfgangvonludwigsburg if you were to look into building a .blend file loader, this would probably be a good place to start:

https://raginggazebo.com/parsing-blender-3d-files-blend-1-of-3/

[wolfgangvonludwigsburg]

Many THX for your comments!

But why is the Blender JSON exporter such error prone ...
=> It depends on the Blender API, is written in Python, shall understand the Blender data structs,
and compiles to an JSON format, that three.js reconverts into its internals ...

A very lot of tasks, that all can (and really do!) fail, mainly on Blender version changes.
Well, I would prefer the "direct data compilation" way ...

[Mugen87]

Well, I would prefer the "direct data compilation" way.

That's no good approach. Loading blend files directly into apps is some kind of misuse. Instead, you should utilize a file format that is intended for data transfer and asset delivery. glTF is the first standardized format that focuses on this aspect from the application's point of view. That's one reason why i promote glTF so many times 😇 . It should be the standard for all upcoming 3D apps.