Search Unity

  1. Unity 2019.2 is now released.
    Dismiss Notice

Upgrading to 2019.3a - FBX Import - Identifier uniqueness violation

Discussion in '2019.3 Alpha' started by kalineh, Aug 2, 2019.

  1. kalineh

    kalineh

    Joined:
    Dec 23, 2015
    Posts:
    67
    Testing out some upgrades to 2019.3a, we are getting some fbx mesh import warnings, along with some missing mesh filter references.

    Identifier uniqueness violation: 'Name:SurfaceMesh, Type:Mesh'. Multiple Objects with the same name/type are generated by this Importer. There is no guarantee that subsequent imports of this asset will properly re-link to these targets.
    It seems like the FBX importer cannot handle child nodes with non-unique names. In the model hierarchy for example:

    Root/ChildA/SurfaceMesh
    Root/ChildB/SurfaceMesh

    ^ will give warning for non-unique SurfaceMesh name. I can't seem to find anything in the ModelImporter docs explaining this clearly, or if it's a problem at all (we've had this structure for a long time, but only recently has it caused missing mesh filter references).

    It seems possible to rename all the generated hierarchy nodes on model import (OnPostprocessMeshHierarchy) but this doesn't affect the actual UnityEngine.Mesh instances in the asset.

    Is there some recommended way to deal with this? Can we override the name on import somehow? Force generating unique names? Should it be fixed in some FBX export step instead?

    Seems like it would be rather common but I'm not finding much posting about it.
     
  2. Lynxed

    Lynxed

    Joined:
    Dec 9, 2012
    Posts:
    46
    I'm actually interested in this too. I would prefer to have hierarchy-type matching rather then by name one. Or an ability to choose one. Some of my import stuff relies on object names being the same.
     
  3. bastien_humeau

    bastien_humeau

    Unity Technologies

    Joined:
    Jun 14, 2017
    Posts:
    24
    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.
     
  4. kalineh

    kalineh

    Joined:
    Dec 23, 2015
    Posts:
    67
    Okay, understood! I'd request some info added to the ModelImporter docs, it seems pretty important!

    Does the FBX SDK not give you the hierarchy info? It seems like generating the hash from a full hierarchy name would be more stable than just the child node name - though it still doesn't prevent some cases. Our testing with maya it seemed that for a given node each child name had to be unique anyway.
     
    fherbst likes this.
  5. bastien_humeau

    bastien_humeau

    Unity Technologies

    Joined:
    Jun 14, 2017
    Posts:
    24
    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.
     
  6. kalineh

    kalineh

    Joined:
    Dec 23, 2015
    Posts:
    67
    Thanks for the detailed explanation!
     
  7. Elecman

    Elecman

    Joined:
    May 5, 2011
    Posts:
    1,326
    Is this related the bug report below? I cannot import my CAD based model (Inventor->3dsMax->Unity) since 2019.1 because lots of mesh references are missing on import.
    https://issuetracker.unity3d.com/is...hes-become-broken-when-updating-to-2019-dot-1

    Judging by the post above, this inocrrect FBX import behavior is a new feature and not a bug, yet in the bug report above it is not marked as "By Design".

    The weird thing is that if I import the FBX into Unity, it works fine, but if I upgrade my project form 2018.x to 2019.x, thousands of meshes are missing.

    I am ok with things breaking if I change the mesh source again and then re-importing, can we at least get a project upgrade to a newer Unity version to work?
     
    Last edited: Aug 6, 2019
  8. bastien_humeau

    bastien_humeau

    Unity Technologies

    Joined:
    Jun 14, 2017
    Posts:
    24
    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.
     
  9. Elecman

    Elecman

    Joined:
    May 5, 2011
    Posts:
    1,326
    Ok, thanks for the explanation. Looking forward to the fix.

    By the way, I really appreciate you take the time to explain what is going on with this issue. I was left in the dark for months, not knowing if this was ever going to be fixed at all. Now I know there is light at the end of the tunnel. So again, thanks :)
     
  10. funkyCoty

    funkyCoty

    Joined:
    May 22, 2018
    Posts:
    4
    If we've already upgraded to 2019.2.0 will this 2019.2.2 fix help us? We've got a ton of missing references as well, just been going through and fixing them by hand. And if it does fix it, if the FBX is again updated will the references stay in tact? Thanks
     
  11. markvi

    markvi

    Unity Technologies

    Joined:
    Oct 31, 2016
    Posts:
    51
    Can you submit a bug report with a minimal project that demonstrates your problem and post the case ID here? That way we can test against your FBX file and make sure it works.
     
  12. Elecman

    Elecman

    Joined:
    May 5, 2011
    Posts:
    1,326
    Here is my repo: 1141428. It is marked as a duplicate but you might want to double check that it works.

    I had to submit the same project twice to some other QA staff because initially they thought it was caused by a deprecated Texture2D reference which I assured them wasn't the cause, but they wouldn't believe me. :rolleyes: