# LuminaEngine: a Vulkan game engine that requires mesh shader hardware

> Lumina is a C++ engine built around Vulkan, a sparse-set ECS and C# scripting through a bundled .NET 10 runtime. It describes itself as an educational project, and its GPU floor is high enough that many working machines cannot run the editor at all.

**MrDrElliot/LuminaEngine** — Advanced Open Source C++ Game Engine with multi-threaded Vulkan rendering.

- Repository: https://github.com/MrDrElliot/LuminaEngine
- Stars: 540 · Forks: 36
- Language: C++
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/mrdrelliot-luminaengine

## What LuminaEngine is for, and what it is not

The README is direct about this: Lumina is an educational project under active development, with APIs that may change and features marked experimental. The intended uses it lists are learning modern engine architecture, experimenting with Vulkan rendering, building prototypes on a modular codebase, and understanding how engines such as Unreal and Godot work internally. That framing matters more than any feature list. A project that names itself a teaching vehicle is telling you the API surface is a moving target, and the caution block in the README says exactly that.

The repository layout supports the claim. Engine/, BuildScripts/ and Templates/ sit at the top level next to Setup.bat, Setup.sh, GenerateProjectFiles.bat, GenerateProjectFiles.sh, LuminaBuild.bat and LuminaBuild.sh. This is a source-first project: there is no installer, no editor binary download, and no package manager entry. You clone it, run setup, generate project files and build. Anyone expecting a double-click editor install will be disappointed in the first five minutes.

So who is it for? Someone who wants to touch a real renderer and a real ECS rather than a framework that hides both. The README also mentions that contributions are recognized with Steam keys and Discord acknowledgment, which suggests the maintainer is courting outside contributors rather than running a closed product.

## The Vulkan renderer and the geometry pipeline that sets the hardware floor

Lumina's renderer is built on Vulkan with automatic resource tracking and barrier placement, a Forward+ pipeline with clustered lighting, and PBR materials authored in a material graph that compiles down to shader code. Those three pieces are the bulk of the rendering story. Automatic barrier placement is the part worth noting: Vulkan synchronization is where most hand-written renderers break, and moving that responsibility into the engine is a design decision that trades control for safety.

The constraint that shapes everything else is mesh shaders. Every platform needs a GPU supporting VK_EXT_mesh_shader: NVIDIA Turing (GTX 16-series or RTX 20-series) or newer, AMD RDNA2 (RX 6000) or newer, or Intel Arc. The README states the reason plainly: the geometry pipeline is built on them, so the editor refuses to start on older hardware and says so. This is not a soft requirement you can work around with a flag. A GTX 1080, a Pascal card that still runs plenty of modern titles, is below the line.

That single decision narrows the audience considerably. If you are evaluating Lumina for a project that must ship on older GPUs, or for a team whose machines are a few generations behind, the renderer is not merely slower there. It will not launch.

## ECS, reflection and the C# layer

The gameplay layer is an in-house sparse-set Entity Component System with per-type storage layouts, typed views and lifecycle signals. A reflection system sits on top of it and drives automatic serialization plus editor integration. That pairing is the interesting architectural bet: because components are reflected, the component inspector UI is generated automatically rather than hand-written per type, and serialization follows from the same metadata.

Scripting runs through LuminaSharp, described as a CoreCLR host that bundles the .NET 10 runtime. Gameplay is written as EntityScript classes with full ECS access: Registry.View queries, C# entity systems, and component reads and writes. The C++ to C# bindings are generated by the Reflector, which means the same reflection metadata that feeds the editor also feeds the scripting boundary. Scripts are hot-reloadable, so gameplay iteration does not require a C++ recompile.

There is also a World facade exposing Physics, Navigation, Input, Messages and GameplayTags. The README does not document the depth of those subsystems, so treat the facade as an entry point rather than a guarantee of feature parity with a mature engine.

On the C++ side, performance infrastructure includes a fiber-based multi-threaded task system, custom allocators built on RPMalloc, and profiling through a Tracy integration. Those are the components you would otherwise spend a year assembling.

## Installing LuminaEngine on Linux and running the setup check

The README gives a concrete Linux path. Start by cloning the repository, then install the build and runtime packages. The split matters: the Vulkan loader and driver are runtime dependencies only. The headers are vendored and volk resolves entry points with dlopen, so a machine with no driver will still compile a working editor that it cannot launch.

```bash
# build
sudo apt-get install -y g++-13 pkg-config libx11-dev libxrandr-dev \
    libxinerama-dev libxcursor-dev libxi-dev libxkbcommon-dev
# run
sudo apt-get install -y libvulkan1 mesa-vulkan-drivers vulkan-tools
# .NET 10 SDK: https://dotnet.microsoft.com/download/dotnet/10.0
```

GCC 13 or newer is the floor, or Clang against an equally new libstdc++. The README attributes that to the tree's use of <format>, and notes the project is built and tested with GCC 13 through 15, with newer pre-release compilers tending to reject vendored third-party code for reasons that are not bugs in this engine. X11 development packages are needed because GLFW links them directly.

Before building, run the setup script. It checks the toolchain and reports what is missing, including whether any installed GPU actually reports VK_EXT_mesh_shader.

```bash
./Setup.sh
```

Once setup passes, generate the build files and compile through the provided scripts.

```bash
./GenerateProjectFiles.sh
./LuminaBuild.sh
```

The README does not show the expected console output of a successful build, so the first thing to confirm is that Setup.sh reports the mesh shader extension as present. If it does not, stop there: the editor will refuse to start. On Linux there is no generated solution; CLion reads the generated compile_commands.json for C++, and Rider opens the engine's C# projects.

## The Visual Studio 2022 trap on Windows

Windows setup looks simpler than Linux until you reach the toolchain versions. You need Windows 10 (1803 or newer) or Windows 11, 64-bit, Visual Studio 2026 (18.0 or newer) with the MSVC v143 toolset and the .NET desktop development workload, plus the .NET 10 SDK (x64).

The README flags a specific failure that will catch people out. LuminaSharp targets net10.0, and only Visual Studio 18.0+ can build that target. Visual Studio 2022 (17.x) fails with error NETSDK1209 even if the standalone .NET 10 SDK is installed, because VS uses its own bundled MSBuild rather than the standalone one. Installing the SDK does not fix it. This is the kind of constraint that costs an afternoon if you discover it by building rather than by reading.

Setup.bat validates the environment and stops with a clear message when something is missing, so the practical advice is to run it before touching the solution. The README notes that no IDE is required and that JetBrains Rider and Visual Studio both open the generated solution, so the Visual Studio requirement is about the MSBuild that ships with it, not about the editor you write code in.

There is no documented rollback path for the setup scripts and no uninstall procedure in the README. Treat setup as something you run on a machine you are willing to configure.

## Where LuminaEngine is the wrong tool, and what to use instead

The clearest disqualifier is hardware. If your deployment target includes GPUs below Turing or RDNA2, Lumina's geometry pipeline rules it out entirely, and no build flag changes that. The second disqualifier is stability expectations: the README calls the project educational and warns that APIs may change and some features are experimental. A team shipping a commercial title on a fixed schedule would be building on sand.

The natural alternative is Godot. The comparison is not about features but about approach: Godot ships prebuilt editor binaries you download and run, supports a much wider range of GPUs including older hardware, and its GDScript and C# layers sit on a mature, versioned release cycle. Lumina asks you to compile the engine from source, requires mesh shader hardware, and tells you the API may move. If your goal is to ship a game, Godot removes the build step and the hardware floor.

If your goal is to understand how an engine works, the trade reverses. Godot's internals are large and take time to map. Lumina's tree is small enough to read end to end, and the reflection-driven editor and the Reflector-generated C++ to C# bindings are concrete examples of patterns you would otherwise only read about. The README explicitly frames the project as a way to understand how engines such as Unreal and Godot work internally, and that is the honest use case.

A third option worth naming: writing your own Vulkan renderer. Lumina is what that effort looks like after three years, per the README, which makes it a useful reference before you start rather than after.

## Licence and the cost of tracking an engine that changes

Lumina is Apache-2.0. That is a permissive licence, and it is the reason the project is usable as a learning reference and as a starting point for prototypes without the copyleft questions that come with GPL-family engines. It is not legal advice, and the Apache-2.0 text in LICENSE is the authority; the practical implication is that you can read, modify and redistribute the code under the terms it sets out, including its patent grant and its notice requirements.

The upgrade cost is the part people underestimate. Because Lumina is source-first, there is no versioned binary to pin. You track the main branch, and the README's own warning about changing APIs applies to every pull. The repository has one release, tagged external-deps and dated 2026-06-21, which is a dependency snapshot rather than a feature release. That tells you the project does not publish semantic version boundaries you can plan migrations around.

The last push to the repository was on 2026-06-21. The README describes the engine as under active development, and the repository is not archived, but three months of quiet is worth knowing before you build a workflow on top of it.

One more cost: the C# layer bundles the .NET 10 runtime, and the C++ side vendors its dependencies (see DEPENDENCIES.md and the external-deps release). You are not just tracking engine changes; you are tracking a toolchain floor that moves with .NET and with your compiler.

## Conclusion

Lumina suits engineers who want to read and modify a real engine: the ECS, reflection layer and Vulkan renderer are all in the tree, and the C# layer gives a fast path to gameplay code. It is the wrong choice if your target hardware predates mesh shaders or your team is pinned to Visual Studio 2022, since the .NET 10 target fails there with NETSDK1209. Before committing, run Setup.sh or Setup.bat on the actual build machine and confirm the GPU reports VK_EXT_mesh_shader; the renderer will not start without it.

## FAQ

### What is LuminaEngine used for?

The README lists learning modern game engine architecture, experimenting with Vulkan rendering techniques, building prototypes on a modular codebase, and understanding how engines such as Unreal and Godot work internally. It describes itself as an educational project under active development rather than a shipping product.

### Who owns and maintains LuminaEngine?

The repository is MrDrElliot/LuminaEngine and the README credits the engine as hand-crafted over three years as a passion project, with contributions recognized in the Discord community. The README does not name a company behind it.

### What GPU does LuminaEngine require?

Every platform needs a GPU supporting Vulkan mesh shaders (VK_EXT_mesh_shader): NVIDIA Turing (GTX 16-series or RTX 20-series) or newer, AMD RDNA2 (RX 6000) or newer, or Intel Arc. The editor refuses to start on anything older because the geometry pipeline is built on mesh shaders.

### Does LuminaEngine work with Visual Studio 2022?

No. The C# layer targets net10.0, and only Visual Studio 18.0+ (2026) can build that target. Visual Studio 2022 (17.x) fails with error NETSDK1209 even with the standalone .NET 10 SDK installed, because VS uses its own bundled MSBuild.

### What scripting language does LuminaEngine use?

C# through LuminaSharp, a CoreCLR host that bundles the .NET 10 runtime. Gameplay is written as EntityScript classes with Registry.View queries, C# entity systems, and component reads and writes, and scripts are hot-reloadable.

## Sources

- [Official README](https://github.com/MrDrElliot/LuminaEngine#readme)
- [Project repository](https://github.com/MrDrElliot/LuminaEngine)
- [Release notes](https://github.com/MrDrElliot/LuminaEngine/releases)

---

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