Show HN: Laser-Tracer, programmable virtual volumetric vector display

1 westoncb 1 6/12/2025, 9:28:16 PM westoncb.github.io ↗
This was an idea I had 7yrs ago that I recently decided to go ahead and build since by working with LLMs (mostly o3 and Gemini 2.5 pro) it seemed doable in reasonable time.

The original motivation was partly aesthetic, but mostly that this was the ideal "language" for me to express arbitrary 3d forms through. I wanted something with zero boilerplate that would be a natural fit for algorithmic expression. For me, writing programs that say how to move a "pen" around in 3d space was more intuitive than e.g. writing pixel shaders.

The format is inspired by Logo/Turtle, and somewhat mimics how a 3d printer works in that Laser-Tracer programs are G-Code like: the fundamental operation is depositing points; from there we get 'traces' specified by either relative (pen.traceBy(x,y,z)) or absolute destinations (pen.traceTo(x,y,z)). And built on top of traces are 'macros' for doing things like drawing text or sweeping polygons.

When deposits are made by the 'pen,' it emits additively blended particles that decay over time mimicking classic phosphor vector displays. That's the mental model: your program is controlling a beam that energizes elements of a volumetric display that it scans around at 60hz.

A note on performance: this is not highly optimized (and will heat up your device, especially phones!), and does some pretty dumb things from a performance perspective. For the time I had my main goal was validating whether this would even be interesting in principle, so priority was given to making the API easy to express vs raw performance. That said: I think it's very optimizable if interest does exist.

- Intro video: https://www.youtube.com/watch?v=f7mokiVnEbk

- Sandbox app: https://westoncb.github.io/laser-tracer/

- NPM lib: https://npmjs.com/package/@laser-tracer/core

- Monorepo (lib + sandbox app): https://github.com/westoncb/laser-tracer

Comments (1)

westoncb · 22h ago
I think the community here would find the methodology behind building this of interest. How all-encompassing "vibe coding" has come to be for "developing software with LLMs" is unfortunate imo. I have experimented with vibe-coding too, but it's a very different thing from the process used here. This tweet from Andrej Karpathy is the best description of how I approach development with LLMs: https://x.com/karpathy/status/1915581920022585597