Lumen: a Vulkan ray tracing framework for path tracing research

Variance reduction is the point, not a feature

The README describes Lumen as a Vulkan ray tracing framework that contains a variety of variance reduction techniques, with the aim of accelerating some of the well-known rendering techniques in computer graphics literature with the help of the ray tracing hardware in modern GPUs. All the techniques Lumen implements run fully on the GPU.

That framing matters, because it tells you what the codebase is for. Lumen is not a general renderer with a path tracer in it. It is a bench on which several light transport algorithms can be run against the same scene, so you can see what a given variance reduction technique actually buys you.

The primary language is C++, the licence is MIT, and the topic tags name the algorithms it implements, with bdpt, mlt, restir, vcm and path-tracing among them, plus vulkan. The default branch is master, and there is no homepage beyond the repository, which is consistent with a project that lives in its own issue tracker rather than on a product site.

The three tools the README names as useful are the ones a researcher would reach for. There is a tutorial on the documentation site, an API reference, and a background post on what a user interface is, and the last of those is a good sign about how the project intends to be read.

Eleven integrators, from path tracing to ReSTIR

The Rendering Techniques list is the centre of the project, and it reads like a table of contents for a course on light transport.

There is a unidirectional path tracer with multiple importance sampling, listed as Path. There is a bidirectional path tracer, BDPT, and stochastic progressive photon mapping, SPPM. There is vertex connection and merging, VCM, primary sample space Metropolis light transport, PSSMLT, and a combined VCM plus MLT integrator, VCMMLT.

Then the resampling family. ReSTIR on its own, ReSTIR GI, and ReSTIR PT under the name GRIS, the unbiased variant. And two real-time oriented entries, DDGI for dynamic diffuse global illumination, and FFT convolution bloom.

That spread is what makes the framework worth the effort of setting up. A path tracer is something you can write in an afternoon; a VCM or a ReSTIR PT implementation is a research project on its own. Lumen puts them in one engine, with one scene format and one output path, which is what makes them comparable.

The showcase section backs this up with rendered images of glass caustics under VCM, a Mitsuba torus, the Japanese classroom scene credited to Benedikt Bitterli, video comparisons of ReSTIR and ReSTIR GI at one sample per pixel, and a Cornell box with dynamic diffuse global illumination.

A scene system in JSON, a Mitsuba parser and a Vulkan layer of its own

The Engine section lists what a renderer needs and, in each case, Lumen has its own answer.

The materials are diffuse, mirror, glass, conductor, dielectric and the Disney Principled BSDF. The lights are spot, described as point, polygonal and directional. The scene system is JSON-based, and there is a modified Mitsuba parser, which is the bridge to the large body of existing research scenes.

The most distinctive entry is a lightweight Vulkan abstraction layer from scratch. A renderer that owns its Vulkan layer can express exactly the ray tracing queries it needs rather than bending a general purpose graphics API to them, and it keeps the codebase independent of any particular engine's scene and material conventions.

Around that sit the practical features: EXR output on F10, on-the-fly RMSE computation so you can see how the image is converging while it renders, and SPIRV reflection.

The repository layout backs the same picture, with `src/` for the renderer, `libs/` for third-party code, `scenes/` for sample scenes, `assets/` and `media/`, and an `example_config/` directory. The reference list is equally telling, with Physically Based Rendering: From Theory to Implementation, the vertex connection and merging paper, the spatiotemporal reservoir resampling paper, the ReSTIR GI paper, and the dynamic diffuse global illumination paper from the Journal of Computer Graphics Techniques.

The render graph leans on experimental Vulkan features

Render graph support is listed as experimental, and the About experimental features section is unusually specific about what that means.

The render graph provides automatic resource and synchronization management, binding inference based on shader reflection results, and a simple builder pattern. Underneath it, Lumen uses some of the more experimental Vulkan features.

The first is templated push descriptors, which the README notes may be problematic with AMD. The second is event-based synchronization through the synchronization2 API, available from Vulkan 1.3, described as an experimental feature that may not work depending on your driver, and that may need Vulkan beta drivers on Nvidia. It is enabled through a `use_events` flag in the Render Graph settings:

    - Enabled via `use_events` flag in the Render Graph settings. (See `RenderGraphSettings` in `RenderGraphTypes.h` and `RayTracer.cpp`)

The two mechanisms interact badly with driver support, which is the practical point. Push descriptors remove a step in the descriptor update path, and event-based synchronisation replaces fences with a finer-grained primitive, and both are exactly the kind of feature where a driver is either conformant or merely plausible. For a user, the honest summary is that Lumen's render graph is fast on drivers that implement these features correctly and a source of crashes or stalls on ones that do not.

Building needs a Vulkan SDK, a recent GPU and CMake

The build instructions are short. You clone the repository recursively:

git clone --recursive https://github.com/yuphin/Lumen.git

The recursive flag matters, because the repository carries a .gitmodules file, so the third-party code in `libs/` is fetched with submodules rather than vendored.

The requirements are listed next: the Vulkan SDK, a Turing+ or RDNA2 GPU, and CMake 3.4 or above. The GPU requirement is the significant one, because it defines the floor of what you can run the framework on at all, and the README notes the CPU does the ray tracing work through the hardware the vendor provided for it.

The CMake port is credited, with the README giving credit to @Lachei for porting the project to CMake and testing it on Linux. That detail says something about the project's history, that the build was not always a CMake build, and that the port came with the Linux testing, which is also why the requirement list mentions CMake rather than the original build system.

The instructions use the Windows executable name in the usage section, so the project is developed on Windows even though the porting credit points to Linux testing as well.

Running a scene is one command, and the first file to read is Path.cpp

Usage is minimal. Sample scenes live in the `scenes/` directory, and sample scene files with various integrators are in the `scenes/cornell_box/` directory, so the fastest way to see the difference between the techniques is to run the same scene through several of them. Loading a scene is:

Lumen.exe <scene_file>

The Getting started section recommends a reading order, and it is a good one. Start with the unidirectional path tracer implemented in `src/Raytracer/Path.cpp` and gradually explore the other integrators, and from there focus on the related shaders in the `src/shaders` folder.

Path.cpp is the right starting point because it is the simplest of the integrators and because everything else in the codebase is built around the same idea, a path from the camera into the scene, with the differences between techniques living in how paths are generated and how samples are weighted.

For a user, the practical first session is therefore: clone, build, run the Cornell box with the path tracer, then run the same scene with the other integrators and compare the output and the convergence. The on-the-fly RMSE computation in the engine is what makes that comparison legible, since it tells you how far the current estimate is from a reference.

No release since 2022, but the branch is still moving

The maintenance picture is unusual and worth stating plainly. The recent releases are v1.1.1 from 2022-11-27, v1.1.0 from 2022-11-20 and v1.0.0 from 2022-05-01, and the repository is not archived with the last push on 2026-10-07.

So the branch is four years ahead of the last tag. There is no GitHub release to point at, no changelog file in the root to read, and the README's feature list describes the current state of the code rather than a released version. The `media` directory with the showcase images and the `example_config` directory in the root suggest that the working state is the interesting artefact, and that a user is expected to build from master.

That is a coherent way to run a research codebase, and it is also the reason to read the code rather than the tags. The features in the list, the render graph, the experimental Vulkan paths, the real-time entries, are all things that have to be present in the working tree to be visible at all.

The licence is MIT, with a LICENSE.txt at the repository root, so there is no obstacle to using the code in commercial work, and the reference list gives the papers behind each technique if you want to check an implementation against its description.

Editorial conclusion

Lumen fits a graphics researcher who wants to compare light transport techniques on the same scene and the same hardware, and who is comfortable reading integrator source and tuning a renderer. It is the wrong choice for production rendering work, since the last tagged release is v1.1.1 from 2022-11-27 even though the branch was pushed on 2026-10-07. Verify first that your GPU qualifies and that the experimental Vulkan features the render graph relies on are enabled by your driver, because templated push descriptors and event-based synchronisation are named as problematic on some vendors.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. yuphin/Lumen on GitHub