Upgrading to 2019.3a - FBX Import - Identifier uniqueness violation

Hi there!
TL;DR: When multiple subassets are registered with the same name, we cannot certify they will keep the same local file ids if the source changes because in that particular case ids are assigned sequentially. Which means that if the order changes in the source file, the resulting ids will be mixed up.

The recommended way would be to prevent/fix meshes names in your fbx export so there is no duplicate. The FBX sdk report them only by name, which prevents us to generate fixed ids when we have multiple ones with the same name.

The AssetPostprocessor cannot help you in that case because Meshes are already registered in the Importer when you can access them.

Long story:
Before 2019.1, local file ids were generated in sequence and stored in the meta-file, with the subasset name as a key, in order to match them with the previous id during the next import. This forces the meta-file to be changed each time a new subassets is created during the import and would trigger a re-import until there is no change to the meta-file.
When two subasset are using the same name, the next reimport will find two entry for this name in the saved id list and will use them in order. That means if a new subasset with the same name is found before an existing one, it will take that existing id and the original subasset will be assigned to a new one. <- this is really the only moment this warning is for and we feel it's better to let you know that upfront instead of leaving people in the dark when all their references get mixed up in a scene because someone added a new "CubeMesh" at the top of the fbx file hierarchy.

In 2019.1 we changed that mechanism to make it more deterministic. The local file ids are based on a hash of the registered name and no map is needed anymore.
Unfortunately, we had to keep a sequential registration if multiple subassets are registered using the same name in the ModelImporter because there is no way to differentiate them. The fbx sdk allows using multiple objects with the same name, especially for meshes, and because we cannot prevent that during the import, we decided it would be better to let users know about it with a warning instead of ignoring the problem. The warning got added in 2019.3 and will be backported to a future 2019.2 release.

It does not mean we don't support it anymore, or that you cannot do that. It is OK to continue doing so and we will never prevent it for the ModelImporter, it's just that we tell you that references to these meshes can break without notice when the fbx file is changed. If you are aware of this limitation and using that in your development process, it is still fine to do so.

 

Yes, we have the hierarchy info for each node in the fbx, but that part is building the transform hierarchy, and not the meshes.
Multiple nodes may refer to the same mesh instance in the fbx, and at the time we resolve the meshes it is not possible to use that hierarchy. Also the implementation of the FBX importer is very old in Unity, and while we are trying to make changes to make it better, we have to keep it compatible with old stuff, which makes it very difficult to change everything. We will try to see what can be done in the future to fix such bad behaviour...

While this is prevented in maya, you can do such things in 3dsmax and the FBX SDK allows it anyway, so we still need to support anyone using that functionality in the SDK.

 

This bug is a particular issue we had with the local file ID migration from 2018.x to 2019.x.
The next version of 2019.2 (probably 2019.2.2f1) should be the first release with a fix for it, we got the bug report in our hands too late to make a fix and ship it before the latest 2019.1 release.

So yes, to be clear, the project upgrade should always work, if it does not, it's a bug, but changing the mesh source may break and that's why we added a warning for.

 

QA was able to reproduce the issue: https://issuetracker.unity3d.com/product/unity/issues/guid/1189683/

For the reproducible that @funkyCoty provided: when upgrading to 2019.2.2f1, at first references are not lost but after Reimport All references become missing.

 

This warning is in place to let you know that multiple nodes in your model have the same name and parent and that because of that, there is no guarantee from Unity that the generated Meshes will have a consistent ID.
The long term result could be that at some point you may update that model and all Meshes in your scene will disappear.

To avoid the issue (and get rid of the warning), you should make sure that the model you are using does not have any name duplicates in its hierarchy. If you got this mesh from another company you should reach out to them to ask for a fixed version with unique names at each node level. You can also probably open that Model in any other DCC (like Maya or Blender) and rename the faulty nodes.
Here is a picture that illustrates an invalid and a valid hierarchy from an imported Model:

 

I see what you mean. We will discuss it with the team.
I think the warning is important (we had a bunch of bugs opened related to meshes and components references missing after a model update, which is why we added the warning), but maybe we can add an importer option that would remove the warning for a given model ("I know what I'm doing and I'm fine with conflicting names, don't warn me for this one")

 

The hierarchy you are providing is working without any issue.
Duplicate names at the same hierarchy level can hide further reference issues and will display a warning.

• ParentObject
  • ChildA
    • SubChild
    • SubChild
  • ChildB

This hierarchy may have an issue because we have two nodes under ChildA with the same name.
However, there is no issue with this one:

• ParentObject
  • ChildA
    • SubChild
  • ChildB
    • SubChild

Because even if they have the same name they belong to a different parent, so everything is fine.

To give some more insight, we have to generate a unique FileID for each node (so you can reference them, and their Meshes, Material, components, etc... from your scene or another asset). That FileID is based on the full path of the node, the node name itself, and what the component type is.
In that case, we combine the path from the root node with the node name (ParentObject/ChildA/SubChild) and add the node type (a GameObject in that case). That will gives us our FileID.

If you have two children named the same with the same hierarchy path, you end up with the same FileID being generated, which is not possible. To make it work, we arbitrarily add an incremental value to the second FileID so it does not collide with the existing one (and that's when the warning occurs).
But that solution assumes we always read both nodes with the same name in the exact same order... But then, what happens if the first SubChild node is removed? The second node is now alone and will not have the FileID incremental bump, which means its FileID changes and all references to it get lost... (and even worse, references to the deleted node now point to the second one...)