// the find
bjornbytes/lovr
Lua Virtual Reality Framework
LÖVR is a C11 framework for building 3D and VR apps scripted in Lua (via LuaJIT), in the spirit of LÖVE but aimed at headsets instead of 2D games. It's for developers who want to prototype VR scenes or small 3D experiences without touching a full engine like Unity or Godot, and who are comfortable with a scripting-first, drag-a-script-onto-an-exe workflow.
It doesn't roll its own physics or audio spatialization — it wires in JoltPhysics and SteamAudio/Phonon, which are both solid, battle-tested libraries, so you're not trusting a hobby implementation for collision or HRTF audio. The rendering layer supports single-pass stereo, compute shaders, and indirect rendering, which is a real GPU API surface, not a toy wrapper. There's an actual per-module test suite under test/lovr (data, graphics, physics, thread, etc.) runnable from the built binary, which a lot of C game frameworks this size skip entirely. OpenXR as the VR backend instead of a proprietary SDK means it isn't locked to one headset vendor.
The dependency list (deps/ as git submodules: glfw, glslang, joltc, lua, luajit, luau, openxr, phonon, tracy, vulkan-headers) means a from-source build pulls in ten separate projects, and submodule drift/version mismatches are a recurring pain point for this kind of setup. It carries both LuaJIT and Luau as vendored Lua runtimes, which is an unusual amount of surface area to maintain and makes it unclear which one you're actually scripting against in edge cases. Docs live entirely on an external site (lovr.org/docs) rather than in the repo, so you can't grep the API reference alongside the source when something's undocumented or stale. The plugin ecosystem is just two entries (lovr-http, lua-enet) after years of existence, so anything beyond the built-in modules is DIY — there's no ecosystem to lean on if you need something the core doesn't ship.