# Carbon Trinity: the rendering engine behind the Carbon Game Engine > Carbon Trinity is CCP Games' MIT-licensed C++ renderer for the Carbon Game Engine. It builds only on Windows with Visual Studio 2017 v141 tooling, and every renderer backend is off by default. **carbonengine/trinity** — Rendering engine for the Carbon Game Engine - Repository: https://github.com/carbonengine/trinity - Stars: 460 · Forks: 78 - Language: C++ - License: MIT - Published: 2026-09-17 · Updated: 2026-09-17 · Language: en - Canonical page: https://hysenlabs.com/projects/carbonengine-trinity ## What Carbon Trinity is, and who it is for This is not a general-purpose renderer you drop into an unrelated C++ project. It is the rendering layer of the Carbon Game Engine, published by CCP Games under the MIT License, and the README frames it as one component among several that sit next to each other in an engine tree. That framing matters: the build system has a mode called INSTALL_TO_MONOLITH whose stated purpose is to install trinity next to the rest of the engine components. The audience is therefore narrow and specific. You are a graphics or engine programmer working inside Carbon, or someone evaluating whether the renderer is separable enough to reuse. The repository layout supports that reading: trinity/ and trinityal/ sit alongside shadercompiler/, python/, cmake/ and vendor/, which is the shape of an engine subproject rather than a library with a stable public API. Nothing in the README promises ABI stability or a documented interface for outside consumers. If you are choosing a renderer for a new project with no Carbon dependency, the prerequisites alone will tell you this is the wrong starting point. If you are already in the Carbon tree, the install path is already written for you. ## How the build is wired: presets, vcpkg and SSH submodules Three mechanisms define how this repository assembles. First, dependencies are git submodules cloned over SSH, so a plain clone without --recurse-submodules leaves you with an incomplete tree. Second, package resolution goes through vcpkg, with vcpkg.json and vcpkg-configuration.json at the top level and a vendored copy expected under vendor/github.com/microsoft/vcpkg. Third, CMake presets drive configuration; the README points at CMakePresets.json and tells you to run cmake --list-presets to see what is available. The backend situation is the part most likely to surprise a first-time builder. Every option is OFF by default, and the README states plainly that a plain build has no renderer backend. DirectX 11, DirectX 12, Metal and the shader compiler are all opt-in flags passed at configure time, and each one pulls extra vcpkg packages during that configure. So there is no default rendering path: you choose a backend or you have nothing to render with. The toolset coupling is equally explicit. The -T flag must match VCPKG_PLATFORM_TOOLSET in your preset's triplet, and the documented preset pairs x64-windows-internal with v141. Get that pairing wrong and the failure surfaces at configure time rather than at link time. ## Installing Carbon Trinity and generating a first solution Start by cloning with submodules, because the SSH-based dependencies will not arrive otherwise. The README gives the recursive clone as the primary path and the update command for an existing checkout. ```bash git clone --recurse-submodules ``` ```bash git submodule update --init --recursive ``` Next, generate the solution. The documented preset is x64-windows-internal, and the architecture and toolset flags are required alongside it. ```bash cmake --preset x64-windows-internal -A x64 -T v141 ``` According to the README, this produces an .slnx under .cmake-build-/. Open that generated solution rather than the repository folder; the README warns that opening the folder makes Visual Studio reconfigure the same build directory and discard the -G, -A and -T settings. Those three flags only apply to a new build folder, so delete the folder if you need to change them. To get an actual renderer, pass the backend options at configure time. Each one is off by default and adds vcpkg packages on that configure. The README lists BUILD_DX11, BUILD_DX12, BUILD_METAL, BUILD_SHADER_COMPILER and WITH_GRANNY as the available options, written as -D arguments. If configure fails complaining about a missing /scripts/toolchains/windows.cmake, the README's remedy is to set PATH_TO_VCPKG_ROOT in your environment to /vendor/github.com/microsoft/vcpkg. ## Installing into a Monolith engine tree The INSTALL_TO_MONOLITH option is the supported way to place trinity next to the other engine components rather than in its own build directory. The README shows it combined with CMAKE_INSTALL_PREFIX pointing at a vendor folder. ```bash cmake --preset x64-windows-internal -A x64 -T v141 ` -DINSTALL_TO_MONOLITH=ON ` -DCMAKE_INSTALL_PREFIX="" ``` This is the path that matches how the project is meant to be consumed. If you are building Carbon itself, this is likely the configuration you want; if you are only poking at the renderer in isolation, the plain preset is enough. Note that the README does not document what INSTALL_TO_MONOLITH copies, nor does it list the files that land in the prefix. You find that out by running the install step and inspecting the destination. ## The Windows and Visual Studio 2017 constraint The single largest limitation is the toolchain. The documented path requires Visual Studio with the v141 (VS 2017) C++ build tools component, and the only preset named in the README is x64-windows-internal. There is no documented Linux or macOS preset, and no CI configuration is described in the README even though the repository contains .github/ and .teamcity/ directories. That combination is unusual in 2026. A new graphics project would typically target a current MSVC toolset. Requiring v141 suggests the renderer is pinned to the ABI and toolchain of the wider Carbon engine, which is a reasonable choice for an in-house engine and an awkward one for anyone outside it. If your project already builds with a modern MSVC toolset, you cannot simply point this renderer at it; the -T value must match VCPKG_PLATFORM_TOOLSET in your triplet, so the triplet has to change too. The Metal option deserves the same scrutiny. BUILD_METAL exists as a flag, but the README gives no macOS preset, no Xcode instructions and no statement about which platforms are actually supported. Treat the flag as the presence of Metal targets in the build graph, not as a documented macOS workflow. A second, quieter failure mode is the SSH submodule requirement. GitHub SSH access is listed as a prerequisite, so a machine without a configured SSH key fails at clone time with an error that has nothing to do with the renderer. ## Carbon Trinity compared with bgfx and Filament The obvious alternatives for a C++ renderer are bgfx and Google's Filament, and the difference is architectural rather than cosmetic. bgfx is a rendering library with a single API that maps onto many backends and is designed to be embedded in a host application; you link it and call it. Filament is a full rendering engine with its own material system, and it ships as a library you integrate into an app. Carbon Trinity is neither of those things in its published form. It is a component of an engine, built through that engine's presets, installed into that engine's vendor folder, and gated behind per-backend options that are off by default. The README does not document a public API, an integration guide, or a supported set of host applications. Where bgfx's selling point is portability across platforms and backends, Trinity's documented build is Windows and MSVC 2017 only. The trade-off is real in both directions. bgfx and Filament ask you to adopt their abstraction and their release cadence. Trinity asks you to adopt Carbon's toolchain and directory conventions. If you are already inside Carbon, the second cost is zero and the first would be substantial. If you are not, the second cost is the whole project. ## Licence, contributions and what MIT does not cover The project is MIT licensed, and the README states that submitting a pull request or otherwise contributing means you agree to license your contribution under the MIT License and confirm you have the right to do so. That is a standard inbound-equals-outbound arrangement and it is worth reading before you send patches, because it applies to any contribution, not just large ones. The licence text itself is not the whole story. The README carries an explicit trademark notice: CCP Games is a trademark of CCP ehf, and nothing in the MIT License grants rights to CCP Games' trademarks or game content. So the code is permissive, but the name and any game assets are not. If you fork this, the MIT grant covers the source; it does not give you the right to present the result as CCP's, and it does not hand you game content. Third-party code is itemised separately in NOTICE.md, which you should read before redistributing a binary, since those components may carry terms that differ from MIT. This is a description of what the documents say, not legal advice. On maintenance, the last push to the default branch was on 2026-09-17, and the most recent release listed is v6.1.0 on the same date, following v6.0.0 on 2026-09-02 and v5.2.2 on 2026-08-12. The README does not describe a support policy, a deprecation process, or an upgrade path between major versions, so planning a version upgrade means reading release notes rather than following documented migration steps. ## Conclusion Adopt Carbon Trinity if you already build the Carbon Game Engine on Windows and need a renderer that slots into that tree; the INSTALL_TO_MONOLITH path exists for exactly that. Do not adopt it as a standalone cross-platform renderer or on macOS, because the documented preset is x64-windows-internal and Metal targets are only reachable through the BUILD_METAL option. Before committing, verify that CMake 3.31 or newer and the v141 build tools are installed, that your GitHub account can read the SSH submodules, and that PATH_TO_VCPKG_ROOT points at vendor/github.com/microsoft/vcpkg if configure fails on the missing windows.cmake toolchain file. ## FAQ ### How do I install Carbon Trinity? Clone the repository with --recurse-submodules, since the dependencies are submodules cloned over SSH, then generate a solution with cmake --preset x64-windows-internal -A x64 -T v141. The README states this produces an .slnx under .cmake-build-/, which you open instead of the repository folder. ### How do I use Carbon Trinity in a build? Pass the backend options as -D flags at configure time, because all options are OFF by default and a plain build has no renderer backend. BUILD_DX11, BUILD_DX12, BUILD_METAL, BUILD_SHADER_COMPILER and WITH_GRANNY each pull extra vcpkg packages on that configure. ### What does Carbon Trinity require before it will configure? The README lists CMake 3.31 or newer, Visual Studio with the v141 (VS 2017) C++ build tools component, and GitHub SSH access for the submodules. It also notes that -T must match VCPKG_PLATFORM_TOOLSET in your preset's triplet. ### Why does Carbon Trinity fail on a missing /scripts/toolchains/windows.cmake? The README addresses this configure failure directly and says to set PATH_TO_VCPKG_ROOT in your environment to /vendor/github.com/microsoft/vcpkg. ### Can Carbon Trinity be used outside the Carbon Game Engine? The README presents it as the rendering engine for the Carbon Game Engine and documents an INSTALL_TO_MONOLITH option for installing it next to the rest of the engine components. It does not document a public API or an integration guide for unrelated host applications. ### What licence is Carbon Trinity released under? It is MIT licensed, and the README states that contributors agree to license their contributions under the MIT License. The README also notes that nothing in the licence grants rights to CCP Games' trademarks or game content, with third-party code listed in NOTICE.md. ## Sources - [carbonengine/trinity on GitHub](https://github.com/carbonengine/trinity) - [Issues](https://github.com/carbonengine/trinity/issues) - [License: MIT](https://github.com/carbonengine/trinity/blob/main/LICENSE) - [README](https://github.com/carbonengine/trinity/blob/main/README.md) - [Releases](https://github.com/carbonengine/trinity/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/carbonengine-trinity