Inexor's Vulkan renderer is a render graph engine still chasing an octree

The stated objective is an octree engine, not a finished one

Inexor is described as an open-source project which combines modern C++ with the Vulkan API, and the project description calls it a new, render-graph based 3D game engine for Linux and Windows using C++20 and Vulkan API 1.3, with the parenthetical note that it is in early development.

The README is more specific about where the work currently stands. The current main objective is the development of a new 3d octree game engine. That single sentence tells you the state of the project better than any feature list would. An octree is a spatial subdivision structure, and building a scene around one implies a particular approach to culling, traversal and level of detail, which is a design commitment rather than an implementation detail.

The release history makes the same point from the other direction. The recent releases are a nightly build from 2026-10-12, then 0.1.0-alpha-3 from 2020-05-17, described as an RAII refactoring snapshot, and v0.1-alpha.2 from 2020-04-26, described as Vulkan API test 2, First octree demo. The names of the alpha releases describe what they were, which is a Vulkan API test and then a first octree demo, and the last tagged snapshot was a refactoring of resource management.

So the project has a working nightly and a six-year-old alpha tag. That is the profile of an engine being built in the open rather than shipped, and the documentation rather than the README is where the answers are, with the FAQ and the getting started guide linked from a readthedocs site and the project homepage at inexor.org.

The licence is MIT, with the LICENSE file in the repository as the authoritative text, and this is a licensing statement rather than legal advice. That is a good licence for a codebase people intend to read.

The repository layout shows a complete engine, not a demo

The top level entries are the best available picture of the engine's structure, and they describe something with all the parts a real engine needs.

There is src/ and include/ for the implementation and its public headers, shaders/ for the shader sources, platform/ for the platform abstraction, and assets/ for resources. The cmake/ directory and the CMakeLists.txt and CMakePresets.json at the root are the build system, and a .clang-format and .clang-tidy pair the formatting and the static analysis configuration.

Then there are the three directories that separate an engine from a library. The example-app/ directory holds a runnable application, which is how an engine proves it works rather than asserting it. The tests/ directory is the test suite. The benchmarks/ directory is a performance harness, which matters for a renderer, because the whole point of a render graph is that you can measure the cost of a frame graph and see what it did.

The documentation/ directory is substantial enough to have its own configuration, with a .readthedocs.yml at the root and the documentation source living under documentation/source, since the README references image paths like documentation/source/images/inexor-banner.svg. The build instructions and the getting started guide are both hosted on readthedocs, with separate anchors for building on Windows and building on Linux, which tells you the project is developed and documented for both platforms rather than one.

Two other entries are worth a mention. SECURITY.rst is a security policy file, which is a good sign for a project that wants outside contributions, and .git-blame-ignore-revs is the mechanism for marking a commit as a formatting-only change so that git blame stays useful across a repository with automated formatting. Both are small details that indicate the project is run with some care.

The GitHub Actions build workflow is on the main branch, and there is a Discord server linked from the badges.

A render graph is the central architectural bet

The render graph is what distinguishes this engine from a straightforward Vulkan tutorial, and the project description leads with it as the defining characteristic.

A render graph is a description of a frame as a set of passes and the resources they read and write, from which the driver or engine can derive the execution order, the barriers between passes, the resource lifetimes and the opportunities to fuse or cull work. Writing that description by hand in Vulkan means ordering the passes yourself, inserting the right barriers yourself, and getting it wrong in ways that produce subtle corruption or a pipeline stall rather than a clean error.

Declaring the graph instead lets the engine do that derivation. The payoff is that a pass which writes a resource nobody reads can be removed, and passes that could share a barrier can be scheduled together, without the developer having to know that was possible.

The repository topics reinforce the reading, listing both framegraph and rendergraph alongside rendering, vulkan, vulkan-api, vulkan-renderer, vulkan-engine, vulkan-game-engine, graphics-programming, 3d-engine, 3d-game-engine, game-engine, gamedev, engine, cplusplus, cplusplus-20, open-source, mit-license. A project with that many topic tags is telling search engines exactly which intersection it occupies, and the render graph terms appear twice, which is a reasonable signal of emphasis.

C++20 is the other half of the bet. The project pairs a modern language with a modern API, Vulkan 1.3, and describes itself as combining modern C++ with the Vulkan API. A Vulkan 1.3 requirement also tells you something about the hardware floor, since 1.3 brought dynamic rendering, synchronization2, and the copy commands that a modern renderer leans on.

The open question is how much of this is exercised. The alpha release names, a Vulkan API test and a first octree demo, describe a project that got as far as proving the API works and demonstrating the spatial structure, and the nightly tag since then says the work continues without a new named milestone.

Building means following the readthedocs instructions for your platform

The README does not carry build commands, and it points to the documentation instead. The quickstart links the Building Instructions and the Getting started page, and the building page has separate sections for Windows and Linux, which are the anchors the README uses.

The building instructions live at inexor-vulkan-renderer.readthedocs.io under the development section, and the getting started guide is a separate page in the same place. The FAQ is the entry point the README gives for anything else, and it is linked as the project documentation in the opening line.

What the repository tells you about the build is the tooling. CMakePresets.json at the root means the build is defined as named presets rather than raw command lines, which is what you want in a project with several platform and configuration combinations, and it is the mechanism by which a new contributor can be told to use one preset instead of a long incantation. The cmake/ directory holds the module and toolchain files, and the .clang-format and .clang-tidy files apply to the same tree.

The one dependency you can be confident about is a Vulkan 1.3 capable driver, since the engine targets Vulkan API 1.3 and there is no compatibility path described for older versions. The README's own screenshot of the documentation site suggests the rest of the toolchain is documented rather than obvious.

The sponsor credit is worth noting for the contributor experience. Special thanks go to JetBrains for providing CLion licenses, and there is a CLion icon in the documentation images. A project that ships a .clang-tidy configuration and a .git-blame-ignore-revs file is clearly developed with an IDE-aware workflow, and having a commercial IDE licensed for contributors is the kind of thing that keeps a small project moving.

There is a nightly release tag dated 2026-10-12, which means CI produces a build artefact continuously even though no new semantic version has been cut since 2020.

The FAQ is the project, and the nightly carries the current work

The structural fact about this repository is that the README is a signpost rather than a manual. Almost every question a new user would ask is routed to the readthedocs site: the FAQ, the building instructions for Windows and Linux, the getting started guide, and the licence page.

That is a deliberate choice and it is a common one for projects whose documentation is too large to maintain in a README. The trade-off is that the first impression of the project, for anyone who lands on the GitHub page, is thin. The badges tell you the language is C++20, the platforms are Linux and Windows, the build workflow passes, and the licence is MIT, and the body text tells you the objective and the sponsors. The rest is one click away.

The documentation structure also tells you the project treats the engine as a product with an audience beyond the developers, which is consistent with having a benchmarks/ directory and an example-app/ directory rather than only a src/ tree.

For an outside contributor, the practical path is the getting started guide, then the FAQ, then the build instructions for the platform you are on. The Discord server is the place for questions that the documentation does not answer, and the project is on readthedocs with a build badge, so the docs are versioned with the code rather than drifting.

The project also has a presence outside the repository. The homepage is inexor.org, and the documentation hosts an FAQ and the usage pages. The nightly release tag, updated on the same day as the last push on 2026-10-12, is the mechanism by which anyone can pick up the current state of the engine rather than the 2020 alpha snapshot.

Editorial conclusion

Adopt the Inexor vulkan-renderer as a codebase to read and contribute to rather than as an engine to ship a game on today. The project names its own objective, a 3D octree game engine, and the tagged release history is old even though nightly builds continue, so the honest use is study and participation. Before you build it, follow the readthedocs building instructions for Windows or Linux, expect to need a Vulkan 1.3 capable driver, and read the FAQ, since the documentation is where the project's own answers live rather than in the README.

Frequently asked questions

Official sources

1. inexorgame/vulkan-renderer on GitHub
2. License: MIT
3. Project website
4. README
5. Releases