We’ve already made sure that Odin Inspectors editors are supported in the 2018.3 beta, but we’re still working on adding nested prefab support to the Odin Serializer. At this point we have a good sense of how much work it requires and we’ll do our best to make sure that Odin’s Serialization system will be ready before the release of Unity 2018.3. This has a high priority for us.
Unitys Entity Component System
Unity’s ECS is still in its early stages, but we already have a working Odin Inspector integration, so when the ECS API becomes a little more settled, it won't take us long to let you use Odin Inspector for your ECS data.
Unity’s New Editor Redesign
When Unity releases their new editor design overhaul, we’ll be the first to download it. As it transitions out of beta, we imagine that Odin will likewise transition into a completely different look from how it does now, to match the new style. We’ll still need to support the old design, and for this, we’re slowly starting to think about various ways for us to implement a styling system that not only adds toggleable support for the new editor design, but also gives more customisation options to the user and makes drawer creation even more powerful.
Odin’s property and drawer system is already a good fit for UI Elements on a technical level, as the principles are very similar. However, we’re still unsure about the real advantages of converting to UI Elements, but if it at any point becomes obvious that there are real benefits to be had then we’ll add in the support for it and slowly start the transition.
Unity for small things
We don’t really know much at this point, but as soon as we get our hands on a version, we’ll be on it to ensure that Odin works here as well. It will likely be very similar to their ECS inspector system, so Odin should also be very easy to integrate here once Unity for small things becomes public and the API settles down.
Generated AOT serialization formatters
Odin currently relies on reflection to serialize and deserialize data on AOT platforms, thereby losing the speed boost gained by emitting custom formatter code on demand on non-AOT platforms where a JIT is available. This feature would allow AOT platforms to gain a similar boost by automatically pre-generating custom formatters into the AOT support dll at project build time. Given Unity's continuing focus on IL2CPP and AOT compilation, Odin has since its release moved steadily towards rock-solid AOT platform serialization support, and this is the final step on that journey.
Much of the work has been done already, and the code hooks for this already exist in the AOT support generation pipeline. The bulk of the remaining work lies in generating custom formatter IL in a manner sufficiently similar to the C# compiler that IL2CPP will be able to parse it into C++ code.
Attribute Expression Compiler
Currently, specifying complex logic for attribute parameters such as for example [HideIf] requires defining a local member on the class containing the logic, and referencing that member by name in an attribute parameter. With this feature, it will be possible to write expression strings directly as attribute parameters.
[ShowIf("Condition")] public string myString; public float myFloat; private bool Condition() => myFloat > 0f && myFloat < 10f;
[ShowIf("$myFloat > 0f && myFloat < 10f")] public string myString; public float myFloat;
This would also allow you to directly reference static members in other classes.
[ShowIf("$MyStaticClass.MyCondition(myFloat)")] public string myString; public float myFloat;
This feature is a natural extension of the pre-existing "$member_reference" syntax which is supported in for example [LabelText] - in essence, a string parameter beginning with "$" will be considered an expression. The compiler will support a subset of C#'s expression syntax which is simple and easy to implement. This feature will have a strong synergy with the Type Designer.
Type Designer - Drag and drop, code-free editor customization
This feature will not only let you to have zero code-dependencies to Odin Inspector, but it will also enable non-programmers to fully customize the editor experience and make it even easier to add support for third-party tools. It’ll also give you a far better overview of what’s possible in Odin. For instance, if you select a float field and click “add attribute”, then the Range Attribute will be included in the dropdown list, but the TextArea attribute wont, since that doesn’t work with floats.
There’s no ETA on this feature yet, but it has a high priority for us, as we see this as the next big thing for Odin Inspector, and we expect it to be the main way customizing your editors in the future. We’ll of course make sure that you have full control over how and where the editor data is saved.
For Odin to be usable in other assets released on the Asset Store, for both for ourselves and others, there are - apart from finding a good and fair financial model - a couple of technical problems to solve. We’ll need to make a tool that can take a build of the existing version of Odin, and from it generate a redistributable build that only works for a given asset. It will also do things like rename all namespaces to your decided namespace to avoid naming conflicts with other installed Odin versions.
Odin currently has an included Scene Validator that validates the current scene, but it offers no built-in facilities for validating your project overall, or validating assets in your project. This feature is intended to expand (or replace) the existing validator to handle such cases as well.
Attributes for providing editors in the Unity Scene View
Using attributes to customize the scene view or hook into OnSceneGUI is an oft-requested feature, and one that we're looking into with great interest, as there are many extremely exciting possibilities here.