PlanetExplorer

Personal project · Active development

C++17VulkanCMake / NinjaEngine-agnostic C ABIMarching cubes · LODGoogleTest

PlanetExplorer is a voxel-based procedural-planet engine I'm building from scratch in C++. It began as a Unity (URP) prototype; I've since retired the engine host entirely and am rebuilding it as a standalone C++ engine — for full control of the render and memory model, and the freedom to run outside any engine. The core is deliberately kept engine-agnostic, so it can still be embedded in Unreal or Unity later if I ever want to, without recompilation coupling.

A full Earthlike planet from orbit — procedural biomes (ice, ocean, archipelago, desert) with a live biome probe

Walking the surface — real-time terrain, volumetric clouds, and the live planet configurator with a performance HUD

'Dune' preset — an arid desert world from the same system with a different seed and biome weights

Marching-cubes meshing visible at low detail — the voxel surface the engine generates and streams as chunks

What it does

Generates full procedural planets in real time — orbit them, then drop into a walk view on the surface.
A live biome system (Earthlike, Desert, Lava, Ice World, Archipelago) with per-biome temperature / moisture / bias, and presets like Varied World, Dune, and Glacia.
An in-engine configurator — seed, region size, latitude, blend, warp, fog, sky — that regenerates the world live.
A performance HUD that surfaces the systems work under the hood: frame rate, chunk count, occlusion culling, and disk-cache hit/miss for chunk streaming.
Marching-cubes meshing with an adjustable detail/LOD level (visible as the raw voxel surface in the last shot).

Architecture — three hard-walled layers

The design principle is a narrow, well-specified boundary between layers, so each can evolve (or be swapped) independently.

flowchart TD
  subgraph HOST[host — thin platform shell]
    H[window · input · main loop
standalone today, swappable]
  end
  subgraph REND[renderer — our own, adapter seam]
    G[GraphicsBackend interface] --> VK[VulkanBackend
device · swapchain · pipelines]
  end
  subgraph CORE[core — pure C++, flat C ABI, zero deps]
    C[voxel density · marching cubes
transvoxel LOD · chunk streaming · world state]
  end
  H --> G
  H -->|C ABI| C
  G -->|meshes / buffers| C
  CORE -. embeddable later .-> UE[Unreal native module]
  CORE -. embeddable later .-> UN[Unity native plugin]

core — pure C++ behind a flat C ABI with zero engine/GPU/windowing dependencies. This is the reusable jewel: voxel density fields, meshing (marching cubes / transvoxel LOD), chunk streaming, and world state. Because the boundary is a C ABI, it links into any host without coupling.
renderer — a custom renderer over Vulkan, sitting behind a backend-agnostic GraphicsBackend adapter seam so a different GPU backend (e.g. WebGPU/Dawn) can be dropped in later without touching engine code.
host — a thin standalone shell owning window, input, and the frame loop; drives the core through the C ABI.

Engineering discipline

Deterministic core tests (GoogleTest + CTest) with C-ABI contract tests that grow per subsystem.
GPU pipelines validated against a CPU reference on identical input — ported compute must match the reference implementation.
Headless renderer: offscreen clear + pixel readback, unit-tested, with golden-image comparison planned in CI using a software adapter.

It also runs headless

Beyond the interactive views above, the engine runs headless for CI — a bounded smoke check brings up a validated Vulkan device and meshes terrain, then exits:

PlanetExplorer engine core v0.3.0
renderer: Vulkan backend on "NVIDIA GeForce RTX 3080" (validation on)
presenter: 3 images, 1280x720, format=44
terrain mesh: 34770 vertices
world created (seed=42 radius=1000.0 chunk=32); entering loop (smoke)

WIP — the engine already renders full procedural planets with live biome editing, occlusion culling, and chunk streaming (above). Ongoing work: transvoxel LOD, Hi-Z occlusion refinement, and broader platform coverage. Source is private for now.

Why it's here: it's the C++/engine-level and native-embedding counterpart to my SDK work — the same discipline of a flat, well-specified boundary that lets independent layers move without breaking each other.