[WIP] Odin Inspector & Serializer Looking for Feedback

Gooren · April 1, 2017, 11:50am

Tor_Vestergaard:

With Odin still being in beta, with more features still to come and a lot of testing still to be done, this is a tricky one to answer, but I’ll do my best.

I could try to do a feature-by-feature comparison to Advanced Inspector and Full Inspector, and say things like “Odin offers more powerful editor customization with its attributes”, “We have much stronger features for input and scene validation, cutting down on entire classes of bugs”, “Our serialization is a lot faster and allocates close to zero garbage at runtime”, and so on. While those points are true, I’m not going to do that. (Except to the extent I just did )

The fact is that while Odin does have many features that Advanced Inspector and Full Inspector don’t, we also currently miss many that they have in aggregate. Of course, we’re adding more every day, and will eventually more than match them both put together if you put them on a point-by-point comparison list. However, we feel the core difference lies on another level, a qualitative as opposed to quantitative one, that touches every part of the product, and is not as simply put as just listing raw features side by side.

Imagine you’re a large game studio, with dozens of people working on a game in Unity. You’re all losing a lot of time to constantly writing custom property drawers to make your editors look nice, having to deal with the vanilla Unity editor’s many idiosyncracies and lack of powerful workflow features, and having to finagle your way around Unity’s limited and rigid serialization. You absolutely need an inspector upgrade, and so you look at what’s available. This is a huge decision to make.

Whatever you pick, this will affect every person on the team that ever touches Unity; whatever enhancements or limitations it offers, these will apply globally across your team. Since you’ve already spent significant time modifying your editor, it may also require a lot of integration work and rewriting of editor code before you’re back to the point you were before. If you plan on using the serialization, it can’t affect your game’s performance, which is already stretched tight with all kinds of neat features. And of course, being a large team with a huge project, containing hundreds of thousands of lines of code and thousands of assets, it is absolutely critical that the inspector upgrade be utterly reliable in a massive enterprise environment.

These are the kinds of extreme conditions under which Odin is intended to excel: being dropped into a major project, full of pre-existing editor customizations, with major demands on performance and stability, and still performing without a single hiccup.

In the given example, the team could simply drop Odin into their project, and immediately their inspectors have been upgraded across the board without them lifting another finger, touching the configuration, or changing a single line of code. Furthermore, all of their old custom property drawers and attributes, all of their old customizations, are still there, integrated into Odin.

They try the custom serialization: null values, polymorphism, cyclic references - all of it is handled and shown intuitively in the inspector. Their old custom property drawers are also being drawn for this new, non-Unity-backed data. Prefabs using the custom serialization work just the same as before - there is no perceivable difference.

Immediately, they can get to work again. There’s no onboarding, no radical new workflow or paradigm to learn. At their leisure, they can peruse Odin’s demos and documentation to get an overview of the dozens of new attributes they now have available to augment their editors. And then, finally, when their demands increase and change, Odin is highly customizable, with a modular and extendable design that can be adjusted to fit their particular needs. To help with this, every single public and protected member in Odin’s source code will be documented.

All of the above also illustrates an important point: Odin doesn’t change the way Unity works or enforce any new pattern on you. There is no integration boilerplate required. Where possible, it always integrates what is already there. If Unity adds a new data type, and a new property drawer for that type, or if they add a new property attribute that is drawn in a special way, that will be found and used by Odin. We don’t try to supplant or replace Unity - it’s solely an additive upgrade, not a lateral or subtractive one.

So that’s Odin’s ideal, so to speak: rock-solid reliability, extreme ease of integration, and making it trivial to design very powerful custom editors using only attribute annotations. It’s the rigorous standard Odin has to uphold before we’re satisfied with it. We want to deliver a dependable product of the highest quality, with a smooth and polished user experience, and we don’t want to compromise on that.

The current beta testing will bear out how close we are to having achieved this goal. We’re asking our testers to throw everything and the kitchen sink at Odin, to tie chains around its ankles and dunk it in the deep end of the pool without mercy, and see whether it sinks or swims. And once it swims, well, that’s when we’ll finally feel comfortable releasing it into the wild.

Thank you for such exhaustive answer, sounds like something I always wished for in Unity. Also thanks @brisingre for his insight on AdvancedInspector. We are going to buy Odin Inspector immediately on day one. And I feel like it’s going to be our #1 on MUST HAVE package list. How many people approx are working on Odin if I may ask? Also you mentioned some garbage on run-time. How much in comparison with Unity default serializer? This garbage is being generated only when scene is being loaded? Thanks in advance. This is some incredible work you are doing here guys. Top notch!

Tor-Vestergaard · April 3, 2017, 4:48pm

Sirenix is a team of three developers, who have been working full-time on Odin for quite a while now.

As for how much garbage we generate, it depends. Serializing using our optimized binary format - the format that runs in builds by default - generates very little garbage. In fact, when serializing and deserializing binary data, generally the only garbage that is allocated are the metadata strings. IE, if you have a field named “someField”, a string “someField” will be allocated during serialization/deserialization so we can know what the field is called. This is rather difficult to avoid.

The only exceptions to this rule are enums, which are currently boxed to the Enum type upon serialization/deserialization, and thus generate a tiny amount of garbage. It is theoretically possible to get around this using either unsafe or runtime-emitted code, we just haven’t done it yet.

As for when garbage is generated, generally during scene load, yes. To be more precise, in builds our serialization runs whenever an Odin-serialized object is instantiated from a prefab, or loaded. Instantiate serializes the prefab and then deserializes the data into the new instantiated object, while load merely deserializes the object from pre-existing scene or asset data.

Gooren · April 5, 2017, 8:30pm

Tor_Vestergaard:

Sirenix is a team of three developers, who have been working full-time on Odin for quite a while now.

As for how much garbage we generate, it depends. Serializing using our optimized binary format - the format that runs in builds by default - generates very little garbage. In fact, when serializing and deserializing binary data, generally the only garbage that is allocated are the metadata strings. IE, if you have a field named “someField”, a string “someField” will be allocated during serialization/deserialization so we can know what the field is called. This is rather difficult to avoid.

The only exceptions to this rule are enums, which are currently boxed to the Enum type upon serialization/deserialization, and thus generate a tiny amount of garbage. It is theoretically possible to get around this using either unsafe or runtime-emitted code, we just haven’t done it yet.

As for when garbage is generated, generally during scene load, yes. To be more precise, in builds our serialization runs whenever an Odin-serialized object is instantiated from a prefab, or loaded. Instantiate serializes the prefab and then deserializes the data into the new instantiated object, while load merely deserializes the object from pre-existing scene or asset data.

Thank you again for the reply. Sounds perfectly reasonable. Now I will just keep looking forward to the release date.

SuneT · April 10, 2017, 11:59am

New little feature: The AssetList attribute now also has functionality for non-array types. And, of course, it works with all the filters (Except for AutoPopulate):

P.s. Thanks to all the amazing beta testers, we’re getting very close to release now!

Naxite · April 10, 2017, 3:29pm

Just wanted to chime in and say I’m super excited for this! There’s been multiple times during development recently that I wished for even 10% of these features

SuneT · April 24, 2017, 12:32pm

What if I told you that you can win Odin for free in our Odin-will-soon-release-celebration-giveaway?
Join the giveaway here: http://vyper.io/c/1059

LightStriker1 · April 25, 2017, 2:29pm

brisingre:

I haven’t used Odin yet but I’m trying to move from AdvancedInspector because it’s caused me a bunch of problems. On complicated gameObjects with a bunch of scripts it would take 2 seconds for a letter to appear after you type it when you change a string, like it’s re-calculating something about every single AI-enabled script on the gameObject every character. It replaced Unity’s camera editor with one that is, as far as I can tell, identical except that it still pops up the little free version warning when you select Deferred and then uses Forward instead. I spent three days trying to figure out why my draw calls were so high before I figured out that the camera set to Deferred wasn’t actually rendering Deferred. Can’t recommend it.

Plus, there’s a good bit of boilerplate. It doesn’t affect your editors unless you #include AdvancedInspector, add [AdvancedInspector] over your class and [Inspect] over anything you want to inspect, which means it’s hard to add to an existing project and hard to strip out of one when it starts causing chaos.

To be honest, I believe you haven’t updated AdvancedInspector in quite a long time. The [AdvancedInspector] attribute was “retired” over two years ago.

Odin looks nice, by the way.

brisingre · April 25, 2017, 6:16pm

I’ve updated it, but I might not have updated it properly, i.e. deleting old versions manually and doing a clean install.

I’ll try that, and update my post if it works. That’s only fair.

That said, even if this fixes it, I’m going to try to switch to Odin, I think. My overall experience of Advanced Inspector is that, every time I’ve used it, it’s saved me a lot of work for a while by letting me do things like inspect List and whatever, and then eventually ended up creating a lot of work tracking down an issue that ends up being AI-related. It’s certainly not the first asset to ever make me track down an issue, but I really don’t want that from an inspector replacement. I really want it to “just work.” Perhaps that’s too much to ask, and I’ll have similar issues with Odin. Time will tell.

bjarkeck · April 26, 2017, 7:22pm

Here is how the newly added support for dictionaries looks. We also handle self-referencing infinite draw loops which the gif also showcase

Samuel411 · May 5, 2017, 5:40pm

Any idea on a day when the asset will be released? I’m looking forward to this asset!

alexanderameye · May 5, 2017, 5:43pm

I heard the asset was already sent to the Unity Asset Store review system

roykoma · May 12, 2017, 4:41am

Odin is released now.

Will of course buy it as soon as I have the money

SuneT · May 12, 2017, 7:43am

Yes, it is official! Odin is finally here.

Thank you so much to the Unity Asset Store team for approving Odin
We (Devdog and Sirenix) look very much forward to hearing what you think about Odin. We’ve been working super hard on it for the past 10-11 months now.

Landiron · May 12, 2017, 12:46pm

Congrats, looks good from what I saw so far.

I might have missed it in the manual, but how can I display Dictionaries with custom classes in the inspector ?

public Dictionary<enum, customClass> Dictionary = new Dictionary<enum, customClass>();

wont show up for me in the inspector.

Samuel411 · May 12, 2017, 1:34pm

I bought it, I’ll be playing with this for the next few weeks and i’ll write up a review on the asset store. Love you. Saving me tons of time from making custom editors for smaller things.

alexanderameye · May 12, 2017, 1:37pm

Will I only be able to create custom inspectors for my personal projects? Or could I create a custom inspector for an asset of mine?

bjarkeck · May 12, 2017, 5:01pm

There are a couple of ways to show dictionaries in the editor. The first one is to inherit from SerializedMonoBehaviour.
This means that the public dictionary field will be serialized, and Odin will, therefore, include the property in the inspector.

Another way is to add the [ShowInInspector] attribute to the field. However, then you will need to handle serialization yourself if you need it.

There is also the [ShowOdinSerializedPropertiesInInspector] which you can put on your MonoBehaviour class or base-class. This will mark a type as being specially serialized. Odin uses this attribute to check whether it should include non-Unity-serialized members in the inspector.

Odin will serialize any dictionary, and the inspector does not care what types the values are. But for the dictionary key type, we currently only support primitive types such as string, char, byte, int etc… However, enums is actually one of those types we could add support for in the future.

Samuel411 · May 12, 2017, 6:12pm

Is there a list of all the attributes that are added? Is this it? Odin Inspector and Serializer | Improve your workflow in Unity

roykoma · May 12, 2017, 6:20pm

http://sirenix.net/odininspector/documentation/sirenix/odininspector/assetlistattribute

You can find all the new attributes on the left side. Please open the corresponding section under Code Reference and open the “Attributes” item.

MaDDoX · May 12, 2017, 6:36pm

Very nice, I’ve been waiting for someone to (try to) tackle the slowness of custom serialization. I’ve been a dedicated tester of VFW and followed its serialization woes and breakages at each new Unity version release until the developer finally threw the towel and deprecated custom serialization. So, some questions before I purchase this in hope that it is the holy grail we’ve been searching for:

I’ve seen you got horizontal layout options, excellent - but how do you define the width of each horizontal section?
Can you define the width of key and value columns in the dictionaries inspector? Do you have settings like “Auto width”, “x% width”, “pixel width”? This is critical for the proper display of different dictionary KVP combinations.
As for your custom binary serialization, how ‘shielded’ from Unity’s several API changes at each new release do you expect Odin to be? FullInspector and others have had a tough time with Unity upgrades breaking their deserialization process.
How fast is your custom binary serialization when compared to Unity’s ridiculously limited yet blazing fast serialization?
Can you use Odin styling for EditorWindows?
Inlining by itself is a must-have, killer feature, I’ve done editor inlining manually and am pretty aware how painful it is to do it without a helper. Does your inlining implementation support Scriptable Assets?
Can your custom serialization work with non-MonoBehaviours, like StateMachineBehaviour for instance? I saw you have an attribute for class serialization, not sure if it works for this.