The editorial frames the algorithm's longevity as a case study in specialization beating generalization: triangle rasterization is a general-purpose hammer while Voxel Space is a scalpel cut for dense 2.5D heightfields. Modern GPUs burn budget on vertex transforms, LOD chunking, frustum culling, and overdraw — costs the columnar front-to-back ray-cast avoids structurally rather than algorithmically.
Notes that Kyle Freeman's engine ran on a 33 MHz 486 with no FPU and no GPU, yet shipped a commercial flight sim with terrain detail that polygon competitors like F-15 Strike Eagle III couldn't match for another half-decade. The entire core loop is roughly 40 lines of code, which underscores how much leverage the right algorithm provided over the brute-force approaches of the era.
By resurfacing s-macke/VoxelSpace on HN (263 points), davikr is implicitly endorsing the port as the reference everyone reaches for when the trick comes up. The MIT-licensed, dependency-free JS reimplementation runs a 1024×1024 heightmap at stable framerate on a mid-range phone without WebGL, shaders, or triangles — making the algorithm immediately legible to anyone who opens the tab.
Sebastian Macke's `s-macke/VoxelSpace` repo climbed to 263 points on Hacker News this week — a JavaScript reimplementation of the rendering engine NovaLogic's Kyle Freeman built in 1992 for *Comanche: Maximum Overkill*. The demo runs in a browser tab, renders a 1024×1024 heightmap at a stable framerate on a mid-range phone, and the entire core loop is about 40 lines of code. No WebGL. No shaders. No triangles.
The technique, often called "Voxel Space" despite using no actual voxels, is a front-to-back columnar ray-cast over two paired bitmaps: one for terrain height, one for color. For each screen column, you step outward from the camera along the ground plane, sample the height map at each step, project that height to screen-space Y, and fill the column from the previous highest pixel up to the new one. Closer samples occlude further ones automatically because you walk front-to-back and never overdraw. That's the whole algorithm.
In 1992 this ran on a 33 MHz 486 with no FPU and no GPU, and it shipped a commercial flight sim with terrain detail that polygon-based competitors like *F-15 Strike Eagle III* couldn't match for another half-decade. Macke's port — MIT-licensed, dependency-free, originally written in 2014 and quietly maintained — is the canonical reference everyone links to when this trick resurfaces, which it does roughly every two years on HN.
The interesting question isn't "isn't this cute?" It's: why does a 34-year-old algorithm with no hardware acceleration still feel competitive on terrain rendering? The answer is that triangle rasterization is a general-purpose hammer, and Voxel Space is a scalpel cut perfectly to the shape of one specific problem: dense, mostly-2.5D heightfields viewed from above the surface.
Modern GPUs spend most of their terrain budget on vertex transforms, LOD chunking, frustum culling, and overdraw — all costs that Voxel Space avoids structurally rather than algorithmically. Front-to-back column traversal gives you perfect occlusion for free. The step size doubles with distance, so LOD is implicit in the loop counter — no quadtrees, no continuous-LOD seam fixups, no geomorphing. Memory access is strictly linear per column, which is exactly what cache prefetchers want. The cost scales with screen pixels, not world complexity, so a 16384×16384 heightmap costs the same as a 1024×1024 one as long as the visible columns are the same.
Compare that to a Unreal Nanite-style virtualized geometry pipeline: streaming clusters, GPU-driven culling, visibility buffers, software rasterization for tiny triangles. Nanite is a marvel, but it exists because triangles are the wrong primitive for high-frequency detail and the industry has spent twenty years building scaffolding around that mismatch. Voxel Space's relevance in 2026 isn't "GPUs are bad" — it's "the primitive shapes your algorithm to your data, and most modern engines force-fit terrain into the triangle pipeline because the tools assume triangles."
The HN comment thread on this submission split predictably. The graphics-programmer faction wanted to talk about how the trick generalizes — Ken Silverman's Build engine, Outcast's voxel landscape, the modern revival in games like *Teardown* (which uses true voxels and ray-marching on the GPU). The web-dev faction was mostly stunned that 40 lines of plain JS could produce something this visually convincing without a framework. Both reactions are correct. The algorithm is genuinely simple, and it generalizes — anywhere you have heightfield data and a top-down-ish viewpoint, it's a viable rendering path.
There's also a quiet performance lesson buried in the demo. Macke's JS version doesn't use `requestAnimationFrame` tricks, doesn't use OffscreenCanvas, doesn't use SIMD. It writes to an ImageData buffer one column at a time and `putImageData`s it. The fact that this is fast enough means the bottleneck in most browser graphics work isn't the JS engine — it's the abstraction tax of WebGL state management and shader compilation that small projects pay without recovering.
If you're rendering terrain — flight sims, drone visualizations, topo-map overlays, game prototypes, GIS tools — Voxel Space is the lowest-cost rendering path that exists, and it has been for 34 years. The break-even versus a triangle mesh is roughly: if your heightmap resolution exceeds your screen resolution and your camera stays above the terrain, columnar ray-cast wins on both performance and code complexity. Below that, meshes are fine.
The broader takeaway is about primitive selection, not nostalgia. When you reach for Three.js or Babylon or react-three-fiber to render a heightmap, you're paying for a triangle pipeline, GLSL toolchain, and scene graph you don't need. A 2D canvas and 40 lines of code may produce a better result with shorter load times and a smaller bundle. The same logic applies elsewhere: signed distance fields for UI shapes instead of SVG meshes, marching squares for contour lines instead of polygonal isobands, jump flood for Voronoi diagrams instead of Fortune's algorithm. Every one of these is a case where the canonical "modern" approach is the wrong primitive for the data.
For production use the practical gaps to be aware of: no shadows beyond what you bake into the color map, no transparent objects, no overhangs (it's 2.5D, not full 3D), and the camera has to stay above the surface or the front-to-back assumption breaks. Most modern revivals — like the [voxlap](https://github.com/Ericson2314/Voxlap) engine or Ken Silverman's continued experiments — fix the overhang limitation with full 3D voxel grids at the cost of memory and complexity. For pure terrain, the original 2.5D version is still the sweet spot.
The periodic resurfacing of Voxel Space on HN isn't a nostalgia loop — it's the industry rediscovering, every two years, that the rendering primitive should match the data. The current AI-coding moment is making this worse, not better: LLMs default to whatever pattern they saw most in training data, which for graphics means Three.js boilerplate and shader copypasta. The engineers who'll ship the next generation of unusually fast visualizations are the ones who can ignore the autocompleted answer and ask the older, harder question: what is the cheapest computation that produces this pixel? Kyle Freeman asked that question in 1992 with a 486 and no GPU. The answer he found is still on the Pareto frontier.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.