Mechanics deep-dive — how triplane representations work end-to-end: ray-casting from camera, bilinear lookup on 3 axis-aligned feature planes, small MLP decoder, volume rendering. The performance story: 10–100× faster than vanilla NeRF, 6–12 MB memory for 256² × 32-ch triplanes, single-forward-pass encoding at 20–40 ms on a consumer GPU. The conceptual story: when you render a triplane scene, you are not rendering a mesh — you are volume- rendering directly from the triplane feature lookup. Mesh extraction is a separate downstream step.
By January 2026 the thesis line had three competing 3-D representations on the table: SDF + marching cubes (Hexplane AE, Six-Plane Mesh, traditional), Gaussian splats (Splatter Image, GS-LRM, fast rendering but procedural-pipeline unfriendly), and triplanes (EG3D, InstantMesh, TRELLIS- style). The triplane deep-dive was the pick-the-default exercise: how does triplane rendering actually work, what is the memory and speed profile, and does it compose with the procedural-pipeline constraints the thesis line has.
The deep-dive output was the decision to use triplane (and its hexplane / six-plane generalisations) as the universal intermediate representation for the thesis line. The Hierarchical Triplane work (Topic 33), the Hexplane AE work (Topic 29), and the SculptNet primitive output all consume a triplane-family representation downstream. The triplane is the spine that connects the topics.
| Property | Triplane | NeRF | Gaussian splats |
|---|---|---|---|
| Storage | 3 × H × W × C (≈ 6–12 MB at 256², C = 32) | MLP weights only (≈ 1–5 MB) | N Gaussians × 60 floats (≈ 50–500 MB) |
| Render time, 256² image | ~30–80 ms | ~1–10 s (without grid acceleration) | ~5–15 ms |
| Memory at render | Constant per ray (3 bilinear lookups + MLP) | Grows with sample density | Grows with #Gaussians per pixel |
| Mesh extraction | Query dense grid → marching cubes | Same | Splat-to-mesh conversion needed |
| Editability | Edit features on 2-D planes | Re-train | Move Gaussians directly |
Triplane rendering renders the triplane, not a mesh.
Mesh extraction is a separate downstream step.
A common misconception: triplane representations are stored, then converted to mesh, then the mesh is rendered. They are not. The rendering loop volume-renders the triplane directly by bilinear-sampling features along each ray. Mesh extraction (query a dense 3-D grid and run marching cubes) is only needed when the downstream consumer wants explicit triangles — e.g., for Houdini integration in the thesis line's procedural-pipeline use case.
Cast rays through the triplane. The left pane shows the three feature planes (XY, XZ, YZ) for the current shape. The middle pane shows a ray's bilinear-sample path through each plane. The right pane shows the volume-rendered output. Drag the right canvas to orbit.
White paper · triplane mechanics · three-way comparison vs G-Splats vs VDB · universal-intermediate decision