erhe, a Vulkan-shaped 3D graphics library with its own sandbox editor

An abstraction shaped like Vulkan, with three backends underneath

erhe is described as a C++ 3D graphics library and sandbox editor, with a Vulkan and Metal style rendering abstraction over OpenGL, Vulkan and Metal. The description in the repository puts it more plainly: a graphics API abstraction loosely modeled after Vulkan and Metal, with backends for OpenGL, Metal and Vulkan.

That shape is the project's main design decision. The abstraction is not a lowest common denominator that flattens every API into one dull subset. It is modelled on the two APIs that a modern renderer would actually be written against, command buffers and all, so that knowledge of Vulkan or Metal transfers directly. The backends then differ in what they can express.

The platform table shows the spread. Windows supports OpenGL and Vulkan and is the primary target. Linux supports OpenGL and Vulkan. macOS supports Vulkan and Metal. Meta Quest and Android are supported with Vulkan and OpenXR. The OpenGL backend needs OpenGL 4.5 with Direct State Access at minimum, with 4.6 recommended, and it is not available on Apple platforms at all, which is why macOS lists Vulkan and Metal instead.

The project describes itself as an actively-developed personal research project for real-time rendering and geometry, and it is the evolution of RenderStack. The C++ standard is C++20, the platforms are Windows, Linux, macOS and Quest, and the README carries a build and a test badge for the main branch. There are no GitHub releases, and the last push to the repository was on 2026-10-18.

The editor is the sandbox, the library is the point

The editor is described as a sandbox application for 3D scene creation and manipulation, and its feature list reads like a wishlist for someone learning real-time rendering.

The scene and viewport layer has multiple 3D viewports with independent camera and rendering settings, a hierarchical scene graph with node parenting, multi-scene support, a post-processing pipeline with bloom and tonemapping, shadow mapping, a PBR material system with a metallic and roughness workflow, and a material library with preview rendering.

The tools are the parts a graphics programmer actually reaches for. A fly camera gives 6DOF navigation with WASD, orbit, tumble, track and zoom. Selection is click-to-select with shift and ctrl multi-select, using either a GPU ID buffer or raytrace picking. There is a transform gizmo for translate, rotate and scale with axis and plane constraints and snapping, a brush placement system that puts shapes on surfaces with snap-to-face, rotation and scale-to-match, vertex painting, material painting per mesh face, physics interaction for dragging, pushing and pulling rigid bodies, and a configurable grid with snap-to-grid.

The geometry section is the deepest part. Subdivision supports Catmull-Clark and sqrt3, the Conway operators are there in full, ambo, chamfer, dual, gyro, join, kis, meta and truncate, and boolean CSG with union, intersection and difference is present but marked experimental, done via Geogram. There is a utility set for triangulate, normalize, reverse, weld, repair, generate tangents and bake transform, and full undo and redo for all operations.

Mesh creation covers parametric shapes including sphere, box, cone, torus, disc and cylinder, a brush system with reusable shape templates, 180 or more built-in polyhedra from Platonic solids to Johnson solids to geodesic domes, and procedural scene generation.

One configure script per platform, then a cmake build

Building is a configure step followed by a normal CMake build, with a script per platform and backend.

git clone https://github.com/tksuoran/erhe
cd erhe

# Windows (from an x64 Native Tools Command Prompt)
scripts\configure_vs2026_vulkan.bat

# Linux
scripts/configure_ninja_linux_vulkan.sh && cmake --build build_ninja_linux_vulkan --target editor

# macOS
scripts/configure_xcode_metal.sh && cmake --build build_xcode_metal --target editor --config Debug

Vulkan is the default backend, and the OpenGL build uses the matching scripts, for example scripts\configure_vs2026_opengl.bat. The repository carries CMakePresets.json alongside CMakeLists.txt, a cmake/ directory and a scripts/ directory, and the full set of backends, CMake options and IDE setup is documented in doc/building.md.

The pattern is worth noting for anyone planning to work on the project. Each configure script sets up a separate build directory, so the Linux Vulkan build lands in build_ninja_linux_vulkan and the macOS Metal build in build_xcode_metal, and the target is the editor. The editor is the artefact you compile, which follows from the project being a research sandbox rather than a shipped library.

The repository also carries a config/ directory, a res/ directory for resources, an android-project/ directory for the Quest build, a memory-bank/ directory, an AGENTS.md and a CLAUDE.md for assistant-driven work, a CHANGELOG.md, a pylintrc and a .codacy.yaml.

glTF with proprietary extensions, and USD that is explicitly partial

File format support is the part of erhe that most affects whether you can use your existing assets, and the answer is a qualified yes.

glTF 2.0 import and export go through fastgltf, including KHR_physics_rigid_bodies, KHR_materials_variants and the erhe specific ERHE_* extensions, which are documented in doc/gltf_extensions/README.md. Scenes can be saved as a single glTF binary carrying those ERHE_* extensions, or as USD, and the scene stays in the format it was opened from.

OpenUSD support is present and partial, via LightUSD, and it is optional, switched on with the ERHE_USD_LIBRARY=lightusd environment variable. Within that partial support, the README lists meshes, UsdPreviewSurface and OpenPBR materials, cameras, lights, xformOp stacks, time samples, skinning, physics, point instancers, composition arcs and variants. What it explicitly does not do is read MaterialX documents, and the compatibility details live in doc/erhe/usd_compatibility.md.

The USD editor side is similarly bounded: the editor can open, edit and save .usd, .usda, .usdc and .usdz stages, with references and payloads shown as prefab instances, variant sets, class prims as styles, and UsdPhysics and UsdSkel content handled.

Wavefront OBJ import has partial support, and the screenshot in the README is linked from the project wiki.

Node graphs, a GPU ray tracer and a CPU ray tracing library

Three subsystems stand out in the rendering side.

The node graph system has two halves. The texture graph is a Material Maker style procedural texture authoring system with around 75 node types, covering noises, patterns, gradients, transforms and colour operations. Nodes compose into a single fragment shader evaluated on the GPU, with live per-node previews, and they can be baked to textures and to PBR material channels. The geometry graph is node based procedural modelling, with parametric generators, subdivision, Conway operators, lattice deform, boolean CSG, point scattering and instancing, and nested node groups. It is evaluated asynchronously on worker threads so editing stays interactive. Both share a node editor canvas with a dockable node palette, undo and redo, and JSON serialisation, and the graphs are content library assets.

The ray tracing story is split by hardware. A CPU ray tracing library has swappable backends, madmann91 bvh, tinybvh and Embree 4, with BVH disk caching, and it is used for mouse picking and spatial queries. A GPU ray tracing renderer uses the Vulkan ray query compute path, with PBR material shading, real scene lights, ray traced shadows, and reflection and refraction for transmissive materials.

The VR side is OpenXR, with headset rendering, hand and controller tracking with visualisation, a floating HUD and hotbar UI in VR, and passthrough support. Input covers keyboard and mouse with configurable bindings, SpaceMouse 6DOF and OpenXR controllers.

An MCP server listening on the loopback interface

The most unusual feature in the editor is that it embeds an MCP server, so AI agents and scripts can drive a running editor. The transport is JSON-RPC over HTTP on 127.0.0.1:3743.

That address is the right one. Binding the control channel to the loopback interface means the editor is not offering scene manipulation to the local network, and the port is unlikely to collide with anything else in a development setup.

The README describes the server as working in three situations: the windowed build, the headless build with no display needed, and on Quest over adb forward. The API reference is in doc/agents/mcp_server_usage.md.

The exposed surface is broad, and the list the README starts with gives a good sense of it: scene queries covering scenes, nodes, cameras, lights, materials, textures, brushes, selection, the undo and redo stack, physics items and async load status, plus further scene operations that the excerpt cuts off. An agent that can query the scene graph, create and edit nodes and materials, drive the undo stack and read the load status is doing more than screenshotting the viewport, and a script can do the same thing without a language model in the loop at all.

The debug facilities around it are what make that usable in practice: debug line and text rendering inside the 3D viewports, physics shape visualisation, a render graph visualisation window, shader hot-reload through a shader monitor, a GL state dump to the clipboard, and Tracy profiler integration.

Editorial conclusion

erhe suits a graphics programmer who wants a Vulkan-shaped abstraction, a working editor with glTF, node graphs and ray tracing, and the freedom to read the implementation. It does not suit a team that needs a supported engine with a stable API, a release history or a community. Before you build on it, clone it and run the configure script for your platform, because the backends are not equivalent, OpenGL needs 4.5 with direct state access and does not exist on Apple platforms, and confirm that the custom licence in the LICENSE file matches what the MIT badge in the README implies before you ship anything.

Frequently asked questions

Official sources

1. Issues
2. README
3. tksuoran/erhe on GitHub