# LuisaRender: a Monte Carlo renderer with CUDA, Metal and DirectX backends > LuisaRender is a C++ Monte Carlo renderer for stream architectures, layered on top of the LuisaCompute framework and published alongside a SIGGRAPH Asia 2022 paper. It ships one command line binary, a choice of five backends including an LLVM-based CPU fallback, two scene description formats, and converters from Tungsten and glTF that the documentation openly says need manual fixing. **LuisaGroup/LuisaRender** — High-Performance Cross-Platform Monte Carlo Renderer Based on LuisaCompute - Repository: https://github.com/LuisaGroup/LuisaRender - Stars: 628 · Forks: 58 - Language: C++ - License: BSD-3-Clause - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/luisagroup-luisarender ## An application on top of a framework, and a paper behind both LuisaRender is described as a high-performance cross-platform Monte Carlo renderer for stream architectures, built on LuisaCompute. The distinction the README makes between the two projects is the most useful thing in it. LuisaCompute is the framework, the general purpose layer that abstracts the compute and graphics APIs and the parallel execution model. LuisaRender is the rendering application that sits on it, and the one that implements the actual renderer: the path tracing algorithms, the scene representation, the sampling and the integrator. Both are covered by the same SIGGRAPH Asia 2022 paper, titled LuisaRender: A High-Performance Rendering Framework with Layered and Unified Interfaces on Stream Architectures. The README also points at a project page with more information about the paper and the project, and at the LuisaCompute repository for the framework side. That framing tells you who this is for. A rendering application built on a research framework, described in a paper, is aimed at people who want to understand or extend a modern path tracer rather than people who want a tool with a user interface. The topics confirm the audience: cpp, cuda, gpu, ispc, metal, optix, path-tracing, ray-tracing and rendering. The licence is BSD-3-Clause, which is the permissive licence research code usually uses, and the default branch is called next, which is the branch name a project uses when the released line and the development line are handled separately. The repository layout is small and typical for this kind of project: src/ for the code, tools/ for the conversion scripts, a CMakeLists.txt, a BUILD.md with platform requirements and configuration options, a .clang-format and .clang-tidy for style, a .gitmodules file, and a CODE_OF_CONDUCT.md. ## Five backends, and the hardware rule underneath them The portability story is in the backend table, and it is worth reading alongside the platform support statement. The command line takes a backend argument, and the possible values are cpu, cuda, dx, metal and fallback, where fallback is the LLVM-based CPU path. What each of those implies is spelled out in the build notes. CUDA is supported on Linux and Windows, DirectX on Windows, Metal on macOS, and ISPC and LLVM on all the major platforms. The ISPC and LLVM entries matter more than they look: they are the portable CPU compilation paths, which is why a machine with no supported GPU can still build and run the renderer. There is a hardware condition, and it is a hard one. For CUDA and DirectX, an RTX-enabled graphics card is required, with NVIDIA RTX 20 and 30 series given as the examples. That is not a preference for a newer card, it is the requirement for the ray tracing hardware those backends need, and it means the CUDA and DirectX paths are unavailable to anyone on a GTX card, on a laptop with a non-RTX GPU, or on a machine with no discrete GPU at all. One more constraint from the same section: you need to enable the corresponding compilation options for the backend you chose. The backend list is therefore a menu of what can be built, not a list of what runs everywhere. The practical consequence is that the fallback backend is the universal answer, and the specialised ones are the point of the project. ## A recursive clone, C++20 and OptiX 7.1 The build is a standard CMake build with a few unusually modern requirements, and the README is explicit about the toolchain. The first step is the clone, and the option matters. The project uses Git submodules to manage its third-party dependencies, so a recursive clone is required: ```bash git clone --recursive https://github.com/LuisaGroup/LuisaRender.git ``` If you forget the flag, the configure step fails later with missing dependencies, and the fix is to re-clone rather than to hunt for packages. Then the environment. The README recommends the latest IDEs, compilers, CMake and CUDA drivers, and explains why: the project aggressively uses new technologies like C++20 and OptiX 7.1 or later. The concrete advice is to upgrade Visual Studio to 2019 or 2022 and install CUDA 11.2 or newer. The configure step is the usual CMake invocation, and the README gives both the general form and a concrete example: ```bash cd LuisaRender cmake -S . -B build -D CMAKE_BUILD_TYPE=Release ``` You can add generator and build type options such as -G Ninja and -D CMAKE_BUILD_TYPE=Release, and if the configuration step fails the README asks you to file an issue. The build itself is cmake --build with the build folder name, and the result is a single executable at /bin/luisa-render-cli. The separate BUILD.md file holds the platform requirements, the configuration options and the other precautions, which is where the details live when the README's summary is not enough. ## One binary, a backend flag and a device index The usage section is a single command line, which tells you a lot about the shape of the tool. ```bash /bin/luisa-render-cli -b [-d ] ``` The -b flag selects the backend from the list of five, the optional -d flag selects a device index for the multi-GPU case, and the final argument is the scene file. There is no configuration file, no scene database and no interactive mode, which is what you would expect from a research renderer that is driven by a script or a benchmark harness. The help output is a flag of its own: ```bash /bin/luisa-render-cli -h ``` and the README gives the long form --help as an alternative. The build folder placeholder is spelled oddly in the README, so if you copy the line literally, expect to fix the path. There is a second executable in the tree, produced from src/apps/export.cpp and installed as /bin/luisa-render-export. It exists to convert glTF scenes into LuisaRender's JSON-based format, which makes it a build artifact rather than a separate project, and it is the second half of the scene story that the next section covers. ## Two scene formats, and two converters that need hand fixing LuisaRender supports a JSON-based format and a custom text-based format for scene description, and the demo scenes are maintained in a separate repository, LuisaRenderScenes, with its own releases. The conversion story is where the honesty in this README is refreshing. The project provides a simple script at tools/tungsten2luisa.py to convert Tungsten scenes into the custom scene description language, and a CLI application at src/apps/export.cpp to convert glTF scenes into the JSON-based format. But the README says plainly that both tools are not perfect and that manual tweaks are sometimes necessary to fix conversion errors or to align the converted scenes to their original appearances. That sentence is more useful than a claim of completeness would have been. A converter that silently changes the look of a scene is worse than one that is known to need checking, and a renderer aimed at researchers is a place where you can expect to be trusted with the caveat. The division of labour between the two formats is also worth noting. The text format is the target of the Tungsten converter, and the JSON format is the target of the glTF exporter, so the choice of scene description is partly determined by which converter you want to use. The credits in this section set out where the scene assets came from: the authors of the demo scenes, Rendering Resources, Poly Heaven, and the Blender demo files, with a thanks to all of them. A limitation follows directly from the design. If your scene exists only in a format neither converter reads, you are writing a parser, not a configuration. ## The demo scenes, their settings, and who owns the assets The README walks through six demo scenes, and for each one it lists the download, the credit, the resolution, the sample count and the tonemapping, which is the kind of detail that tells you how a renderer is meant to be used. The Contemporary Bathroom scene is 1024 by 1024 with 65536 samples and ACES tonemapping at an exposure of -0.5, credited to Mareck under CC0. The Bedroom is 1280 by 720 with 65536 samples and Uncharted2 tonemapping, credited to SlykDrako under CC0. The Camera scene is 3840 by 2160 with 65536 samples and Uncharted2, and every resource in it comes from Poly Heaven under CC0 with the details in the contained README.txt. The Kitchen is 1280 by 720 with 65536 samples and ACES, credited to Jay-Artist under CC BY 3.0. The Spaceship is 1920 by 1080 with 16384 samples and Uncharted2, credited to thecali under CC0. The Modern Hall is 1024 by 1024 with 65536 samples and Uncharted2 at an exposure of +1, credited to NewSee2l035 under CC BY 3.0. Two things come out of that list. The sample counts are high, in the tens of thousands, which is a Monte Carlo renderer's normal operating range, and the fact that most scenes use 65536 while the Spaceship uses 16384 suggests the budget is per scene rather than fixed. The second is the licensing, which is mixed rather than uniform. Some assets are CC0, where the attribution in the README is a courtesy rather than a requirement, and two are CC BY 3.0, which does require attribution and a share-alike condition on adaptations. The scene archives are distributed through the separate scenes repository, and each archive contains its own README.txt describing the resources, so the terms travel with the files. For anyone using these scenes as a benchmark, that is the detail to read first, not the pixel counts. ## Where a research renderer is the wrong tool It is worth being direct about the cases where this project is the wrong choice, because it is a research framework rather than a product. There is no user interface. Everything is a command line invocation with a scene file, so if you want to look at a scene, adjust a scene interactively and watch it converge, you are using the wrong tool and you should be using a renderer with a viewport. The scene pipeline assumes conversion. A scene in a format that neither the Tungsten script nor the glTF exporter can read has to be brought in by hand, and the README's own caveat about manual tweaks is a reminder that this step is not frictionless. The hardware requirement narrows the audience further. Without an RTX-enabled card, the CUDA and DirectX backends are unavailable, and the remaining options are Metal on macOS or the LLVM-based CPU fallback. The fallback is there, and it is the reason the project is still usable on a laptop, but the specialised backends are the reason the project exists. Finally, the project state. There are no GitHub releases, so there is no versioned artefact to download and no changelog to diff against a previous version, and the default branch is named next, which signals a development line rather than a stable one. The last push to the repository was on 2026-07-16, and the project documentation is the README plus BUILD.md plus the paper, which is a thin documentation base for a codebase of this size. None of this makes the project bad. It makes it a specific thing: a readable, paper-backed renderer for people who want to work on the renderer. ## Conclusion LuisaRender suits graphics researchers, students and engineers who want to read and modify a modern path tracer written for stream architectures, and who are willing to convert their own scenes and to configure the build themselves. It does not suit someone who wants a renderer with a user interface and a large collection of ready-made scenes, because the whole project is a command line application with converters that need hand correction, and it does not suit a workstation without an NVIDIA RTX card if you intend to use the CUDA or DirectX backends. Check three things before you start: which backend your hardware can actually run, since an RTX card is required for CUDA and DirectX, that you cloned with submodules, because the third-party dependencies are managed that way, and that the scene you want is available in a format the two converters can read. The last push to the repository was on 2026-07-16, the default branch is named next, and the project publishes no GitHub releases. ## FAQ ### What is LuisaRender and how does it relate to LuisaCompute? LuisaRender is a high-performance cross-platform Monte Carlo renderer for stream architectures built on LuisaCompute. LuisaCompute is the underlying framework, and LuisaRender is the rendering application described in the SIGGRAPH Asia 2022 paper, which covers both. ### Which backends can LuisaRender use? The command line takes a backend value of cpu, cuda, dx, metal or fallback, where fallback is the LLVM-based CPU path. CUDA is supported on Linux and Windows, DirectX on Windows, Metal on macOS, and ISPC and LLVM on all major platforms, and an RTX-enabled card is required for CUDA and DirectX. ### How do I build LuisaRender from source? Clone with git clone --recursive https://github.com/LuisaGroup/LuisaRender.git because the third-party dependencies are Git submodules, then configure with cmake -S . -B build -D CMAKE_BUILD_TYPE=Release and build with cmake --build. The result is the CLI executable at /bin/luisa-render-cli, and BUILD.md holds the platform requirements and configuration options. ### How do I convert an existing scene to LuisaRender? There is a script at tools/tungsten2luisa.py for Tungsten scenes and a CLI application at src/apps/export.cpp, compiled to /bin/luisa-render-export, for glTF scenes. The README states that both tools are not perfect and that manual tweaks are sometimes needed to fix conversion errors or match the original appearance. ### Where are the demo scenes and what are their licences? They are maintained in the separate LuisaRenderScenes repository and released as archives. The credits in the README are mixed: several scenes are CC0, while the Kitchen and Modern Hall are CC BY 3.0, and each archive contains a README.txt with the resource details. ## Sources - [Issues](https://github.com/LuisaGroup/LuisaRender/issues) - [License: BSD-3-Clause](https://github.com/LuisaGroup/LuisaRender/blob/next/LICENSE) - [LuisaGroup/LuisaRender on GitHub](https://github.com/LuisaGroup/LuisaRender) - [README](https://github.com/LuisaGroup/LuisaRender/blob/next/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/luisagroup-luisarender