Luma Framework: swapping rendering passes in DirectX 11 games through ReShade

What changes when a mod owns the post processing stage

Luma is a modding framework for improving graphics in DirectX 11 games, and the mechanism is specific: it uses the ReShade addon system to add or modify rendering passes and to replace shaders, such as the post processing ones, through DirectX hooks. Most of the generic shader work in the project is focused on HDR output support, but the description is careful to say there is a lot more to it already, with DLSS support named as an example, and no limit to what it can do. The distinction from a conventional shader injection mod is the depth of the hook. A standard ReShade install injects effects at the end of the render chain. Luma sits inside the game's own rendering phase and refactors it, which is why the flagship mod for Prey from 2017 can change the post processing rendering phase itself. Multiple games are already in the code, including a template project, and adding another is described as relatively easy.

It doubles as a graphics analyzer for any DX11 title

The second capability is arguably the more broadly useful one. Luma also acts as a graphics analyzer, with what the README calls deep debugging capabilities: it captures all draw and dispatch commands and state changes in DirectX, and the list of what it records is specific, including SRVs, RTVs, UAVs, DSV and constant buffers. The way to use it is to download the graphics analyzer and point it at any DX11 game, which means the tool is not limited to the titles that already have a Luma mod. For someone reverse engineering how a game renders a frame, that is the more interesting half of the project, and it costs you only the DX11 hook rather than the whole framework. The screenshot in the README shows a captured frame with its state, which is the sort of view that answers the question of why a particular pass produced the image it did.

The build wants a very recent Visual Studio

The development requirements are the first practical hurdle and they are strict. Windows 11 is listed, with Windows 10 probably working fine too. The Windows 11 SDK 10.0.26100.0 is named, with a note that older versions work but do not support HDR as well. Visual Studio 2026 is the stated tool, with 2022 and older said to work but currently best with the v145 Microsoft C++ Build Tools, and only the Desktop development with C++ component package is needed. Two smaller requirements follow from that: vcpkg, and the latest VC++ redistributable before running the code, with the note that users are expected to update to the latest versions, though a _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR define can be used to avoid that. The vcpkg version integrated with Visual Studio is called less reliable than installing it separately, and the project points at the microsoft/vcpkg repository for that install. There is no install command in the documentation, so the path is to fetch vcpkg from there, point the VCPKG_ROOT environment variable at the installation folder, and then build. Building means opening Luma.sln and building it, with one warning that matters: Edit and Continue build settings, the ZI option, should not be used, because they break the code patches generation, at least for projects that use DKUtil such as the Prey mod. The hot spots are in core.hpp and in each game's main.cpp.

Three configurations, and the debug build is exponentially slower

Luma uses the game project itself for developing and shipping the mods, and the build configuration is the switch that decides what you get. The three are DEVELOPMENT, TEST and PUBLISHING, and toggling between them enables the respective features, which then spread to the shaders automatically on the next load or compile. Both the Development-Release and Development-Debug builds have debug symbols, so breakpoints work in either, but the Debug build has optimisations disabled and more logging, which the README says makes it exponentially slower and should only be used when debugging is actually required. It warns that Visual Studio might default to Debug, so you have to change it manually. The other developer-facing rule is that the mod automatically dumps the game's shaders in development builds, and those dumps land in the Shaders folder for that game, with hand written shaders going in the same place unless they are generic, in which case they belong in the generic folder. Shaders are saved and replaced by their compiled binary hash, and VSCode is the suggested editor for them.

Adding a game is a template project and an environment variable

The process for a new game is laid out step by step, and it reads like a checklist for someone doing this for the first time. You copy the template file from the Templates/VisualStudio folder into the Visual Studio project templates directory under your user profile, then add a new project to the solution under Source/Games and select the Luma Template project. You can name it with the full game name including spaces, and the newly created main.cpp file has comments explaining what to replace. Each mod's version is stored in Globals::VERSION and can be increased there. Win32 games are supported too, with BioShock 2 named as an example, and you have to select the platform for it. Then you add an environment variable named LUMA_GAME_NAME_BIN_PATH, for example LUMA_BIOSHOCK_2_BIN_PATH, pointing at the game's executable folder where ReShade goes, and set the post-build event to copy the binaries into that folder. Finally the debug command is set to the game executable path so the game runs and attaches when debugging, with the note that this often does not work on games with DRM.

ReShade is a dependency, and the reason is a good one

The project explains why it stands on ReShade, and the reasoning is worth reading because it defines what Luma is and is not. It would be possible to achieve the same result with generic DirectX hooks and game specific code hooks alone, but that would be exponentially more complicated, even if it were more performant. The reason given is that some engines reuse render target textures for different purposes, so it is not easy to tell which ones should be upgraded, and ReShade offers settings serialization among a bundle of other features. That is an honest engineering trade: give up some performance and some control in exchange for a working abstraction that survives engines doing clever things with their render targets. The version required for a new mod is ReShade 6.6.0 or newer, usually the current latest, installed in the game's directory. The addon's job is to make the mod load, and the framework's job is to know what to do once it is there.

Releasing is a pull request and a Publishing-mode test

The release process is automated on the build side. GitHub Actions builds all the game projects and packages them with their respective shaders, the Luma folder, and once a mod is ready you make a pull request to the original repository. The instruction to test the mod in Publishing mode before wrapping it up is there for a specific reason: both the shaders and the C++ code can change depending on the configuration, so a mod that works in Development is not evidence that the shipping build works. The public releases follow a build-number scheme rather than semantic versions, with recent tags like latest-755 on 2026-10-17, latest-749 a few days earlier and latest-741 before that, so the release stream is a rolling series of builds tied to the repository's main branch. The last push was on 2026-10-17, the same day as the newest build. The repository also carries a Scripts directory, a Data directory, an install-githooks.ps1 file and an update-submodules.bat, which tells you the hook and submodule setup is part of the expected workflow rather than an afterthought.

Luma is not the Starfield or Kingdom Come mods

Two boundary clarifications in the README prevent a lot of confusion. The first is about scope of the project. Luma was born out of the modding code the author originally wrote for Prey, and the author soon realised it could be made generic and reused on other games. The Starfield and Kingdom Come Deliverance Luma mods are not built on the generic framework and should not be confused with it, although some authors and some features such as the HDR work are shared, and they are separate entities. The second is about comparison with RenoDX, from which the project says it took inspiration. Luma is similar in spirit but is focused on modding games deep down, adding and replacing entire rendering techniques and adding DLSS or ultrawide support, and porting simple mods between the two is said to be relatively easy. That is a fair characterisation of the difference in ambition, and it tells you which one to reach for: RenoDX for a user-facing mod, Luma for a rendering-pipeline rewrite. The licence field on the repository points to a custom licence that GitHub cannot classify, with the terms in the LICENSE.md file at the root, so read that file before you redistribute anything built with it.

Editorial conclusion

Luma suits a modder who wants to rebuild the post processing stage of a DirectX 11 game rather than bolt a shader onto it, and a graphics programmer who wants to capture every draw and dispatch call in a DX11 title to understand what it does. It does not suit a modder working on a game that is not DirectX 11, and the toolchain requirement of Visual Studio 2026 with a specific vcpkg setup is a real barrier on an older machine. Before you start, check that the game is in the mod list in the project wiki, and read the licence file at the root, because the licence field on the repository points to a custom one that GitHub cannot classify.

Frequently asked questions

Official sources

1. Filoppi/Luma-Framework on GitHub
2. Issues
3. README
4. Releases