I’ve been working on new FBX importer (written in C++, based on ufbx library). While it “seems to work” on some files I tried it on, it would be great to get others to test it, and/or provide feedback on import settings and their behavior etc.
Update: the new FBX importer has been merged into blender main on 2025 April 16, and will be available in 4.5 alpha daily builds from now on. Thanks everyone for feedback so far!
Short summary of current advantages: several times faster import, support ASCII .fbx files, handles some “partially broken / strange” files better, better import of various material parameters, each animation “take” inside FBX gets imported into one Action with multiple slots, handles “geometry transform” cases better.
Not all import settings from the previous importer are implemented yet – mostly since I have questions about the need or utility of them, or their previous behavior. Again, details in the PR linked above. Feedback on their use cases would be very welcome!
Things to test: do you have some cases where the new FBX importer produces worse results than the old one? If so, knowing about them, either here or as a comment on the PR, would be great. At this point I’m not looking for feedback like “old importer is broken, why is new importer broken too?” – right now major goal is to get the new importer not be worse; later step would be to improve it compared to the old one.
So far has worked well, and fast, for the Zero-Day ORCA test scene!
However, for another test, I noticed that root bones are not being posed correctly - I think the code is skipping poses for such bones. Grab the scene from #111931 - USD: Support armature and shape key export - blender - Blender Projects and export to FBX. It contains only a single posed bone. Then import using old and new:
Relatedly, bones are imported as un-connected - each can move freely even if they have a parent. There’s a use_connect property that is somehow set on the old importer but not the new. I think it would use a heuristic and check to see if 2 bones overlap their respective head/tails and consider those that do overlap as “connected”. This problem also exists for USD which I haven’t worked through yet either.
Topic for the crowd: As for adding the “File Handler” right now, I’m curious what folks think about that? Because there’s now 2 importers handling FBX, quickly slinging files into the viewport pops the conflict resolution dialog, as designed and works great, but it does require extra clicks. Do we want this front and center while the new importer is still experimental?
Just curious, this is just importer or importer/exporter? I’ve been having issues with exporting FBX to unreal engine for years where exported hierarchies (object parenting) from blender would always end up in target software with root node being 100x the scale and all the children being 0.01x scale. And no amount if the tinkering with the settings would ever fix that.
Do this just affects the imports, not exports, right? And if so, do you plan to work also on the exporter in the future? I’d love to test that.
Other than that, I am absolutely loving that the new one has much less cryptic settings
I know this is a slightly larger suggestion than just FBX importing, and I assume there is a can of worms to it, but I have often found that it is annoying to have each importer be its own menu item. I want a file>import dialog that can handle obj, fbx, abc, etc. without having to check what file type I am about to grab and then choose the appropriate importer. More than once I have chosen the wrong importer and had to figure out why my file was not visible in the import dialog.
Yeah this is entirely unrelated topic/ask. However, did you know that you can simply drag your model file into the 3D viewport, and then the correct type import settings will pop up? (this was added in Blender 4.2 or so)
PetrusTaurus has no loaded in texture/is shown in black.
In another ufbx capable program, the texture got loaded in correctly.
Texture is correctly loaded in with e-LysE but her scaling is wrong in the jump animation.
In another ufbx capable program, the jump scaling issue is also there but the texture was missing. Blenders UFBX has a slight advantage.
animation with/no ascii examples are scaled up and in the wrong direction.
added non ascii fbx files. for testing with the old fbx method where direction and scale are correct for both Z and Y up.
In another ufbx capable program, the correct and expected result was that animation no ascii examples as well as animation with ascii examples gets correct scale and direction.
Can´t upload directly so wetransfer (3 days up) it is.
Found a workaround/“solution” for fixing the black texture issue after importing fbx files with embedded textures.
When you go into the UV Editor , Browse images to be linked and open those (black)textures and press Alt+R, the texture gets correctly loaded in and shown on the Mesh(es).
currently, “experimental fbx” only imports base color/albedo textures and dismisses for example normalmap textures (probably other textures too?)
the old one imports those textures.
one thing I realized and find got changed for the better(in my tiny test cases) is Texture naming differences.
New “experimental fbx” is using the original Texture filename
TEX_CHA_PetrusTaurus_Base_02.jpg
with the old fbx importer the filename is vastly different:
Diffuse Texture.jpg
I don’t see this, in files that I have the new importer recognizes more textures than the old one, including normal maps. If you see otherwise, then again FBX files that show this would be appreciated.
Yeah I changed them to be named after the filename information inside FBX file; to me that feels more useful.
The only thing I was immediately worried could maybe be neglected was the import of Edge Creases but that seems to work in the experimental Build.
We started using edge creases in our FBX database lately and it would really throw a wrench into our workflow if this feature would malfunction. I just feel it’s important to emphasize since not too many people seem to use it.
@Timur_Ariman I’ve just made a new build (same location) that fixes texture load issue, and fixes the “animation with/no ascii examples” cases. The “e-LysE” case is still strangely streched vertically though. Thanks again for the reports!
here is another ASCII FBX file, somehow no matter what, I can´t import it.
Might be out of scope but nevertheless it could be important to have such a case file since the prior non-ascii variant could be imported.
This seems to have “not a number” entries in animation curve of Gun_Trigger object X position curve. That curve is on line 40905 of the fbx file, and is full of KeyValueFloat: *180 { a: -nan(ind),-nan(ind),-nan(ind),-nan(ind),-nan(ind) values. This is not parsed correctly by ufbx right now. Meanwhile, avoiding animations with infinity/not-a-number values is probably good.
