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?
https://issues.unrealengine.com/issue/search?q=fbx+reimport&resolution=open

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:

https://answers.unrealengine.com/questions/26619/combine-meshes-flag-not-respected-on-reimport.html
https://answers.unrealengine.com/questions/522108/414-p3-fbx-reimport-static-mesh-combines-all-the-m.html

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).

Nope, this is a pretty low priority UE4 bug probably (compared to crashes and so on) and right now Epic is preparing for GDC so there's little happening on the engine side.

I could make a patch that fixes this in the Blender side but it would be pretty niche because you would have to have wrong object names in the first place and the bug only occurs when using multiple meshes in a merged mesh in UE4. I'm not sure how happy @Bastien Montagne (mont29) and @Campbell Barton (campbellbarton) are with having even more niche options in the FBX exporter.

I’d really rather not have something like that in our exporter indeed!

[Note that names don’t have to be unique in FBX, it’s using an UUID system for its nodes]

Now, why can’t you just run a small py script like that before exporting to FBX for UE4?

import bpy
import re

regex = re.compile("([^a-zA-Z0-9_´\¨§¤+])")

do_loop = True
while do_loop:
    do_loop = False
    for ob in bpy.data.objects:
        new_name, num_changes = regex.subn("_", ob.name)
        if num_changes > 0:
            ob.name = new_name
            do_loop = True

That will remove all non-UE4-supported chars from object names in current .blend file (just ensure to save your faile before hand, and restore it after exporting, or even better, export from a temp .blend copy, to be sure no to mess the original file with weird names).

In T53965#486525, @Bastien Montagne (mont29) wrote:

Now, why can’t you just run a small py script like that before exporting to FBX for UE4?

Maybe I'm misunderstanding something, but surely this is a really bad user experience? Imagine having to manually run an additional script before each Blender build, a developer would fix that very quickly.

Ideally UE just fixes it on their side, but if nothing happens maybe it is reasonable to have an option (enabled by default?) that replace certain characters.

In T53965#486525, @Bastien Montagne (mont29) wrote:

Now, why can’t you just run a small py script like that before exporting to FBX for UE4?

This is fine if you know what you're doing but if you're not (let's say a UE4 user trying out Blender for the first time) it's easy to end up with objects that have .001 suffixes. Then if you want to have multiple objects in Blender but merge them in UE4 you can run into this problem when trying to reimport the objects. And when that happens there are a few different things you can do:

1. Say "Blender sucks!" and never use it again.
2. Try to find out what happened, maybe search the UE4 forums/answerhub and find out that the dots in the object names causes this problem, then rename every object and reimport again.
3. As 2 but write a script to do the renaming.
4. Edit the FBX exporter code to rename objects on export.

Right now 4. is the most reasonable because you will only need to do it on every Blender version update and it will work for all objects with .001 and so on without running any scripts before export. However it would be even better if you didn't need to do this at all (if there was an option in the FBX exporter to do this). I don't see the problem with adding options to the FBX exporter if it will make things work better. Right now there are a few issues in the Blender-UE4 workflow, the biggest being the 0.01 unit scene thing (with Blender default settings rigs/animations get messed up), there's also this issue with reimporting multi part objects with .001 etc suffixes and the fact that actions and shape key actions are not linked has also been confusing for UE4 users.

That will remove all non-UE4-supported chars from object names in current .blend file (just ensure to save your faile before hand, and restore it after exporting, or even better, export from a temp .blend copy, to be sure no to mess the original file with weird names).

This is not something you want to do in an asset pipeline, you would just want things to work without worrying about running random scripts. Especially if you're not comfortable with python scripting.

In an asset pipeline you want things to work, how they work under the hood is not that important to the end user. I don't believe other software put dots in names, most allow duplicate names and you have to actually fix that before exporting so in this sense Blender is better, but there's no way to change the dot delimiter to something else in Blender currently which causes this problem.

I can understand that this is not considered a bug because it doesn't cause problems in Blender, but it does cause problems in other software where the final .fbx is used. By the way, UE4 for example already has code fixes for Blender bugs. It's disappointing for someone who wants Blender to be seen as a real alternative to other software for use in game engines. And I think this attitude only hurts Blender's image in the long run.

I don’t see how having code fixes in UE4 for Blender bugs help any project at all? Blender bugs are to be fixed in Blender, not in some other tool! We have a tracker to report issues, precisely to fix Blender bugs…

It helps the Blender-UE4 pipeline so it helps users of Blender using it in combination with UE4. In this case it was FBX related and maybe hard to fix in Blender, so it was fixed in the UE4 side instead. If you're curious it's the "armature creates an extra bone in UE4" problem, I'm pretty sure that has been reported before. Maybe not a bug per definition if it's working as intended, but it caused problems in UE4 because you could not share rigs between characters, had to animate root motion in object mode and so on. For me as long as it works smoothly it's not too important where issues are fixed.

The naming patterns for data blocks in blend files should be handled separately from the exporter. As this can be a general case not just related to the IO but also scene/collection organization. That could be an task for an included add-on in the future.

I don't see why something like that should be an addon instead of a core feature in User Preference - Editing or somewhere.