> For the complete documentation index, see [llms.txt](https://postica.gitbook.io/binding-system-3/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://postica.gitbook.io/binding-system-3/reference/integrations/odin-inspector.md).

# Odin Inspector

Bind fields under Odin's drawing system.

Binding System integrates with [Odin Inspector](https://odininspector.com/). The integration is a separate assembly compiled only when `ODIN_INSPECTOR` is defined, so it costs nothing when Odin is not in the project and needs no setup when it is.

## What works

Nearly everything. Bind fields draw normally under Odin's drawing system, with the same row, the same menus and the same diagnostics.

Odin attributes that constrain an object field are respected on the source:

<table><thead><tr><th width="290">Attribute</th><th>What it does</th></tr></thead><tbody><tr><td><code>[AssetsOnly]</code></td><td>The source field refuses scene objects, and says <em>Scene Objects NOT Allowed</em>.</td></tr><tr><td><code>[SceneObjectsOnly]</code></td><td>The source field refuses assets, and says <em>Assets NOT Allowed</em>.</td></tr></tbody></table>

## Attributes on the inner value

A `Bind<float>` is not a `float`, so `[Range(0, 1)]` on it has nothing to work with. The `[Bind]` attribute is the switch that says where the attributes below it should land.

**Attributes below `[Bind]` are transferred to the inner value. Attributes above it stay on the bind field.**

{% tabs %}
{% tab title="Correct" %}

```csharp
[Bind]
[Range(0f, 1f)]
[MinValue(0f)]
public Bind<float> intensity;
```

Both `[Range]` and `[MinValue]` target the inner `float`, so the unbound field draws as a slider from 0 to 1.
{% endtab %}

{% tab title="Wrong" %}

```csharp
[Range(0f, 1f)]
[Bind]
public Bind<float> intensity;
```

`[Range]` stays on the `Bind<float>` field, and Odin correctly reports that it cannot process the type.
{% endtab %}
{% endtabs %}

## What is not supported

Features that rely on **Odin serialized properties** rather than Unity serialization. A bind field needs Unity serialization to store its bind data, so a property that only Odin serializes cannot carry one.

Odin serialized properties are still perfectly usable as **sources**, which is the more common need.

## Troubleshooting

{% hint style="warning" %}
If bind fields draw without their bind row after installing Odin, the extension assembly did not pick up the define. Restart Unity. This happens most often when Odin is added *after* Binding System.
{% endhint %}

<table><thead><tr><th width="330">Symptom</th><th>What to do</th></tr></thead><tbody><tr><td>Bind fields draw as raw serialized data</td><td>The Odin extension is not compiled. Check that <code>ODIN_INSPECTOR</code> is defined, then restart Unity.</td></tr><tr><td>An attribute has no effect</td><td>Check whether it sits above or below <code>[Bind]</code>.</td></tr><tr><td>A property does not appear in the bind path menu</td><td>It may be Odin-serialized only. Bind to the backing field, or expose a Unity-serialized member.</td></tr></tbody></table>

## Under the hood

The integration hooks the static delegates the bind drawer exposes (`OnInitialized`, `OnFocused`, `ShouldIndentFoldouts`, `UpdatePositionRect`, `OnDrawObjectField`, `OnTryPrepareDataPreview`) rather than replacing the drawer. That is why the two systems compose instead of competing, and why the same hooks are available if you need to integrate another inspector framework.