Another sprint in the virtual workshop and the browser-based toolpath generator keeps getting sharper. What started as a proof-of-concept—rendering cutter sweeps in THREE.js—now feels like a pocket-CAM you can open in a tab. The latest drop trades raw G-code import for something a little smarter: you sketch or paste a cloud of points, choose an offset distance, and the engine morphs that outline into a tight, back-and-forth tool dance complete with automatic retracts. No post-processor, no syntax errors—just pure geometry turned into motion.

Milling-bit animations. The spindle finally spins on screen! Each virtual tool carries its own loop keyed to your feed-slider, so a 12 000 RPM rougher whirls visibly faster than a 2 000 RPM finisher. It’s more than eye-candy: the motion helps spot mismatched step-overs at a glance—if the cutter’s screaming yet progress crawls, you know the chip load is off.

Parametric feed rate. Instead of parsing an F-word from G-code, a single slider now drives the linear feed for every segment the engine creates. During playback the toolpath hue shifts from cool blues at gentle feeds to warm ambers when you start pushing the limits. One glance tells you if your brass rough pass is baby-slow or your carbide micro-bit is about to cry.

Plug-and-play geometry. A refactor of the component library means adding new cutter shapes or diameters is basically a one-liner. Drop a JSON snippet—{ "type": "ballEnd", "diameter": 0.12 }—and the scene pulls in a pre-scaled STL, mounts it in the spindle, and wraps collision boundaries around the business end. Ideal when you’re juggling watch-scale tooling: need a 0.07 mm carbide ball nose? Pop it in, hit save, done.

Scroll-through collision hunt. The timeline now sports a buttery scrollbar that lets you scrub every move frame-by-frame. Potential crashes flash crimson, the camera snaps to the offending vertex, and the point-cloud offset updates live so you can widen clearances without playing detective. On a 4-axis barrel-arbor job—thousands of tiny A-rotations—that feature already saved me hours of forehead-denting.

Shape morphing instead of G-code. Here’s the big architectural twist. Rather than feeding the simulator raw NC code, you define intent: points that describe the part’s silhouette or an engraving loop. The engine expands that outline by your chosen distance, zigzags across the interior with an automatic step-over, and inserts retract hops at the boundaries. It then feeds those moves straight into the animation layer. Less control for now, but zero chance of a missing G00 sending the spindle through the table. Baby steps, but safe ones.

Tidy React hooks. Under the hood, React keeps state crisp while THREE.js handles shaders and meshes. I tossed out the imperative spaghetti, replaced it with functional hooks, and tidied context so the codebase finally feels as clean as the renders. Next stop: physics shaders so the chip-fling direction changes when the spindle tilts. Because why not? 🛠️

Explore the interactive toolpath playground →