Infinitely growing "fileIDToRecycleName" in modelimporter meta files - when will the madness end?

Hi all,

In my meta files for our FBX meshes, we have a problem. The fileIDToRecycleName keeps growing every time we do an import, and it's honestly... ugly and painful to deal with in our source control.

I guess I'm just wondering about `fileIDToRecycleName` and if there ever will be a better approach to handling those. I think I understand the basic premise. The Unity Library needs to maintain this proper mapping between the named FileID and a number, and it keeps recycling them or creating more entries every time a new import occurs or the library is regenerated, or I install the project on a new machine, etc.

However, we've had clashes on a few occasions when dealing with committing these, because the order is somewhat random and weirdly references names that have nothing to do with that particular asset, and if I commit something with a new fileIDToRecycleName and someone else does a similar reimport - whose library gets priority? Should I be the one deleting my library in order to regenerate things, or should my partner, because if we deal with the merge conflicts, then Unity is unhappy for both of us.

Either way, this is getting a bit clunky. Our meta files for all of our FBXs are full of hundreds of references to things that have nothing to do with those particular models; every time we reimport on a new machine, tons of new references are created; we've had serious clashes that have cost us hours of work of having to wait for a full reimport when merge conflicts arise in this space, etc.

Honestly, it seems like downloading and opening a project each time shouldn't cause file changes, but that's how it seems to be. Is there a better approach to cleaning these, or is Unity planning on changing how this approach works, because it's fairly problematic and undocumented.

^ this is a gif of ONE file out of hundreds that changed on a recent reimport - and this meta file is polluted with tons of references to things that don't exist in this FBX, and never did exist.

What can be done about this seeming problem?

 

We don't have those issues with our projects, so I don't think it a general Unity problem. Getting a fresh project copy from version control does not modify .meta files here.

Did you customize Unity's import pipeline? If that's the case, perhaps an AssetPostprocessor is modifying something that causes these changes?

Are you able to reproduce also with different/new project?

 

We do have a custom AssetPostprocessor, but without knowing what this whole fileIDToRecycleName business is about, I couldn't tell you if we're modifying it. Like, our AssetPostprocessor isn't directly messing with fileIDToRecycleName, and we're not sure what fileIDToRecycleName even is or what does or doesn't modify it. We're also using Odin, but only in 'Editor Mode' and not for serialization.

What's really bizarre is that fileIDToRecycleName of a particular meta file will contain names of things in other assets. Like, if we have a table, that table's fileIDToRecycleName will contain name references to part of a bed in another FBX, etc. It's very strange.

After a bit of research, I've noticed that the reason the fileIDToRecycleName list grows is that after cloning a project, there will be some weird first-time Unity errors that have nothing to do with our code, but which prevent our AssetPostprocessor from executing (somehow that assembly fails to load? no idea). Because the AssetPostprocessor didn't run, the FBX files import without it. (Our AssetPostprocessor does some material linking and scrubs out some dummy objects such as 'Directional Light', 'Camera', and 'Texture Locator' transforms from the FBX file.) So then, we restart Unity and the weird first-time errors go away and AssetPostprocessor imports correctly, but our FBX files have already imported, so we have to reimport all of the FBX files. Upon reimport, the meta files for those FBX files grow their fileIDToRecycleName list.

It also seems that the new entries in fileIDToRecycleName are required for the person who cloned the project, and not for people who had it before. So, if a mesh called 'Trim' mapped to 100014 in my project, it continues to do so, and the 100014 seems to point somewhere to some place in the Library folder where the imported version of that mesh resides as a binary file. But if Aurel imports the project, it'll add an entry for him that maps 'Trim' to 100048. From that point on, if we remove '100014: Trim', it breaks for me. If we remove '100048: Trim', it breaks for Aurel. It's almost like our Library folders import the project differently and link the imported meshes differently through the meta files.