Feedback Trying to add new data to FBX imports is absolutely miserable

(Using Unity 2021.3.11f1) Today I tried making an AssetPostProcessor for certain FBX files, so that I can give them new data.
My one goal was to give certain skinned meshes access to their pre-skinned vertex positions, put into UV2, which I cannot do outside of unity (as software like blender expects uv to be a vector2, and does not have the capacity unity has to make it a vector3/4).

Code (CSharp):

1. private void ModifyMesh(Mesh mesh)
2.     {
3.         var vertices = mesh.vertices;
4.         mesh.SetUVs(2, vertices.ToList());
5.     }
6.  

I've done it in runtime before (example code above), but doing it in runtime is both slower than I'd like, wasteful on memory, and not as clean to discern where information is coming from, so I determined I should Post Process my FBX imports.
I didn't want to make this happen to all my meshes, as that would be unnecessarily slow.
I didn't want it to be controlled by specific file names as I find those incredibly restricting.
And I didn't want to use asset tags as suggested by this blog post, because the assets already contain user properties that say how they should be handled.

I saw that OnPostprocessGameObjectWithUserProperties exists, and I confirmed that it does detect my FBX's custom properties. It mentions having full control over the mesh so I figured that's great... as an experiment - grab a reference to the MeshFilter from a test-cube gameobject, the sharedmesh from that one, and call the method mentioned earlier...except this introduced a warning that shows up every time I reimport:

Importer(FBXImporter) generated inconsistent result for asset(guid:guidhere)"namehere".

No matter what I try, this warning does not go away. Any type of change I try to make in the method, to the mesh, is met with this annoyance.

I tried exploring other avenues of changing the mesh - perhaps in earlier methods. The information is incredibly scarse and I don't see a single way to obtain the reference to the mesh in any part of the asset post processing pipeline short of getting a component and fetching a shared mesh from that.

Additionally, there is no way to obtain the user properties short of waiting for the exact first method I mentioned, so even if I wanted to use my user properties, I have to wait until that one moment, which seems to have issues.

The research did point out to me that Asset Importers have a userData field, so I could make checkboxes within unity itself and use those from the start of the import process, which sounds incredibly appealing. It is a string so separating it into fields can be a hassle but it also means it is flexible...great. I'll try to extend the model importer editor to have a checkbox for whether my new UVs should be made, writing into userData, and then just check for that to modify my mesh....

Except the ModelImporterEditor is internal, trying to make a new editor for it from scratch would be miserable due to the loss of the UI provided by the original, and trying to make a wrapping editor for it extending from AssetImporterEditor is futile because it makes a bunch of incoherent errors despite successful compilations. The most notable one being

The previous instance of MyProject.Editor.ModelImporterEditor has not been disposed correctly. Make sure you are calling base.OnDisable() in your AssetImporterEditor implementation.

Can't even add a tab to the existing 'Model/Rig/Animation/Materials'.

So extending the model importer editor is no good, making my own model importer editor is a huge hassle that won't be maintainable if unity ever updates its own, and is no good, trying to use my already existing user properties already present on the model is no good... and I'm not done yet.

I figured if I can't add new fields to the existing ModelImporterEditor, I can at least make my own desperate window just so I can add userData to the fbx which I'd like to edit. I went ahead and made my own EditorWindow, which checks the selection for an AssetImporter , and if it finds one, it shows me a checkbox to turn my flag on / off. That worked great...except I have one checkbox and the minimum size for an editor window is 100x100. I found the .minSize field, and set it to 10x10, and that worked wonders...when undocked. I then tried to dock it to the bottom of my inspector...and it was suddenly back to being giant. Some more frustration later and apparently the minsize for docked windows is static and internal, so I can't ever fix that in the current existing version of Unity.

After a few hours of trying everything I can think of, I don't have a single working clean, nor intuitive, nor even functional solution. It's incredibly difficult to tell whether the problems are of my own making or actual bugs from unity's end. I'd love any type of help I can have in order to make this asset post processing work without stupid warnings, and without heavy compromises like tags, specific path conventions, or permanent window layout space sacrifice.

tl;dr:
1. changing mesh data in

AssetPostprocessor.OnPostprocessGameObjectWithUserProperties 

throws an inconsistent guid warning on every reimport attempt.
2. User properties cannot be obtained earlier in the asset post processing pipeline
3.

AssetImporter.userData 

exists, but there is no easy way to show it nor any other information on Unity's default asset importer editors, as they are uneditable & unwrappable by any conventional means.
4. Making an external a separate editor window to set the userData means sacrificing permanent layout space consumption of far too many pixels for the simple cause of a single checkbox.
5. The default ModelImporter has 4 tabs, but does not let users add more, despite the many possible and positive use cases.

Today ended in defeat, but I hope this feedback can at least help drive future versions of unity to be far less painful than what I had to go through, and still have to keep searching through, just to...add a checkbox... and have it run 2 lines of code on a mesh.

 

Hi, first - thank you so much for taking the time to respond to this post.
I've since made more iterations and attempts at it, as well as having reported the inconsistent warning with the IN-28865, and the inability to adjust anything regarding the ModelImporterEditor on IN-28870.

Here's the smallest script I've deduced can be used for the asset post processor, to replicate the issue.
I also confirmed that as you mentioned, reimporting all assets 'solves' this issue, but its incredibly long a process and I'd prefer manually collecting and allowing a 'reimport all things that would be affected' (a far smaller subset) than the former, or at least to suppress the warning for a day.

Code (CSharp):

1. using System.Linq;
2. using UnityEditor;
3. using UnityEngine;
4.  
5. namespace Editor
6. {
7.     public class CustomAssetPostProcessor : AssetPostprocessor
8.     {
9.         private void OnPostprocessGameObjectWithUserProperties(GameObject go, string[] propNames, object[] values)
10.         {
11.             var meshFilter = go.GetComponent<MeshFilter>();
12.             var mesh = meshFilter.sharedMesh;
13.             mesh.SetUVs(2, mesh.vertices.ToList());
14.         }
15.     }
16. }

The example of the custom dependency mentioned in (1) mentions that I cannot set those while the asset is importing, but I only get to know that on the post process, which sounds too late. What do I do in this case? the only 'dependency' is the fact that my model has custom user properties in this case, I'm not even checking which one to allow branching in this minimal example.
For (2) - updating the version, this is actually great to know, thank you. I'll give it a go later when I have the chance. It does sound ever so slightly tedious but I fully understand the need.
For (3) - I fully understand - and believe - that my import process is deterministic.
If updating the version is all I need to secure a warning less import, that sounds fantastic.
(Also, example project in IN-28865 with simple cube asset that has custom user properties, in case it matters)

I did feel that notion as well. I've looked at other developers' usage of it (however little I could find) and it seems that there are no standards whatsoever, some serialize with jsonutility, some parse it by splitting commas, its all over the place. Dictionaries - or a system to directly add our own fields / check if they exist in meta files, would be splendid.I borderline considered doing manual text scanning & editing of the meta file before finding the userdata, but I feared it won't survive a reimport or the likes because there is no way for me to 'protect' fields in it from whatever Unity may do (that I don't know).

That's sad to hear, but yes - solving the root issue is better than solving the symptoms individually, please.

The problems isn't the tabs per se - but rather that there is absolutely no way to use already existing code of the model importer editor without rewriting it all manually and praying no other internal code is relied upon. It brings up all sorts of questions like...
1. Why aren't there importer editor wrappers in unity by default? surely adding power tooling around importers would have been better than the limited 'presets' years down the line. letting developers add buttons to set all their settings or include extra information sounds like something that would have been more common...
2. Why is the code around those editors flagged internal instead of public? we can't even refer to them directly. as it stands, none can go make tabbed ui editors right now using unity's implementation.
3. Why can't importer editors be created inside other importer editors? (will make more sense with example snippet below)
4. sans all other options, why is there no clean "add your own settings / ui to editors here and it will be found and used"?

For my desperate attempt at wrapping the ModelImporterEditor, I started with this: (also found in IN-28870)

Code (CSharp):

1. using System;
2. using UnityEditor;
3. using UnityEditor.AssetImporters;
4. using UnityEngine;
5.  
6. namespace Editor
7. {
8.     [CustomEditor(typeof(ModelImporter))]
9.     public class CustomModelImporterEditor : AssetImporterEditor
10.     {
11.         AssetImporterEditor _originalEditor;
12.  
13.         public override void OnEnable()
14.         {
15.             _originalEditor = CreateEditor(targets, Type.GetType("UnityEditor.ModelImporterEditor, UnityEditor")) as AssetImporterEditor;
16.             base.OnEnable();
17.         }
18.      
19.         public override void OnDisable()
20.         {
21.             DestroyImmediate(_originalEditor);
22.             base.OnDisable();
23.         }
24.  
25.         public override void OnInspectorGUI()
26.         {
27.             serializedObject.Update();
28.  
29.             _originalEditor.OnInspectorGUI();
30.  
31.             if (GUILayout.Button("Do something"))
32.                 Debug.Log(("I did a thing"));
33.  
34.             serializedObject.ApplyModifiedProperties();
35.          
36.             ApplyRevertGUI();
37.         }
38.     }
39. }

Sadly, the mere act of having this editor wrap another, makes "previous editor was not properly disposed" at any selection attempt between models. This would make it fatally annoying to work cleanly. The usage of a wrapped editor also makes the ApplyRevertGUI show twice, as well as the list of the assetpostprocessors - apparently they've been oddly added to the end of ApplyRevertGUI instead of being separate from the importer editor system?

I suspect I can mark my wrapper to not need ApplyRevertGUI, and remove that method call, since I can trust it is called from ModelImporterEditor, but this still won't solve the errors. The AssetImporterEditor demands I call base.OnEnable / base.OnDisable, but calling them is what causes the issues, seemingly.

As a side note, switching the extension from AssetImporterEditor to just Editor, makes the errors disappear, but I obviously lose the apply revert functionality, which is a deal breaker.

Also - if I may have more of your time please...
As I continued my experiments in the form of using AssetPostProcessor, another thought popped into my head, the idea of appending a settings object to the asset, and then relying on it. However, reasonably, it seems that appended objects in assets cannot be edited - the inspector is grayed out. I also don't like the idea of plentiful objects in assets I never plan to mess with, so I understand - but is there a way to enable such editing of appended objects in assets anyways?

I assume this is the reason animation clips cannot be edited in fbx importers directly, but only through the importer window. the values actually belong to the importer and the generated assets are uneditable. Still, it makes me wish that there was a way to make edits without having to completely disconnect the clips from their original asset...

 

Going the companion file road is also worse in many senses since now managing moving a single resource around requires you find all its companions and move them along. The inspectors are also separate so you can't have a full view in a single place... even if I do choose to go the companion route, how do I determine/find the companions to my file, without wrecking the import process performance? can you provide an example please?

I'm somewhat stumped - while I can understand a scripted importer depending on other files to make its own content, I'm unsure how to create this situation for an fbx file's post processor... let alone conditionally.

If I make an asset depend on the artifact of another, does this automatically setup the import order so that the artifact has to always be made first?

My current imagination of this is that on importing my model, in the post process, I would have to find scriptableobjects / 'companion assets' , set them as a dependency in the post process, using DependOnArtifact? Then I simply author them separately and ensure they're found? what would be the quickest way to ensure they're found / don't get screwed up by import order? is there some GetDependedAssets method I can rely on?

Is there a way said scriptableobject can declare itself as a dependency of the model instead? does that make sense at all? do I need to do anything to ensure those scriptableobjects always get imported earlier than models such as with a scripted importer?

I assume at minimum trying to figure out a right click fbx file -> create attached companion asset would be useful...

This of course doesn't solve the aforementioned user experience issue, having to create and witness the assets separately will still be wasteful on time... Is there any way to override what the inspector sees in general? I could try to add something along the lines of "if inspecting a modelimportereditor, also do stuff like..." (show the scriptableobject contents/checkbox /create button?)

Thank you so much for your time and explanations again!

 

Thank you again for your time and effort. I took the time to try it out and some more things, here are my results.

First, I tried out the script exactly as you wrote it, with the only change being the inclusion of 'do what you want here'.
Sadly... even with adding that,bumping the version of the importer up to 2, and going in my project to try it out (using the context menu to generate the companion asset, setting the bool to true)... nothing happens.

The change in the companion asset - even after a project save, does not trigger a reimport of the model. Reimporting the model shows that it does find the companion asset, and relies on its content...but the inconsistent warning still shows up...

I tried switching the DependOnSourceAsset to DependsOnArtifact, but this had no change. I still have to manually reimport, and I still get the inconsistent warning.

Interestingly, removing the companion asset does trigger a reimport and removes the extra asset's contents. It would seem like the fields within the companion asset are not respected for the purpose of hashing / warning, but the existence of the asset does?

Having to create a whole object per special feature is far less than ideal and bloats the project... quite significantly, the companion assets alone mean 2 assets per thing that needs the special feature. It also has some maintenance cost on searching, committing, and moving assets around...

For show of effort, I've opted to try and make an extremely easily visible result. I also added the MenuItem validation, changed the manual extension editing to use Path.ChangeExtension, and lastly made the context menu asset creation reimport the original asset, as the existence of the companion asset is meant to change its output.

This example 'works' but only in the sense that it changes the original asset, if the companion asset exists or not. Even if you add fields to said companion asset, the original asset's result won't change / will generate the warning. I hope someone else finds it useful...

Code (CSharp):

1. using System.IO;
2. using UnityEditor;
3. using UnityEngine;
4.  
5. public class CustomConfiguration : ScriptableObject
6. {
7.     private const string MenuItemPath = @"CONTEXT/ModelImporter/Create Custom Configuration";
8.    
9.     [MenuItem(MenuItemPath)]
10.     public static void CreateCompanionSetting(MenuCommand command)
11.     {
12.         var originalAssetPath = AssetDatabase.GetAssetPath(command.context);
13.         var configPath = Path.ChangeExtension(originalAssetPath, "asset");
14.         if (AssetDatabase.LoadAssetAtPath<CustomConfiguration>(configPath))
15.             return;
16.        
17.         var config = CreateInstance<CustomConfiguration>();
18.         if (!AssetDatabase.LoadMainAssetAtPath(configPath))
19.             AssetDatabase.CreateAsset(config, configPath);
20.         else
21.             AssetDatabase.AddObjectToAsset(config, configPath);
22.  
23.         AssetDatabase.ImportAsset(originalAssetPath);
24.  
25.     }
26.  
27.     [MenuItem(MenuItemPath, true)]
28.     private static bool ValidateCreateCompanionSetting(MenuCommand command)
29.     {
30.         var assetPath = AssetDatabase.GetAssetPath(command.context);
31.         var settingsPath = Path.ChangeExtension(assetPath, ".asset");
32.         return !AssetDatabase.LoadAssetAtPath<CustomConfiguration>(settingsPath);
33.     }
34. }
35.  
36.  
37. public class ModelImporterCustomImport : AssetPostprocessor
38. {
39.     public override uint GetVersion() => 5;
40.  
41.     private void OnPostprocessModel(GameObject go)
42.     {
43.         var settingsPath = Path.ChangeExtension(assetPath, "asset");
44.         context.DependsOnSourceAsset(settingsPath);
45.        
46.         var config = AssetDatabase.LoadAssetAtPath<CustomConfiguration>(settingsPath);
47.         if (!config)
48.             return;
49.  
50.         var material = new Material(Shader.Find("Specular")) { name = "Very Visible Example Material" };
51.         context.AddObjectToAsset(material.name, material);
52.     }
53. }

Now, this does bring up some more questions...
I know that AssetImportContext.DependsOnArtifact exists... but attempting to use it to detect changes in the scriptableobject's bool state seems defunct.
Is it because scriptableobjects have 'nothing to import'?
If I make my own scriptedimporter type and use that as my artifact, would that work instead?
Would I still have to make a dummy subobject import result?...

I'm trying to figure out how to make fields changing on the companion asset actually affect the original asset's import state, without causing the warning, and without being limited to 1 variation per entire extra object. (mainly because the code to manage them is not easy to mass produce/maintain, relying on multiple methods, keyed attributes, and a tiny context menu...)

Also, I tried to see if I can actually add extra visuals to any inspector, against my better judgement.
Apparently the Addressables package uses 'Editor.finishedDefaultHeaderGUI' to render its asset checkbox. Expanding on this, you can do whatever you want at the top of the inspector, regardless of what you're inspecting.


The above can be achieved with this code

Code (CSharp):

1.  
2. [InitializeOnLoad]
3. public static class SeeQualityOfLifeButtonsInInspectorHeader
4. {
5.     static SeeQualityOfLifeButtonsInInspectorHeader() => Editor.finishedDefaultHeaderGUI += ShowQualityOfLifeButtons;
6.  
7.     private static void ShowQualityOfLifeButtons(Editor editor)
8.     {
9.         if (!editor.target || editor.target is not ModelImporter)
10.             return;
11.  
12.         GUILayout.BeginHorizontal();
13.         if (GUILayout.Button("Create Companion Asset A"))
14.             Debug.Log($"Do whatever you want here");
15.         if (GUILayout.Button("Create Companion Asset B"))
16.             Debug.Log($"Do whatever you want here");
17.         GUILayout.FlexibleSpace();
18.         GUILayout.EndHorizontal();
19.     }
20. }

I don't love it, but it is far better than the prior manual hassles. With this, you can actually display - and edit - all the settings you want while still staring at the model importer, having one clean big picture.

Is there any way to actually bind specific settings as dependencies?
I see that registering a custom dependency cannot be done while importing the asset, which makes sense...
I tried source asset, but the fields changing do not trigger a reimport for the asset that depends on them.
I tried artifact, but there's seemingly no difference.
Did I do something wrong? please help?

And, going back to the userData each asset has... can those contribute to importing without the warnings? is there any way to register them as the dependency?