This introductory section is essentially Odin 101; it will get you started with Odin, and tell you everything you need to know to become a proficient user. It will in general skip over the deeper technical details, and instead aims to give you an overview over Odin's out-of-the-box capabilities and how to use them.
Power-users aiming to extend Odin, or those who simply wish to understand Odin's underlying systems more thoroughly, are advised to read this introductory section, and then proceed to the in-depth technical sections Drawers in Depth and Serialization in Depth.
And of course, if you're in need of knowledge about a more specific class or method in Odin, you can always look it up in the documentation.
For now, Odin is installed using Unity's standard .unitypackage format. Installation is very straightforward; simply unpack the entire package into your project, then wait for the editor to load all of the assemblies - Odin will then be installed. After this, you may take the Sirenix folder which contains Odin and its assemblies, and place it anywhere you please in your project; Odin will automatically detect where it is placed in the project. By default, it will be placed in the Plugins folder.
Do note that it is extremely inadvisable to change the internal structure of the Sirenix folder itself or renaming the folder in any way; this will in rare cases cause Odin to be unable to find its location in the project, and result in assets being generated in unwanted locations.
Odin is perfectly compatible with common source control systems. However, there are a few files which Odin continuosly regenerates, and while it causes no harm to include these in your source control, it is best to ignore them and leave them as local files only, since they will be changing constantly. The files in question are located in the Sirenix/Assemblies/Editor folder, and are called GeneratedOdinEditors.dll and GeneratedOdinEditors.mdb. You should also ignore the associated .meta files, if you are working in a project with those enabled.
Odin's custom serialization is supported on all platforms but Windows Store and lets you use dictionaries, interfaces and more in the inspector. However, not all projects are in need of this, and for IL2CPP builds, including the serialization assemblies can increase your build size, since the serialization assemblies will not have code stripping performed on them. Odin is built in a modular fashion, and it is possible to completely remove Odin's serialization system from all of your builds, if you are using Odin in its compiled .dll form and not as source files.
To remove the serialization system, you must delete the following files and folders from Odin:
Once you have done this, Odin's serialization system will no longer be included when you build a player.
Note that the serialization system will still be present in the editor, and you will be able to use it in the editor. However, if you reference it anywhere in build code, you will get compiler errors once you attempt to build a player, and you will have to remove those references before you are able to build a player.
Also note that this will not cause Odin to work on the Windows Store platform - that platforms remains unsupported by Odin. This may change in the future, but as of now, Odin does not support Windows Store at all, with or without serialization.
Odin supports being used as source, instead of as assemblies, from version 5.3.7 of Unity and up (with assemblies, Odin supports 5.3.0 and up).
If you wish to use the source in your project, first install Odin regularly.
After you have done this, delete the Sirenix/Assemblies folder, and unzip the source file. Apart from the source itself, you will find an unzipped folder called MoveFilesToRoot. Take the contents of that folder (csc.rsp, gmcs.rsp and smcs.rsp), and move them to the root asset folder of your project. These files contain compilation settings for allowing Odin to be compiled, as Odin uses unsafe code to speed up its binary serialization. If you already have some or all of these files in your project, you will have to merge them, or otherwise change your own files to enable unsafe compilation in your project.
After you have done this, and Unity has recompiled, you may get some messages about config asset m_Script guids being corrected. This is fine - Odin is ensuring that your old configuration assets are still usable. If you instead get warning messages about being unable to load configs, and m_Script guids being corrupt, see the above note about retaining your Odin configuration for how to resolve this issue.
After this, you may move the source wherever you wish, so long as it is still in a subfolder of Sirenix. As with assemblies, you may still place the Sirenix folder wherever you wish in your project, though it is advisable to keep it as a subfolder of Plugins, to cut down your compilation time when working on game code. (See Unity Special Folder Names.)
Once you've installed Odin, the main difference you'll notice is that your inspector will look a little nicer. Lists and arrays in particular will have undergone quite an upgrade; list elements are now draggable, long lists have paging, and so on. You now have a right-click context menu for every property in the inspector, that provides contextual actions for that property, such as copying and pasting, resetting changed prefab values to their original, and so on.
Odin offers you many options to configure where it applies. In its default configuration, Odin applies itself to all types that do not already have a custom editor defined, but you can adjust this in the advanced preferences for Odin, under Window -> Odin Preferences -> Inspector -> Editor Types.
Once a component is being drawn by Odin, it integrates seamlessly into your pre-existing Unity workflow. There's no boilerplate code, and no complicated setup - it all just works out of the box. You still create your fields, decorate them with attributes, and edit them in the inspector.
However, with Odin, you now have a vast array of choices to configure how your inspector looks and acts, with dozens of built-in attributes and great ease of extendability. Furthermore, if you inherit from one of our specially serialized classes, such as SerializedMonoBehaviour, you can use fields of any type; those not serialized by Unity will be serialized by Odin instead.