koobas.hobune.stream
Unity Inspector limiting display of nested lists.
I'm having a problem where when I want to inspect an object that has nested lists in the inspector causes the unity editor to become unresponsive.
I basically have the following code:
[System.Serializable]
public class Cell{
public List<Cell> AdjacentCells;
}
And a monobehaviour that has a Cell[].
In my current testscene I have 4 Cells and each of the cell has the three other ones as an adjacent cell, so: cell 1 has cell 2, 3 and 4 as adjacent cells. cell 2 has cell 1, 3 and 4 as adjacent cells. etc.
the problem is when I want to inspect that monobehaviour to make sure all adjacentcells are properly set, unity becomes unresponsive because when it want to display the properties it is basically doing an endless loop through those lists of adjacent cells.
Now I was wondering if anyone knows of a way to make a custom inspector that only shows the adjacent cells for the root nodes?
The problem is that this can exceed the serialization depth limit. Your cell has a list of cells, each of those has a list of cells, and so on potentially infinitely.
Please see my answer on this question for a possible solution.
If i understand correctly, you are suggesting to replace the List adjacentcells with a List containing the indices of the cells?
This kind of structure is not supported by Unity's serialization system, It's not really a visual / display problem. Custom serializable classes are not serialized as unique instance but simply has sub and sub-sub properties of the MonoBehaviour instance. Circular dependencies are not supported at all. The serializer usually detects such things since it simply stops after a nested depth of 7.
You need your cells as an actual asset which can be referenced. So either make it a MonoBehaviour or a ScriptableObject. Those can be serialized on their own and have an actual asset / instance ID which is used for cross references between assets / instances.
An alternative way is to only have a single array with all cells in it, make the List non serialized and use the ISerializationCallbackReceiver interface to save the cross references in a different way. For example as indices into that large array. Though it's usually better to use ScriptableObjects and save them as assets. Keep in mind that you can save multiple ScriptableObjects into a single assetfile. Just have a look at the AssetDatabase and more specifically AddObjectToAsset.
Of course displaying them in a tree-like fashion requires you to create a custom inspector for your MonoBehaviour,
ScriptableObjects unfortunately won't work for me, as I generate the cells at runtime. I could turn it into a $$anonymous$$onoBehaviour and that will also give me some other benefits unrelated to this problem. The only thing I worry about is the performance impact: I could see use-cases where I would have 10,000 cells, I don't know what kind of performance impact those 10,000 monobehaviours would have.
Huh? You can create ScriptableObject at runtime just like you can create $$anonymous$$onoBehaviours at runtime ^^. The inspector is mainly ment for displaying serialized data at edit time. If you just care about displaying the classes at runtime, you can simply make your List "NonSerialized" so Unity's serialization system doesn't mess with the list.
Now you can implement a custom inspector that directly reads the instances from the "target" instance and displays the GUI you like. However you have to explicitly display the GUI for each variable manually as you can't use SerializedObject / SerializedProperty for this. So this wouldn't be a generic solution but a specific custom solution for your "Cell" class. If you have trouble getting started with I$$anonymous$$GUI, have a look at my GUI crash course ^^. Currently (at least what you showed us) your Cell class is essentially empty so we can't tell how difficult the GUI might get.
edit
I had once such a case where i didn't create a custom inspector but a quick and dirty EditorWindow to display the structure of my neural network. It was a pure "viewer" to inspect the current weights of each connection.
