> 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/readme.md). # Welcome Data connections, made simple.

Binding System 3 is a Unity editor tool that connects one value in your project to another. You pick the two ends in the Inspector, and the package keeps them in sync while the game runs. You do not write the code in between, and you do not recompile to change a connection. Almost anything can be one end of a connection: a field, a property or a method on any component, asset, material or UI Toolkit element. That includes Unity's own components and packages whose source code you do not have. ## The problem it solves A health value lives on one component. A fill bar lives on another. To join them you write a third script, and its whole job is this one line: ```csharp _bar.fillAmount = _health.Current / _health.Max; ``` Around that line you also need two serialized references that can be null, an `Update` that runs even when nothing changed, and a class name you had to invent. It works, but it never stays at one. The next connection needs another script, and a finished project has dozens of them in the same folder. Each one is simple, and each one is a real file somebody has to maintain. Binding System replaces that file with a row in the Inspector. {% tabs %} {% tab title="Without" %} ```csharp public class HealthBarDriver : MonoBehaviour { [SerializeField] private Health _health; [SerializeField] private Image _bar; [SerializeField] private float _max = 100f; private void Update() { if (_health == null || _bar == null) return; _bar.fillAmount = Mathf.Clamp01(_health.Current / _max); } } ``` One more class in the project, one more component in the scene, and one more file to update when either side changes. {% endtab %} {% tab title="With" %} Nothing. No file, no class, no component. Right click **Fill Amount** on the `Image`, choose **Enable Binding**, click the hexagon toggle next to the label, point it at `Health.Current` and add a **Normalize Value** modifier. **UPDATE** is already the update point. ``` Health.Current → Normalize Value [0 .. Health.max] → Image.fillAmount ``` `Image` is Unity's own component. You could not have added that line inside it even if you wanted to, and you did not need to: the binding is stored next to the object. {% endtab %} {% endtabs %}

Step 1: you write the component. Step 2: Binding System connects it.

## Pure components A component is **pure** when it does not reference any other component or object. It declares the values it needs and the values it produces, and nothing else. It does not know where its values come from, and it does not know where they go. Here is a door that is not pure. Most doors are not. ```csharp public class Door : MonoBehaviour { [SerializeField] private Lever _lever; [SerializeField] private PowerGrid _grid; [SerializeField] private float _openSpeed = 1f; private void Update() { if (_lever == null || _grid == null) return; if (_lever.Pulled && _grid.HasPower) Open(_openSpeed); } } ``` This `Door` depends on `Lever` and on `PowerGrid`. You cannot use it in a scene that has no lever, and you cannot test it until you build one. If somebody renames `Pulled`, this file stops compiling, together with every other component that also uses a lever. The same door, written as a pure component: ```csharp public class Door : MonoBehaviour { public Bind ShouldOpen; public Bind OpenSpeed; private void Update() { if (ShouldOpen) Open(OpenSpeed); } } ``` Nothing inside it mentions a lever, a power grid, or anything else in your game. In the Inspector you connect `ShouldOpen` to `Lever.Pulled`. You can also connect it to a checkbox that you tick by hand while you tune the animation, then point it at the real lever when you are done. The door itself does not change.

The same six components, with references between them and connected from outside

### Benefits of this approach

Benefit	What it means
You can test it alone	Put it in an empty scene, type a value into the field, and watch what it does. You do not need mocks, or a stand-in for the other component, or a whole scene.
You can reuse it anywhere	The file does not know which game it belongs to. Copy it into another project and it still compiles.
Fewer merge conflicts	The person building the door and the person deciding when doors open no longer edit the same `.cs` file.
Connecting is not programming	To change what opens the door you pick a different source in the Inspector. No ticket, no branch, no build.
Deleting is safe	Remove the lever and nothing else stops compiling. The binding turns red and shows you where it used to point.

You do not have to do this everywhere. You can make one field bindable today and leave the fields next to it exactly as they are. ## Where and when Binding System is useful These are the situations where it saves the most work. ### Copying a value between two components A physics door has a dozen parameters you want to tune. To drive it you add a `DoorController`, give it a reference to the door, and from then on two files change whenever the door does. Make the door's parameters bindable and the controller has nothing left to do. The lever, the slider and the UI button that used to feed it can each stand alone in the same way, and none of them knows the others exist.

The usual way needs a third script. With Binding System the lever and the door connect directly.

### One value used in many places Component A produces a number and component B needs it. Later C and D need it too, then the HUD, then the save system. Normally each new reader means editing A to push the value, editing the reader to pull it, or writing a bridge between them. With bindings, A does not change at all: every reader points at `A.Value` and receives every update. Adding the sixth reader is one row in the Inspector, and nothing recompiles.

One value feeding five readers, each through its own binding

### One value set from several controls Max speed can be set from a UI slider, from an input field and from a joystick, and the one that moved last should win. Normally this is a small arbitration system that you write once and debug forever. Here it is a [modifier](/binding-system-3/pipeline/modifiers.md#multi-controlled-values): bind all three into the same field and the pipeline handles it.

### A list of values from different sources ```csharp public List> inputs; ``` The first element is a constant, the second follows a slider, and the third reads the velocity of a rigidbody. One type, one list, three different sources. The code that uses the list reads `inputs[i]` and notices nothing.

A list whose elements come from three different sources

### Shared data, without a singleton Normally every component that shows a colour holds a reference to the `Palette` asset, or reads it from a global instance. With bindings the component simply has a `Color` field, and something outside it decides that this colour comes from the palette. Change the palette while the editor is open and the scene updates as you watch, because a binding can also run at [edit time](/binding-system-3/overview/modes-and-updates.md).

Three components reading one palette, none of them naming it

### A field you cannot edit `Rigidbody.mass`. `Light.intensity`. A property on a plugin whose source you do not have. A shader property on a material. This is the case that is hardest to solve in any other way: right click the field, enable the binding, and it is stored next to the object instead of inside it. Nothing is recompiled and nothing is subclassed. See [Proxy Bindings](/binding-system-3/overview/proxy-bindings.md).

A binding on a field of a component you cannot edit

### A source that does not exist yet A prefab has to bind to whichever player is in the scene it is dropped into. A direct reference cannot do that, so most tools leave the problem to you. Here the source can be found by tag, by hierarchy path, by name pattern, by a scene search, or by a [named variable](/binding-system-3/overview/bind-variables.md) that each scene fills in for itself. There are eight ways in total, and the rest of the binding is the same in all of them. See [Sources](/binding-system-3/overview/sources.md).

A prefab that finds its source by tag when the scene loads

## How it differs from other approaches Most tools of this kind ask for something before they give you anything: a view model, a context class, a wrapper type around every value you want to move, or one asset per value to name and store. None of that is unreasonable, and on a new project it is often the right choice. It fits badly on a project that already exists, where the values you want to connect are already declared, already serialized and already working.

Common requirement	In Binding System 3
Write the source first: a view model, a context, or a wrapper type for each value	Point at the field that is already there.
One asset per connected value, to name, organise and keep	None. Named values exist if you want them, and are never required.
Both ends must be code you own	Either end can be a Unity component, a package you cannot recompile, a material, a shader property or a UXML element.
A programmer and a recompile to change a connection	One row in the Inspector, changed by whoever is using the editor.
Adopt the architecture across the whole project, or not at all	One field at a time, and reversible with one click. The field next to it can stay as it is.
Works on user interfaces only	Works on anything with a value. Most tools in this category are UI tools that also bind.

The second row from the bottom is the important one. Every other approach is a decision about the whole project, taken once and early. This one is taken per field, and any field can be changed back with one click. Once a project has a few hundred bindings, the question stops being *can I connect these two things* and becomes *what is connected to what*. That is what the [diagnostics](/binding-system-3/project-tools/diagnostics.md) are for, and almost nothing else in this category has them. For the full comparison, with names, prices and the cases where another tool is the better choice, see [How It Compares](/binding-system-3/getting-started/comparison.md). ## Two ways to bind The first way needs no code. Every serialized field of every component and asset in your project can be bound directly from the Inspector: right click, **Enable Binding**, click the hexagon, and connect it. One more click on the same hexagon turns it off again without losing the setup. Nothing is written to disk and nothing is recompiled, so people who never open a source file can build and change all of the connections.

The second way is for components you wrote yourself, when you want to control exactly when the value is read: ```csharp public class HealthBar : MonoBehaviour { public Bind fill; // resolves the instant your code reads it } ``` A `Bind` field updates only when it is read, which makes it both cheaper and more precise. It does need the field to be yours, and one line of code to declare it, so the Inspector route is the one to learn first. Both ways share the same source modes, paths, converters, modifiers and diagnostics, and they can be used side by side on the same GameObject. See [Two Ways to Bind](/binding-system-3/overview/two-ways-to-bind.md). {% hint style="success" %} The quickest way to start: [Your First Binding](/binding-system-3/getting-started/first-binding.md) takes about a minute and needs no code. {% endhint %} ## Built for big projects Bindings are quick to make, so a real project ends up with thousands of them. Binding System 3 is built for that from the start.

Tool	What it answers
Live Debug	What value is at every stage of this binding, right now?
Bindings Monitor	Which bindings are active, how often do they run, and what do they cost?
Bindings Dependencies	Where in the project is this member bound, and by what?
Dependency Graph	What is connected to what, as a graph I can walk?
Refactoring	I renamed a field. What broke, and can it be repaired?
Optimized Accessors	Which bindings can the build replace with direct code?

## Get started


Your First Binding	One field, one minute, no code.	Your First Binding	bs3-tile.png
Core Concepts	Source, path, pipeline.	Core Concepts	bind-pipeline.png
The Bind Field	Everything the Inspector row does.	The Bind Field	source-modes.png
Two Ways to Bind	With code, or without it.	Two Ways to Bind	two-ways-to-bind.png
Modifiers	Shape the value on the way.	Modifiers	modifier-interfaces.png
Diagnostics	Find and fix, at project scale.	Diagnostics	diagnostics.png

## What is new in 3 If you are coming from Binding System 2, this is what the new version adds.

Change	What it means
Bindings for UI Toolkit	Bind the properties, inline styles and USS classes of UXML elements, straight from UI Builder. The binding is stored on the scene or in the asset.
Method binding	A path can call a method or an indexer, not only read a field or a property. Every argument can itself be a binding.
Source modes	A source can be named by variable, name or path, tag, pattern, context, scene search or static type, instead of only by direct reference.
Bind variables	Named values in a scene component or a project asset, usable as the source of any binding.
Better project-wide diagnostics	Every serialized binding in the project, as a list, as a graph and as a validation pass, alongside the Bindings Monitor.
Generated accessors	At build time, the paths your project binds are turned into generated direct-access code.
Micro UI	A bound field can keep its own control, showing the value the binding produces, with only the hexagon beside it. Its centre lights green or red for the value shown, and the whole binding opens in a popup.
Bulk editing of binding lists	Edit one binding in a list, or on one of several selected objects, and have the change repeated on the others that match.
Async search and member loading	The bind path menu fills its groups and runs its search in the background, so it opens immediately even on types with very large member trees.

The full list is in the [Change Log](/binding-system-3/help/change-log.md). Coming from 2.x, read [Upgrading from Binding System 2](/binding-system-3/getting-started/upgrading.md) first. {% hint style="info" %} **Requires Unity 6000.0 or newer.** Projects on an older editor should stay on the 2.x line. {% endhint %} ## Explore the documentation Choose a chapter to find its guides and reference pages.


Getting Started	Install, make your first binding, and learn the core ideas.	Getting Started	cover-getting-started.svg
Tutorials and Demo Scenes	Build a working example or explore a finished sample.	Tutorials and Demo Scenes	cover-tutorials.svg
Binding	Choose sources, connect fields, and control updates.	Binding	cover-binding.svg
The Pipeline	Convert types, transform values, and smooth motion.	The Pipeline	cover-pipeline.svg
Debug and Optimize	Inspect connections, audit the project, and measure cost.	Debug and Optimize	cover-diagnostics.svg
Developer Reference	Look up APIs and settings, and extend or integrate the tool.	Developer Reference	cover-reference.svg
Help and Releases	Find answers, troubleshoot, and check what changed.	Help and Releases	cover-help.svg