MethaneKit: a C++20 graphics abstraction over DirectX 12, Vulkan and Metal

An abstraction layer, described in three lines

The readme states the scope in three bullets, and each one is a design commitment rather than a feature list.

The first is that it builds on top of modern native 3D graphics APIs: DirectX 12 on Windows, Vulkan on Linux, and Metal on macOS, iOS and tvOS. That is the substrate, and the project is explicit that it sits on the native APIs rather than inventing its own.

The second is that it simplifies modern graphics programming with an object-oriented medium-level graphics API inspired by the simplicity of Apple Metal. The word medium-level is doing the work. A low-level API such as DirectX 12 or Vulkan exposes command lists, descriptor heaps, pipeline state objects and synchronisation primitives, and a high-level engine hides all of it. This sits in between, which is the layer where you still control the rendering but do not have to hand-manage the platform's resource plumbing.

The third is that common shader code in HLSL 6 is used on all platforms. That is the part that most often breaks a port, because each vendor's shading language is different, so a single HLSL 6 shader set that compiles for DirectX 12, Vulkan and Metal removes a large and tedious category of work.

The framework half is described separately, as a cross-platform application framework with a CMake build toolchain, platform-independent application foundation classes, and a native GUI layer for Windows, Linux and macOS. The word application rather than engine is deliberate, and the readme does not claim a scene graph, a physics system or an asset pipeline.

The primary language is C++20, which is what makes the resource ownership story workable, since a modern C++ engine can express GPU resource lifetimes with the same vocabulary as CPU lifetimes.

The build matrix says what is actually supported

The readme's largest element is a table, and it is worth reading carefully because it is the most precise statement of what the project supports.

The rows are platform and graphics API combinations. The first entries are Windows x64 and Windows x86 with DirectX 12, and then Windows x64 with Vulkan. The columns are the graphics API, the master build status and the develop build status, and each cell is a link to a build status record.

The master and develop distinction is the one to notice. This is a project that maintains a stable line and a development line in parallel, with continuous integration building both, and the status of each combination is published per platform and per graphics API. So you can see, before you clone anything, whether your target configuration is currently green.

That is a real service to a reader. A cross-platform graphics library is exactly the kind of project where a given platform and API combination can be broken while the others are fine, and where the difference between supported and aspirational is easy to miss.

The visible rows also tell you something about priorities. Windows with DirectX 12 is listed first, twice, for both 64-bit and 32-bit, and Vulkan on Windows follows. The rest of the table covers the Linux, macOS and mobile combinations, and the badges are per platform rather than a single global one, which again points to a project that tracks each configuration separately.

The pipeline is as prominent as the API

The badge row at the top of the readme is longer than most projects of this size, and each badge corresponds to a different kind of verification.

There is a continuous integration build badge, a CodeQL scan badge, a Sonar scan badge, a SonarCloud quality gate status, a CodeCov coverage badge, and a Test Space badge for the number of test cases. The readme says these let you check the latest build status, tests, code coverage and analysis results, or get build artefacts from the GitHub Actions pipeline and Sonar Cloud.

Four independent kinds of static analysis in one project is unusual, and each covers something different. A build badge tells you the code compiles on each configuration. CodeQL is a query based analyser for security-relevant patterns, which matters more than usual in a graphics library because the code is full of pointer arithmetic, manual memory and platform API calls. Sonar measures maintainability metrics and enforces a quality gate, which for a project with a large object-oriented API is a way of keeping the design from sprawling. Coverage shows how much of the code the tests actually reach, and the test case badge is a slightly unusual metric but a good proxy for how much of the framework is exercised by something other than a human clicking through the tutorials.

For an evaluation, the useful question is not how many badges there are but whether the numbers are good. The coverage badge and the quality gate are the two to look at, and the fact that they are published rather than hidden behind a login means you can compare this project with any other.

The repository is arranged like a course

The top level of the tree is the clearest description of the project's structure, and it reads like a syllabus.

There is an Apps directory, and the readme points at the first tutorial by name, the Hello Triangle application, and at the Methane Graphics RHI module, which is the rendering hardware interface, the layer that talks to DirectX 12, Vulkan or Metal. There is a Build directory with its own readme holding the manual build instructions, a Modules directory holding the framework's libraries including the graphics RHI, a Tests directory, a Docs directory, a Resources directory, a CMake directory, a CMakeLists.txt at the root, a CMakePresets.json for the IDE and build configuration, and an Externals directory for the third-party dependencies.

The separation of Apps, Modules and Tests is the significant part. The applications are the examples and tutorials, the modules are the library, and the tests are separate from both, which means the test suite is not just the tutorial programs with assertions added.

The configuration files show the tooling in use: a codecov configuration, a Sonar project properties file, a security policy, an editor configuration for IntelliJ and one for Visual Studio Code, and a Claude instructions file at the root, which suggests the project has been developed with an AI coding assistant in the loop rather than merely with one added recently.

The release builds are published with pre-built samples, tutorials and tests, and the readme explicitly invites you to download them to try the project out. That is a thoughtful choice for a graphics framework, because the difference between a working and a broken toolchain on a given machine is often a day of unpacking, and a pre-built Hello Triangle answers that question in a minute.

Where to start, and what to expect from the version number

The recommended path is spelled out: see the build instructions topic for manual builds, then start learning the graphics RHI API with the Hello Triangle application and the documentation of the other tutorials.

That ordering is the sensible one, because the RHI is the layer everything else sits on, and Hello Triangle is the smallest program that exercises it end to end. A graphics abstraction can hide an enormous amount of platform behaviour, and the only way to find out whether the abstraction is actually hiding what you need is to build something small with it.

The version history gives a sense of the project's maturity. Version 0.8.0 was released on 2025-01-02, version 0.8.1 on 2025-05-09 and version 0.8.2 on 2026-08-27, and the last push was on 2026-09-20, with the repository not archived.

A 0.x version number is the honest signal here. It means the API is still allowed to move, and for a library whose entire value is that it is the stable layer between your code and three graphics APIs, that is a real consideration rather than a formality. The project publishes release builds with samples and tutorials, which is the right way to let people try it without committing to a version.

The licence is Apache-2.0, which is permissive and appropriate for a framework that companies will build products on. The project has no homepage beyond the repository, and the documentation lives in the Docs directory and in the tutorials, which is consistent with a project whose users are developers reading source-adjacent documentation rather than visitors.

Editorial conclusion

MethaneKit suits a graphics programmer who wants one modern API across the three native graphics stacks, in a language with real object lifetime rules, and who is prepared to learn an abstraction rather than pick one vendor's API. It is a poor fit if you want a game engine, since what is described here is a rendering abstraction and an application framework, and it is a poor fit if you need a stable API, since the project is on a 0.x version line. Before you build on it, read the build instructions for your platform, compile the Hello Triangle tutorial first to confirm the toolchain works on your machine, and pick the graphics API you will actually ship with, since the abstraction is built to let you choose late.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. MethanePowered/MethaneKit on GitHub
4. README
5. Releases