[4.0] a7 – FBX file import is enabled, but no FBX2glTF path is configured

[ArseniyMirniy]

Godot version

4.0 alpha 7

System information

Windows 10

Issue description

The FBX support is still broken. Here I dropped the FBX file, it's visible in Windows Explorer, but not inside the editor:

Steps to reproduce

• Try to import FBX
• See nothing
• Check error log to find: modules/gltf/register_types.cpp:92 - FBX file import is enabled, but no FBX2glTF path is configured. FBX files will not be imported.

Minimal reproduction project

No response

[akien-mga]

Did you configure a path to FBX2glTF as the error tells you?

[ArseniyMirniy]

Did you configure a path to FBX2glTF as the error tells you?

No, I truly believed, that FBX import must work out of the box, as it was before.
Otherwise, it's a huge downgrade of user experience from Godot 3.
What is FBX2glTF and why on earth it must be downloaded separately?

[akien-mga]

See the release notes for 4.0 alpha 6: https://godotengine.org/article/dev-snapshot-godot-4-0-alpha-6

The new importer uses an external tool which is a lot better at importing FBX files than the previous importer.

[ArseniyMirniy]

The new importer uses an external tool which is a lot better at importing FBX files than the previous importer.

Still not very convenient and this "a lot better" isn't better for me (since the internal tool worked just fine, and this one require some extra steps, which breaks the whole Godot magic of a solid tool). How about using both tools and the external would be OPTIONAL, since it's required, when the internal one fail?

Godot idea in a core is how solid and unified it is: get it and you can work offline from any place in the world. This step is a huge step back.

[akien-mga]

since the internal tool worked just fine

Well you were one of a handful of lucky few then. For far most use cases the internal importer was broken, and that's what it was replaced with a better one.

Anyway, #59810 will improve the setup experience somewhat.

Godot idea in a core is how solid and unified it is: get it and you can work offline from any place in the world. This step is a huge step back.

Let's not overstate things. You just have to download an external tool once and it will work forever.

There's no plan to re-add the old importer, it had way too many types of FBX files that it couldn't handle properly.

[ArseniyMirniy]

There's no plan to re-add the old importer, it had way too many types of FBX files that it couldn't handle properly.

It worked fine with Blender FBX

Anyway, #59810 will improve the setup experience somewhat.

Sounds like a very limited "solution", it's still an external library, and you even suggest to use someone's fork. It obviously looks not very convincing.

Yet again, I suggest to use both.

[akien-mga]

It definitely didn't work fine with Blender FBX for many users... #44402

Yet again, I suggest to use both.

That's not possible. You can't detect which FBX would be supported by which importer, you have to import, and the user has to see if what they get is what they expect.

Please have some confidence that we're not just removing what you think is "better" on a whim. There are good reasons to change the importer, despite the new one having to rely on a thirdparty tool.

[kzerot]

Maybe it would be better to ease user experience with automated download&&install this tool? Just like with export templates.
So user just will be asked "Do you want to install fbx support?" and so on. Does FBX2glTF license allows it?

[akien-mga]

Maybe it would be better to ease user experience with automated download&&install this tool? Just like with export templates. So user just will be asked "Do you want to install fbx support?" and so on. Does FBX2glTF license allows it?

Ideally yes, but FBX2glTF depends on the FBX SDK and so the user needs to approve that license to use it.
We could parse the license file to display it in the editor and ask the user to accept, which is the workflow I'd favor, but we'll need to check that we're legally allowed to integrate it this way.

[nathanfranke]

I propose bundling a thirdparty/ FBX library with the editor.

Auto-downloading sounds like a bad idea.

1. It is phoning home (or someone else's home).
2. Could download malicious software if we do not control the server.
3. Auto-downloading proprietary (FBX SDK) software with an EULA defeats the purpose of open source.

Edit: I think FBX2glTF is better actually, but it shouldn't show the warning by default.

[akien-mga]

Auto-downloading proprietary (FBX SDK) software with an EULA defeats the purpose of open source.

Using FBX defeats the purpose of open source. It's a proprietary format. People should really use glTF 2.0 instead, but for now we have to make do with users wanting FBX support.

I propose bundling a thirdparty/ FBX library with the editor.

Well, that's what the previous, not really functional reverse engineering of FBX based on the Assimp parser was. It didn't work well.

Another option is to use OpenFBX, but implementing it in a way that produces a scene useful to Godot is probably at least 6 months of work for someone very familiar with both FBX and Godot. So while this would be nice (provided that OpenFBX works well on a wide range of FBX scenes), this is not as simple as you make it sound.

The FBX2glTF tool depends on the proprietary FBX SDK so it cannot be vendored in thirdparty/.