threepp

threepp is a cross platform C++20 3D library that ports the high level API of three.js into native code under the MIT licence. Its scene graph, materials, cameras, controls and loaders track three.js around revision r129 with changes from later revisions in some areas, and its OpenGL 3.3 backend is a mechanical port of the WebGL renderer. A second backend is a deferred Vulkan renderer whose shading path is ray query based, tracing ambient occlusion, global illumination, reflections and shadows with no raster fallback, denoised and with temporal antialiasing.

Gaussian splat support is a first class scene object called SplatCloud and it renders on both backends. Two loaders read scans, the original INRIA .ply and PlayCanvas SOG, and the Vulkan path adds dynamic level of detail on top of a compute tile rasterizer. The OpenGL path draws the same cloud as an instanced mesh with a CPU side depth sort, which makes it the portable option and also the slower one.

The splat integration deliberately stops short of full participation in the traced scene. Nothing places a splat into an acceleration structure, so a cloud casts no shadows, contributes nothing to global illumination and is invisible to the ray traced sensors, and neither a SplatCloud nor a particle field is serialised into a scene document. Two opt in routes exist around that. Each cloud bakes a small density and radiance volume that the water, glass and glossy reflection legs march as a stand in for the cloud, primary view only, and splats::bakeSurface fuses the depth AOV into a triangle mesh that PhysX can collide against and that the simulated sensors can perceive behind a setSensorOnlySurfaces flag that is off by default.

The project states plainly that it exists for research, prototyping and education rather than as a production hardened engine, and that API and behavioural stability are not prioritised. The three.js port is the mature half and barely moves between releases. The simulation layer is where the work goes and where the breakage lives, and the Vulkan backend evolves fastest of all. Builds are tested on Windows, Linux, macOS, MinGW and with Emscripten, where the OpenGL path becomes the WebGL2 target.

Around the renderer sits that simulation layer. PhysX reduced coordinate articulations load straight from a URDF or a xacro file in one call, simulated LIDAR, depth, colour and event cameras read ground truth out of the Vulkan G buffer as float32 metric depth, instance ids, semantic classes, normals and motion, and a scene editor and a headless player save documents as ordinary three.js Object JSON so an authored scene runs with no editor present. Python bindings ship on PyPI as prebuilt wheels for CPython 3.10 through 3.14 on Windows x64 and manylinux x86_64, carrying the OpenGL renderer, the Vulkan deferred renderer with its AOVs, and CPU PhysX. macOS has no wheel and builds from source with OpenGL only.