Basis: an open source social VR framework you can fork and own

What Basis is: a social layer, not a game

Basis lets you set up your own social VR and networked VR games with ease, and the project describes itself as an open-source social framework for VR and desktop usage.

The distinction between a framework and a game matters for what you get. A social VR application needs a great deal that has nothing to do with the experience it is trying to deliver: a networking layer, avatar loading and rigging, voice chat, world and prop streaming, a way to spawn objects, an interface for entering a space, and a server that holds the state. None of that is the game's idea, and every project ends up writing it.

Basis is that layer, written in Unity and C#, with the game left to you.

The project is by BasisVR, the homepage is BasisVR.org, and there is a philosophy page at basisvr.org/philosophy that the README points to first. The stated licensing position is an MIT-Licensed Open-Source project with a focus on open development and full access to any optional modification desired or required, and the goal is to help equip VR creators so the growth of VR can be accelerated.

The primary language is C#, the default branch is developer, the last push was on 2026-10-19, and the recent releases use a VPM naming scheme: vpm-2026-W42.26 on 2026-10-17, vpm-2026-W41.25 on 2026-10-10 and vpm-2026-W40.24 on 2026-10-03. Those are year, week and build counters rather than semantic versions, which is the convention when a project is packaged as a Unity package rather than published to a registry with its own versioning culture.

The repository root is a good map of what the project has grown into. There is a Basis/ directory for the Unity project, a Basis Server/ directory, an AI.md, a PHILOSOPHY.md, a STYLE.md, a COMPLIANCE.md, a TRADEMARK.md, a SECURITY.md, a CONTRIBUTING.md, a CI.md, a Directory.build.props, an ExportSourceFiles.ps1 script, a .csharpierignore, an .editorconfig and a .config/ directory.

Getting it running: Unity 6, the Initialisation scene, and the command line flags

The installation path is short, and the first step is a version constraint rather than a command.

The project is currently using Unity 6, and you open the project through Unity Hub to see the version. Other Unity versions may work, but will require changes and adaptations. Currently OPENXR and SteamVR are supported, as well as OPENXR Quest.

Then there are four steps: make sure you have the correct Unity version installed, clone the repository, open the project and make sure to load the scene Initialisation, and enter play.

   git clone https://github.com/BasisVR/Basis.git

The Initialisation scene matters more than it sounds, because a social framework has a sequence of things to bring up: the transports, the local player, the avatar, the world and the UI. A scene that assumes it is the first thing to run is how the project guarantees that order rather than leaving it to whichever scene you happened to open.

There is also a set of command line arguments for Basis, and they exist because the same build has to run on a desktop without a headset, on a Quest, and on a PC, and a host sometimes needs to pin one of those.

To disable booting a VR mode:

 --disable-OpenVRLoader
 --disable-OpenXRLoader

To force a VR mode from boot:

 --force-OpenXRLoader
 --force-OpenVRLoader

The pairing is deliberate. Each loader can be disabled independently, so you can force OpenXR on a machine where OpenVR would otherwise claim the runtime, or suppress both when you want a flat desktop session. For a project whose whole point is to work on VR and desktop, that is a real requirement rather than a nicety.

The web build, and the list of what does not work in it

Basis can also be built as a Web player that runs in the browser on WebAssembly and WebGPU, and the README is unusually honest about both the requirements and the gaps.

You install Unity's Web build support module for the project's editor version, then build with Basis/Build/Web Player, or from the command line with `-buildTarget WebGL -executeMethod BasisWebBuild.BuildWeb -customBuildPath <folder>`.

The target constraints are specific. The build targets WebGPU only and 64-bit WebAssembly, up to 16 GB of memory, so players need a browser with WebGPU and WebAssembly Memory64, such as current Chrome or Edge, and Safari does not support Memory64 yet. That single fact rules out Safari, and it is the kind of constraint that a browser-target project usually discovers from user reports rather than from documentation.

Then there is the serving. You serve the output folder over HTTPS, with localhost working for testing, and serving the .unityweb files with Content-Encoding: br makes loading faster.

The networking difference is the interesting engineering point. Browsers cannot use UDP, so web builds connect over WebSocket, which is a separate package, com.basis.transport.websocket, that Basis does not include. You install it into the Unity project before building for the web, and into every server web players should join, with a pointer to the Web Clients section of Basis Server/Docker/README.md.

That arrangement is worth understanding. The transport is pluggable at the package level, so the native build uses UDP and the web build uses WebSocket, and the web transport is deliberately not vendored in because it would pull a dependency into every native project. The cost is that a web deployment has an extra step that a native one does not, and the payoff is that the framework itself does not drag a browser-only dependency into desktop builds.

The content hosting has a matching caveat. Browsers download avatars, worlds and props themselves, so the host serving them must send Access-Control-Allow-Origin headers, for example the CORS option of a CDN pull zone, and content must be built for the Web target.

And joining by link works, with `?connection=wss://example.com:4296&password=...&name=...`, where connection also accepts host:port.

Then the list of what is missing, stated as a single sentence: voice chat, VR, Steam Audio, MediaPipe tracking, lip sync, the media player, and Basis global illumination and ray traced AO are not available in the web player yet.

Forking as the contribution model, and the governance files

The contribution model in this repository is forking rather than patching, and the README makes that explicit with a six step list titled Creating a Fork.

You fork the project, optionally set up CI secrets as described in CI.md, create a feature branch with `git checkout -b feature/ACrazyNewFeature`, commit your changes with `git commit -m 'Add some ACrazyNewFeature'`, push to the branch with `git push origin feature/ACrazyNewFeature`, and open a pull request.

The examples in that list are deliberately whimsical, but the sequence is a real one, and the optional CI secrets step tells you the project expects forks to run its own pipelines rather than to rely on the upstream.

The philosophy is stated in the About section: focus on open development and full access to any optional modification desired or required, with the goal of helping equip VR creators. The repository backs that with a set of documents that are not usual in a game project. There is PHILOSOPHY.md, linked from the README as the Basis Philosophy, a STYLE.md, a COMPLIANCE.md, a TRADEMARK.md, a SECURITY.md, a CONTRIBUTING.md and an AI.md.

The AI.md is worth noting for what it signals about the project's stance on automated tooling, and the STYLE.md and COMPLIANCE.md together suggest that the project treats consistency as a contribution requirement rather than a preference. A .csharpierignore alongside an .editorconfig points at CSharpier as the formatter, and the .config/ directory is where a Unity project keeps its package and tool configuration.

The ExportSourceFiles.ps1 script is the piece that explains how a project with a .csharpierignore and a STYLE.md actually keeps its formatting honest. Exporting the source and reformatting it outside the editor is how you make a formatter that is not the editor's own the single source of truth, and for a project that expects a lot of forks with different editors, that matters.

Funding is handled through GitHub Sponsors, KoFi and Liberapay, and the README is direct about the alternative: not sure how to contribute but still wanting to help out, consider donating.

The dependency list, and what the licensing file is actually doing

The Built With section of the README is a credit list, and it doubles as a map of the technology stack.

The networking and audio pieces are the most identifiable. LiteNetLib and K4os.Compression.LZ4 cover the transport, which is the UDP layer the native build uses. For voice there is Opus and OpusSharp, with the Opus Codec listed separately under a modified BSD licence and the file named as Opus_LICENSE_PLEASE_READ.txt, which is the correct kind of warning for a codec with a history of licence conditions. RNNoise and RNNoise.Net handle noise suppression, and Steam Audio and uLipSync handle the rest of the audio and lip sync work.

The physics and utility pieces are UnityJigglePhysics, cilbox, ionic icons and the Unity third person starter assets.

The Third-Party Code and Trademarks section then goes through the licensing in detail, and this is the section that matters for a project whose stated value is that you can fork it. Under Apache License 2.0 there is Steam Audio, OpenLipSync with the ONNX Runtime, and SQLitePCLRaw, which is noted as a NuGet dependency of the standalone server's sqlite player storage. Under BSD-3-Clause there is OpenVR and the SteamVR Unity plugin, both attributed to Valve Corporation. The Opus codec is under BSD, modified or clear, and uLipSync is under MIT.

The pattern is that each third-party component is listed with its licence and, in several cases, with a pointer to the licence file inside the package directory, such as Basis/Packages/com.steam.steamaudio/LICENSE.md and Basis/Packages/com.basisvr.openlipsync/THIRD_PARTY_NOTICES.md.

Putting the notices inside the package folders rather than only in a root document is the right call for a project meant to be forked, because a fork that ships a single package will carry that package's notices with it. The root THIRD_PARTY_NOTICES style file is where the standalone server's own dependencies get recorded, and the TRADEMARK.md at the root is the file that separates the licence of the code from the rights in the name and logos, which is the distinction that a project inviting forks of its community needs to state clearly.

Note that GitHub classifies the repository licence as a custom licence it cannot classify, so check the LICENSE file for the details.

Editorial conclusion

Adopt Basis if you want to build a social VR or networked VR application and would rather start from an existing social layer than write networking, avatars, voice and world loading yourself. Do not adopt it expecting the web build to be equivalent to the native one, because voice chat, VR, Steam Audio, MediaPipe tracking, lip sync, the media player and the global illumination features are all listed as unavailable in the web player. Before you start, install the WebSocket transport package if you intend to build for the browser, since Basis does not include it, and check the Unity version, because the project targets Unity 6 and other versions need changes and adaptations.

Frequently asked questions

Official sources

1. BasisVR/Basis on GitHub
2. Issues
3. Project website
4. README
5. Releases