Open Brush is the community fork of Tilt Brush for VR painting

A fork that exists because the original was archived

Open Brush is described as the open source, community led evolution of Tilt Brush, forked from the Google repository.

Tilt Brush itself was a room-scale 3D painting virtual reality application from Google, originally developed by Skillman and Hackett. The project description is careful about the history, and it matters for understanding what Open Brush is. It is a free fork, the project states that a large number of changes have been made from the original repository, including Unity upgrades and feature additions to bring Open Brush up to modern XR development standards, and the notable changes are listed on the documentation site under the differences between Open Brush and Tilt Brush.

The reason the fork exists at all is in the README as a single practical sentence. The original repository is archived, so pull requests cannot be submitted there, and the invitation is to submit them here instead. That is the whole governance story. There is no committee and no transfer of ownership ceremony, just an archived upstream and a community that wanted to keep working on it.

The stated ambition is to maintain and improve upon Tilt Brush as a community-led project, free forever. The project sits under the Icosa Foundation, supports itself through Open Collective, has a Discord, and localises through Crowdin.

The audience splits into two groups. The first is an artist with a VR headset who wants to paint in 3D at room scale, and the second is a developer who wants to read, modify or extend a substantial Unity VR application that Google released under Apache-2.0 and then stopped developing.

The release cadence is notable. The three most recent versions are 2.32.35, 2.32.36 and 2.32.37, the last two published on 2026-10-10, and the last push was on 2026-10-19.

Installing means choosing a store or a build channel

The downloads section lists seven store destinations and two GitHub channels, and the difference between the store versions and the bleeding edge builds is the choice most users have to make.

The store listings are SideQuest, Meta Horizon for Quest, Steam, Oculus Rift, Viveport Desktop, Pico and itch.io. For a headset owner this is the straightforward path, since the application is a normal store app with a rating and an update channel.

The GitHub path offers formal releases and bleeding edge releases, and the rule for telling them apart is in the version number. Versions of the form vX.Y.0 are official releases, and versions that do not end in.0 are made available for testing purposes only, with no guarantees as to their quality. Those are additionally marked as pre-release on the releases page.

So a build named 2.32.0 would be a formal release, and 2.32.38 a test build. That is a convention rather than a channel, and it means the distinction is carried in the version string you are reading rather than in a separate download page.

The bleeding edge build is produced automatically by CI and is available as a ZIP for either Windows with SteamVR or Oculus Quest and Quest 2.

The third path is a build artefact. There is a Windows Monoscopic version listed as an Artifact of the GitHub Actions, and the documentation is explicit that it is intended only for developers and should not be used by general users. You find it by browsing to the commit list, clicking the green check mark under the commit title, then clicking Details and taking the artifact from the upper right corner. You then unzip it and either run the executable, which is the Desktop OpenXR/Monoscopic build, or install the APK on Android with:

adb install com.Icosa.OpenBrush-github.apk

That package name is also how you tell the sideloaded build apart from the store one, since it differs from the official package name.

Two build channels that share the same save files

The most consequential detail about the bleeding edge channel is that it is not a separate installation in the usual sense.

The documentation says these builds share a save location with the official Open Brush release, and that they can be installed alongside the formal version. On the Quest, which is a sideloaded app in the same way as any other, the build appears under Unknown Sources and has the word Github appended to its name, with a different package name as well, to differentiate it from the official release.

That combination is deliberate and it is a good design for a testing channel. A user can install a test build, try a change on the artwork they are working on, and then go back to the store version without losing anything, because the sketches are in the same place. The only thing they have to watch for is which icon they launch.

The risk the documentation flags is the brushes. The experimental builds contain experimental brushes, and sketches created using those brushes may appear differently when loaded in the official build. That is a real limitation for anyone whose work depends on a specific brush, and it is the sort of thing that would otherwise be discovered after the fact.

For the Quest build the practical workflow is to download the ZIP from the releases page, sideload the APK, and accept that the app will show up under Unknown Sources with a Github suffix. The Windows build is the equivalent ZIP, extracted and run.

Everything in this channel is opt-in. The formal releases remain the default, and the pre-release marker on the version is the flag to read before installing anything.

Building in the editor needs one pinned Unity version

The build documentation is short, and the first requirement is the one that decides whether the project will open for you at all.

The prerequisite is Unity 2022.3.34f1, given as a deep link that opens the right version through Unity Hub. Python 3 is optional and only needed if you want to run the scripts in the `Support/bin` directory, and it was tested with Python 3.8.

Running the application in the editor takes five steps. Start Unity, then use File and Open Scene and select `/Assets/Scenes/Main.unity`. Unity should prompt you to import TextMesh Pro, and you choose Import TMP Essentials, which the documentation says can also be done through the Window, TextMesh Pro, Import TMP Essential Resources menu. Then you press Play.

The detail that makes this usable without a headset is at the end. When no VR headset is detected, Open Brush can be navigated using the WASD keys or a connected gamepad. For a developer on a desktop machine, that is the difference between being able to look at the project and not. The steps were tested with Release 1.0.54.

For producing a build, the documentation says that while it is possible to build with the standard Unity build tools, the project recommends a build script to make sure the application builds with the correct settings. You run it from the Open Brush menu, Build, Do Build, or use the build window in the same menu. The documentation warns that the first build may take a while.

The repository layout supports that workflow. Alongside `Assets/`, `Packages/` and `ProjectSettings/` there is a `Support/` directory holding the scripts and per platform material, `ReferenceImages/` for the artwork the project ships, a `fastlane/` directory for the store release pipeline, a `Gemfile` and `Gemfile.lock`, a `.pylintrc` and `.flake8` for the Python tooling, and a `.pre-commit-config.yaml`. There is also an `AGENTS.md`, a `RuntimeActionBindings.json`, a `steam_controller_bindings.vdf` and a `tiltasaurus.json`.

The Windows command line route is mentioned too, using the `build` script.

The brand is separate from the code licence

The README carries a section titled Important note from the original Tilt Brush README, and it is the part to read carefully if you are thinking about the name.

The Tilt Brush trademark and logo are trademarks of Google, and they are treated separately from the copyright or patent licence grants contained in the Apache-licensed Tilt Brush repositories. Any use of the Tilt Brush trademarks other than those permitted in those guidelines must be approved in advance, and the repository contains the guidelines themselves in `TILT_BRUSH_BRAND_GUIDELINES.md`.

So there are two separate legal objects here. The code is Apache-2.0, which means anyone can use, modify and redistribute it, including commercially, under the standard conditions of keeping the copyright and licence notices. The name and logo are not, and they remain Google's.

The fork therefore carries the code licence without carrying the brand, which is why the project has its own name, its own logo credited to SiMonk0, and a link to the brand guidelines for anyone who wants to reference the original. For a fork that grew out of an archived upstream this is the correct way to handle it, and it means the downstream project is not at risk of being treated as a misuse of a mark it never owned.

The acknowledgements in the README also credit the Tilt Brush developers for the original work and for finding a way to open source the app, the SideQuest team for their support, and VR Rosie for promotional artwork, banners and videos. The `AUTHORS` file in the repository root carries the fuller list.

Where Open Brush is the wrong tool

The limitations are worth separating into the ones that are the nature of the project and the ones that are the nature of the platform.

The first is the platform. Open Brush is a VR application. It needs a headset, or at least a tracked space, and while the editor mode lets you move around with WASD, the application was designed for room-scale painting with controllers in your hands. A team that needs a lightweight 3D painting tool for a desktop, or that needs to run on a machine with no XR runtime at all, is looking at the wrong kind of project.

The second is the fork relationship. The documentation is honest that a large number of changes have been made, including Unity upgrades, and it links a page enumerating the differences from the original. The practical consequence is that a tutorial, a workflow or an asset written for Tilt Brush may not behave identically in Open Brush, and a developer working with either has to know which one they are looking at. That is the tax every long lived fork pays, and the differences page is where you pay it.

The third is the release channel risk, which is described plainly in the README rather than hidden. A build whose version does not end in .0 has no guarantees as to quality, it can contain experimental brushes, and sketches made with those brushes may render differently in the official build. That is a reasonable trade for a testing channel and an unreasonable one for artwork you care about.

The alternative approach, and the difference in approach matters, is to use a general purpose 3D application or a current commercial VR painting tool. Open Brush's advantage is that the code is open, that the roadmap is public on a GitHub project board, and that a developer can change the brush engine or the paint behaviour in a Unity codebase. The cost is that you inherit a Unity project with its own conventions, and you inherit the fork's history. For a user who wants to paint, the store version is simply easier, and for a developer who wants to build a new tool, the open code is the only reason to be here at all.

Editorial conclusion

Open Brush suits an artist or developer who wants Tilt Brush's room-scale painting model on current hardware, with an open roadmap and a community that ships releases regularly, and it suits a developer who wants to modify a VR painting application on a Unity codebase that is still being modernised. It is the wrong choice if you need a production-ready tool with a support commitment, and the wrong choice if you need the Google trademarks, which the fork does not carry. Check first the differences page in the documentation, and if you install a build that does not end in.0, remember that it is marked pre-release and that its brushes can render differently in the formal build.

Frequently asked questions

Official sources

1. icosa-foundation/open-brush on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases