# VRC Light Volumes: baking voxel light into Unity and VRChat worlds

> VRC Light Volumes is a free Unity package that bakes lighting into voxels and analytic point, spot and area lights so a VRChat world can have many light sources without the usual realtime cost. The price is a build step and a dependency on your lightmapper and shaders.

**REDSIM/VRCLightVolumes** — Optimized voxel-based and analytic lighting solution for Unity and VRChat

- Repository: https://github.com/REDSIM/VRCLightVolumes
- Stars: 656 · Forks: 59
- Language: C#
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/redsim-vrclightvolumes

## Light volumes bake lighting into a voxel grid the shader can read

VRC Light Volumes is an optimized voxel-based and analytic lighting solution for Unity and VRChat, and the word optimized is doing specific work in that sentence. The lighting is not computed live in the frame loop. It is baked, and the bake produces data that the shaders sample per pixel. The feature list is explicit about the granularity: baked voxel based lighting with adjustable voxel density and smooth blending between volumes, and per-pixel lighting rather than per-vertex approximation. Regular and Additive light volumes are combined, with a cap of 32 active volumes of both kinds. Additive volumes exist for separately baked lights that can move, or turn on and off, together. The other half of the solution is analytic lights. Up to 128 active point, spot or area lights are supported, each with runtime control of position, colour and intensity, and each with its own specular highlight that responds to the light's size. Shadows for those realtime lights are baked in the Editor, captured at startup, or updated in game. The design intent is that a world looks like it has many dynamic lights while the runtime cost stays in the range a headset can carry.

## Installing through VCC means adding a VPM repository URL

The recommended installation path goes through the VRChat Creator Companion, and it is a URL paste rather than a download. In VCC you open Settings > Packages, click Add Repository, paste the listing URL into the repository field, click Add, and confirm with I Understand, Add Repository. The URL is:

```bash
   https://redsim.github.io/vpmlisting/index.json
```

Once the repository is registered, you go to Projects, click Manage Project for your world, and click the [+] next to VRC Light Volumes. The README also points to the RED_SIM VPM Listing page as an alternative route, where an Add to VCC button does the same registration. The reason this works for VRChat users is that the package is distributed as a VPM package, the same package format the platform itself uses for avatar and world packages, so the dependency resolves the same way your own world packages do. There is no manual import step and no version juggling in the common case.

## The Unity Package Manager route is a git URL with a path suffix

If you are not using VCC, the package installs through the Unity Package Manager. You open Window > Package Manager, press the [+] button, choose Add package from git URL, and enter:

```bash
   https://github.com/REDSIM/VRCLightVolumes.git?path=/Packages/red.sim.lightvolumes
```

The path suffix is what makes this work, because the repository root is a full Unity project rather than a package folder, and the path parameter points the package manager at the package inside it. The README notes that the Git URL follows the main branch, and that when testing a prerelease you should install the matching release or branch so that the package and the documentation describe the same version. That warning is easy to skip and annoying to debug later, since a moving branch and a versioned documentation folder can disagree. For existing 2.x projects, the README routes you to a migration section in the best practices document, which matters because the 3.x line is a change of major version and the feature list and installation flow both differ from what an older project would have been configured for.

## Baking needs a lightmapper, and only certain ones are supported

This is the dependency that decides whether the project works for you at all. Baking with Unity Progressive, Bakery, Hikari and Glim are listed as supported, and there is a custom lightmapper API documented separately for integrations beyond those. The README also says it works with Bakery, the Unity Progressive lightmapper and other lightmappers, so the framing is that the common cases are covered and the escape hatch exists for the rest. Two consequences follow. First, there is a build step in your workflow that did not exist before, and the bake has to be redone whenever lighting changes. Second, the second half of the feature list describes the editing experience that makes that tolerable. Colour and brightness adjustments are possible without rebaking, and Additive volumes let a separately baked light be moved or switched on and off together, so not every tweak means a full rebake. Shadows for the realtime lights are baked in the Editor, captured at startup, or updated in game, which gives you a way to move them at runtime without losing them entirely.

## Froxel clustering and shader stripping are where the performance comes from

Two mechanisms carry the performance story, and both are opt-in or shader-level work rather than defaults. Froxel Clustering skips lights that cannot reach a surface, and it comes with optional Shadow Culling on top. The idea is straightforward: instead of every light being evaluated for every fragment, the light's influence is bounded to the region it can actually affect. The second mechanism is Shader Stripping, documented for developers, which removes unused lighting features from world builds. That means the shaders in your project have to opt into the lighting features they use, and the ones they do not use are compiled out. Shader integration is described as working through shader code or through Amplify Shader Editor, and there is a CompatibleShaders document for the list of shaders that already work. The README also notes that lots of shaders already support VRC Light Volumes, which is a fair statement of the ecosystem but not a promise about your particular world. Support covers PC and Quest and Android, with world shaders that support VRC Light Volumes.

## Integrations with AudioLink and LTCGI extend the light volumes

The package does not stop at lighting geometry. AudioLink is listed in the main features, and the documentation has a dedicated AudioLink integration page, alongside a TV screen integration page. AudioLink is the mechanism VRChat worlds use to drive effects from audio, so an AudioLink integration means the baked volumes and realtime lights can react to music in the world rather than sitting static. LTCGI is named in the main feature list as something the package works with, which covers the screen-space lighting technique used by many avatars and world surfaces. The use case list explains why: lamps, flashlights, stage lights and glowing panels, image and cubemap projectors, and screen lighting and music-reactive effects. Analytic point, spot and area lights with runtime control of position, colour and intensity are what make flashlights and stage lights practical here, because they are not frozen into the bake. The scripting API covers runtime light control, Editor tools, atlas processing and custom lightmappers, so a world that needs to drive a light from game logic has an interface for it.

## Attribution is optional and the world can credit the shader authors

The README explains an attribution mechanism that is worth understanding because it reveals how the project expects to be used. An optional attribution prefab tells visitors about avatar shaders that support VRC Light Volumes, and it lives at:

```text
Packages/red.sim.lightvolumes/Attribution/
```

The prefab itself ships two logo variants, one for dark mode and one for light mode, so the credit does not look broken in either interface setting. If a world would rather use plain text, the README supplies a message to use instead:

```bash
This world supports VRC Light Volumes. Use avatar shaders with VRC Light Volumes support for an enhanced visual experience.
```

Attribution is described as optional but appreciated. What makes the request reasonable is the direction of the benefit. The world builder gets the lighting solution, but the shader authors are the ones who did the work to make their shaders sample the volumes, so the attribution names them. The world also has a debugging story for the people who use it, with scene view modes, voxel previews, live Inspector data and an optional PC avatar debugger. The package is a free and open-source asset under the MIT licence, and the README notes the author also accepts support through Patreon.

## Conclusion

VRC Light Volumes suits VRChat world builders and Unity artists who need more than the platform's realtime light budget, who already have a working lightmapper pipeline, and who can afford the bake step and the shader work that shader integration implies. It is the wrong tool for a realtime game where lights change every frame, for a project that cannot run an offline bake, and for a world whose shaders were never written to sample the light volumes. Verify first that your lightmapper is one of the supported ones or that you can use the custom lightmapper API, that the shaders in your scene support VRC Light Volumes, and that you read the migration notes before moving a 2.x project to 3.x.

## FAQ

### How do I install VRC Light Volumes in a VRChat world?

The recommended route is through the VRChat Creator Companion: open Settings > Packages, click Add Repository, paste https://redsim.github.io/vpmlisting/index.json into the field, confirm with I Understand, Add Repository, then under Projects click Manage Project and the [+] next to VRC Light Volumes.

### Can I install VRC Light Volumes with the Unity Package Manager?

Yes. Open Window > Package Manager, press the [+] button, select Add package from git URL, and enter https://github.com/REDSIM/VRCLightVolumes.git?path=/Packages/red.sim.lightvolumes. The README notes the Git URL follows the main branch.

### Which lightmappers does VRC Light Volumes support?

The README lists Unity Progressive, Bakery, Hikari and Glim, and there is a custom lightmapper API for other integrations. Baking is required, so a supported lightmapper or that API is a prerequisite.

### How many lights can a VRC Light Volumes world have?

Up to 32 active Regular and Additive light volumes combined, and up to 128 active point, spot or area light sources visible at the same time. Froxel clustering is used to skip lights that cannot reach a surface.

## Sources

- [Issues](https://github.com/REDSIM/VRCLightVolumes/issues)
- [License: MIT](https://github.com/REDSIM/VRCLightVolumes/blob/main/LICENSE)
- [README](https://github.com/REDSIM/VRCLightVolumes/blob/main/README.md)
- [REDSIM/VRCLightVolumes on GitHub](https://github.com/REDSIM/VRCLightVolumes)
- [Releases](https://github.com/REDSIM/VRCLightVolumes/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/redsim-vrclightvolumes
