FBX BIN export - "dot" vs "dash" for UE4
Open, Needs TriagePublic


System Information
Windows 10/64, GTX1080

Blender Version
Broken: all

Short description of error
There is a problem with exported FBX files that contain many objects.
They cannot be reimported in the UE4 cause the "." in the name of some objects causes that UE4 with own name notation is unable to reimport such object.
There is very simple way to fix it.
before this line:
fbx_data_object_elements(objects, ob_obj, scene_data)
should be this conversion:
ob_obj.name = ob_obj.name.replace(".","_") #replace dots in object names with underscores

All has been described here:
Ue4 forum link

It would be nice to have this fixed permanently, because Blender is the only one modeller that uses dots in automatic name extensions
na causes problems at UE4 reimport. Cause at every Blender upgrade this needs to be fixed manually.

Exact steps for others to reproduce the error
no needed



Firstly, having a dot in a name is quite reasonable, It's surprising UE4 doesn't handle this properly.

Further - note that simply renaming isn't a reliable solution, since other objects with this name may exist.
A name mapping would need to be maintained that detects and resolves collisions.

My hack (don't tell mont) wasn't meant to be reliable really, just a quick fix to a strange problem.

What happpens is that you import a multi object .fbx to UE4 where some of the object names have a . in the name (so Cube.001 or whatever). The filenames are UE4ized so it turns into Cube_001 for some reason. Then if you try to reimport the object now called Cube_001 UE4 forgot what the original file was and goes to a fallback that just imports everything in the file, so your single object Cube.001 turns into all of the objects in the entire .fbx. Which isn't great.

Anyway even if this was fixed on the UE4 side it would be broken in all previous versions anyway so it might be a good idea to have a real fix in Blender.

After checking in UE4 only these characters seem accepted in names: a-z, A-Z, 0-9, -, _, ´, ¨, §, ¤, +. I'm not sure if these are actually accepted or if it's another bug (maybe breaks in cooking) but at least can strip the non working characters. Checking for name collision between objects could also be done too although I think this would be pretty rare that you've got one object called Cube.001 and another called Cube_001 for example.

This would be a pure UE4 compatibility feature though and I'm not sure how everyone feels about that. If it's not a problem another feature that forces UE4 style naming conventions (SM_ prefix for static meshes, SK_ prefix for skeletal meshes and so on) could be possible too.

Have you reported the bug to UE4? This sounds like a fairly straightforward issue in their importer where they are doing some wrong comparisons on reimport. Probably comparing the unmodified name from the FBX object with a modified name from the Unreal object, and not finding any matches.

It was reported a bunch of times but not fixed yet. You're right though, I checked the code and there's even a comment saying "// find the Fbx mesh node that the Unreal Mesh matches according to name". So there's no check for converted file names.

Even if it were to be fixed from now on it would be broken on all previous versions so I still think it could be valuable to have a setting in the FBX exporter that makes sure that file paths are valid for UE4.

I can't find a matching issue here, do you have a link to where it was reported?

It may be reasonable to work around a bug in UE4 in the Blender exporter, but it's best if the actual bug is fixed as well.

The issues tracker is only for "accepted" bugs and was not used in earlier versions (it didn't exist back then). Here are a few answerhub reports:


That being said they are a bit vague and there's not a report that has files that fail when reimporting and a clear description of why it's failing. I can report it later using the new bug report form here https://epicgames.formstack.com/forms/unreal_engine_bug_submission_form .

I reported the bug for now, it should be very clear what's wrong. I will update with their response later (if any).