VoxForge
A voxel editor where an AI suggests scene changes as proposals that are checked and previewed before anything is applied.
- TypeScript
- Next.js 16
- React 19
- React Three Fiber 9
- three.js 0.184
- node:test
key results
- 16,384 → 8draw calls at 16,384 voxels, per-voxel meshes vs. one InstancedMesh per material
- 55.1 → 0.13 msframe time at 16,384 voxels on my RTX 5090, in a three.js reproduction of both paths
- 200 / 200identical picks between the two render paths
- 259tests (node:test), all passing
demo
media
how it works
ai output is a proposal, not code
The model never edits the scene. It returns a proposal, which VoxForge checks for 15 kinds of issue: a stale revision, world bounds, scope, ownership, confirmation for destructive changes and others. A valid proposal is previewed on a cloned scene, and accepting a preview that has gone stale is refused.
Two back-ends sit behind one server-side route: the local Codex CLI, or an OpenInfer gateway reached through the OpenAI Responses API.
rendering many voxels
Components with 512 or more voxels render as one InstancedMesh per material instead of
one mesh per voxel, and picking still resolves a single voxel through instanceId. The
benchmark reproduces both paths in plain three.js: at
16,384 voxels, 16,384 draw calls become 8 and frame time drops from 55.1 ms to 0.13 ms on
my RTX 5090; at 65,536 voxels it’s 279.5 ms vs. 0.44 ms. It measures three.js only, not
React or R3F overhead.
the rest of the editor
- An image-to-voxel pipeline with four modes, edge-connected background removal and palette limits.
- Undo and redo over 60 snapshots.
- An x:z spatial index for region selection.
what i'd do next
- Measure the whole app, React and R3F included; the benchmark covers the three.js scene graph only.
- Host the editor at voxforge.makinchii.dev with a demo project.
- Record a proposal going from prompt to preview to accept.