LTCGI: area lights that work in VRChat without baking

What the algorithm actually buys you

LTCGI is described as an optimized plug-and-play realtime area light solution using the linearly transformed cosine algorithm for standalone Unity and VRChat, and it is free to use with attribution. The underlying idea is a shading technique, not a light type. In a normal realtime renderer, a light source is treated as a point or a directional vector, so a large rectangular panel light produces a hard edge and an implausible falloff across it. The linearly transformed cosine algorithm, from the paper Real-Time Polygonal-Light Shading with Linearly Transformed Cosines by Eric Heitz, Jonathan Dupuy, Stephen Hill and David Neubelt, published in ACM Transactions on Graphics in 2016, computes the correct result for a polygonal area light in real time, which means a wall-mounted panel or a ceiling strip looks like the shape it actually is. The practical effect for a VRChat creator is that you can place a light that matches the geometry of a window or a neon sign and have it read correctly to a viewer, without a lightmap bake, and the README notes it can use the built-in Unity lightmapper or Bakery for realistic shadows on static objects. So the package is not a replacement for baking, it is a way to get credible area lighting in the parts of a scene that are dynamic.

Installation is a package manager, and the VPM route is the easy one

There are two install routes, and which one you use depends on whether you are building a VRChat world or a standalone Unity project. For VRChat you install LTCGI via the Creator Companion from a VPM repository, and the README links a Creator Companion and VPM install page on the project domain. For standalone Unity you import LTCGI as a git package using the repository URL, which the README gives explicitly as the URL for the git package import.

One wrinkle is that the adapters for various VRChat video players are still distributed as unitypackages from the Releases tab rather than through the VPM flow, which is a leftover from how those packages are consumed. The repository has a set of top level directories and assets that make the structure clear, with an Editor folder for editor-side code, a Runtime folder for the runtime components, Shaders for the shader side, Lookup Tables holding the precomputed matrices the algorithm needs, Prefilter Blur for the filtering step, LightVolumes for the integration with VRC Light Volumes, Adapters for the video player adapters, and an Adapter Support folder, plus the prefabs for the controller, the attribution prefab, a global toggle example and a screen gizmo image. The Unity package metadata is minimal, with the package name at.pimaker.ltcgi, the display name LTCGI, a version matching the release, and a unity field of 2022.3.

Every lit surface has to opt in, which is the main constraint

The supported shaders section states the requirement plainly: to use LTCGI, all objects that should receive lighting must use a compatible shader, and if you implement LTCGI into your own shader the project asks you to send a pull request so it can be included. The compatible list is a mix of well known community shader packs and a few included ones, with the ORL Shader Family, Silent's Filamented, Mochie's Unity Shaders, Hekky Shaders, z3y's Shaders, Poiyomi Shaders and VixForge Toon, plus a basic unlit test shader and a surface shader that ship with the package. The URP entry is the most detailed and the most interesting, with two shaders for URP 17.7 or newer on Unity 6000.7, including single-pass instanced VR. One of them, LTCGI/Lit URP, is URP's Lit shader with LTCGI added, and it has the same properties and inspector as the original Universal Render Pipeline/Lit, so an existing Lit surface can switch to it and keep its settings. That property is what makes the integration practical, because it means the cost of adopting LTCGI in an existing scene is changing which shader a surface points at rather than re-authoring every one. The second, LTCGI/Simple URP, is the unlit test shader for URP. The package also supports VRC Light Volumes by RED_SIM.

The attribution requirement is a licence obligation, not a courtesy

The attribution section is the part of this project that needs reading before you ship a world with it in. According to the licence you are free to use it in your world, but you need to give credit, and you are free to do so in whichever way, but you must provide a link to the GitHub repository, which the README explains is to fulfil the imported licence of the LTC example code used as a base for the project. For convenience, a prefab called LTCGI Attribution is provided in the package, so the requirement is satisfiable by dropping a prefab into the scene rather than by editing text. If you would rather not use the prefab, the README says to display text similar to the following.

This project/world uses LTCGI by _pi_, see 'github.com/pimaker/ltcgi'.

The licensing section then separates three things that are easy to conflate. The LTC algorithm itself is covered by the paper cited above, and the LTCGI project is made available under the terms of the MIT license unless explicitly marked otherwise in the source files. But a small set of files is licensed explicitly and may not be modified or used in commercial projects, though it can be redistributed and displayed otherwise provided the licence is kept, and the two files listed are the two graffiti images in the Propaganda folder. That carve-out is narrow, and it matters only if you were planning to put the package's own artwork into something you sell.

The version history is a compatibility ledger

The release titles tell you that this package tracks the platforms it runs on rather than adding features. The most recent is v1.7.4 from 2026-10-17, with the title Minor VRCLV compat fix and URP example shaders, before it v1.7.3 from 2026-08-02 titled Fix compilation with VRCLV 3.0-dev14+ and v1.7.2 from 2026-07-18 titled Fix compilation with VRCLV 2.x. Three consecutive releases, all of them about making the package compile against a particular VRChat SDK version, and that is the whole maintenance story of a project whose code runs inside someone else's engine. It also tells you what to check before you upgrade. If you are on an older VRCLV, the release you want is the one that fixed compilation for your SDK rather than the newest, and the Releases tab is where you find it. The last push to the repository was on 2026-10-17, the same day as the newest tag, and the repository is not archived. The project page carries a Getting Started guide and a FAQ, and the README asks you to read the FAQ before asking for help anywhere, and to join a Discord afterwards, which is a reasonable way to handle support for a package that people install into their own projects.

Where LTCGI is the wrong choice

The first limit is the shader requirement, and it is structural rather than a matter of configuration. Every object that should receive the light has to use a compatible shader, so a scene built on a shader family that is not on the list, or on a custom pipeline, gets no LTCGI lighting at all, and the failure is silent because the light still works, it just looks like a point light. The second is the platform dependence on VRChat, where the package's own release history is a sequence of compilation fixes, so you are choosing a version that matches your SDK rather than a version that is best. The third is that it does not replace baked lighting. The README is clear that it can use the built-in lightmapper or Bakery for realistic shadows on static objects, which means a well lit scene is still a bake, and LTCGI is the layer that handles the parts that move or the areas a bake would not cover. The fourth is the attribution obligation, which is easy to satisfy and easy to forget, and a world shipped to the hub without it is a licence problem for the author. And the fifth is the preview workflow, since the standalone demo app and the demo world in VRChat are the only ways to see the effect before you wire it into a scene, so evaluating it costs more than reading the documentation.

Editorial conclusion

Adopt LTCGI if you light VRChat worlds or standalone Unity scenes where baked lighting is impractical and you want area lights to read correctly in realtime. Skip it if you are on a render pipeline or shader the package does not support, since objects that do not use a compatible shader will not receive the light at all. Verify first that the version you take fixes compilation against your SDK, that every lit surface in the scene uses a supported shader, and that your world includes the attribution prefab or the equivalent text, since the licence requires a link back to the repository.

Frequently asked questions

Official sources

1. Issues
2. PiMaker/ltcgi on GitHub
3. Project website
4. README
5. Releases