The geometry pipeline was stanky for a while.
What I needed sounded simple enough: select a real mountain, extract usable terrain, shape it into something I could fabricate, and iterate quickly enough to compare ideas instead of getting lost in tooling churn. In practice this meant GIS inputs, notebook environments, CAD viewers, mesh processing, and a lot of dependency weirdness all trying to occupy the same room.
This is the point in the project where the software starts to look substantial from the outside. That can make it seem like the software became the project. I do not think that is what happened. I think this was the price of admission for making the mountain part tunable.
Before wax-cam really settles in, the Dropbox notes show an older workflow:
That path worked well enough to prove the basic idea, but it was awkward.
There were too many disconnected steps, too much manual translation between tools, and too much room for the whole thing to become a one-off science fair demo instead of a usable process.
The problem was not just “get terrain data.” The problem was getting terrain data into a form that stayed editable and reproducible while I kept changing the downstream object.
That means the pipeline had to support at least these jobs:
That last one is where a lot of projects get you.
A pipeline can technically work and still be miserable to iterate on.
The notes and repos line up pretty tightly here.
On the notes side, late April 2025 is basically a packaging sprint diary:
jupyenv with a CAD environmentjupyter-cadquerytouchterrainpymeshfast-simplificationOn the repo side, jupyter-gis shows the same burst:
1b1149e (2025-04-28 15:01 -07:00) — WIP: Wonky package BS19c0238 (2025-04-28 19:05 -07:00) — building cad-viewer-widget9f1a60a (2025-04-28 19:37 -07:00) — building jupyter-cadquery orjson ocp-tessellate ocp-vscode31cc272 (2025-04-29 20:07 -07:00) — Working touchterrain0fee4ab (2025-04-30 21:18 -07:00) — Forking touchterrain to fix geotiff bug3c319aa (2025-05-02 11:11 -07:00) — Successful build and import of pymeshThis is one of those periods where the commit log looks kind of absurd until you know what the surrounding problem was.
Yes, from the outside it is a bunch of package wrangling. But if the goal is a terrain-derived object I can keep refining, then getting the environment into a reproducible state is not secondary work. It is the work.
I kept tripping over the same class of problem: each piece of the stack was reasonable on its own, but the combined stack was awkward.
I wanted:
That means frontend widget code, Python packaging, geometry libraries, scientific libraries, and enough CAD support to make the results visible.
Unfortunately, these systems do not care about my vibe.
One of the more honest lines preserved in Dropbox was:
I just wasted ~8 hours trying to package ipyleaflet when I should have just used touchterrain.
That is the genre of problem this phase is made out of. A lot of it is not glamorous. It is just figuring out which abstraction is worth carrying forward and which one is a side quest wearing a fake mustache.
The big shift was from disconnected one-off tooling toward a more coherent notebook and library workflow.
By the time wax-cam gets version-controlled on 2025-04-29, I am no longer just poking at terrain data. I am starting to build a system around it.
That includes:
A line from the notes catches the mental model pretty well:
Each cell is either a decision or an operation.
That is not just notebook philosophy. It is a clue about how I was trying to make the pipeline reason-about-able instead of magical.
This phase made a few later things possible:
wax-cam.Most importantly, I could start treating terrain-derived form as a thing I could revise instead of a precious artifact I had to avoid touching.
That is a huge difference.
If the geometry is precious, you make one thing and tiptoe around it. If the geometry is iterable, now you can design.
This phase definitely increased technical surface area.
I was now carrying:
That is real overhead. If the project had stopped at this point, I think the software would have looked overbuilt.
The only reason it does not feel overbuilt in hindsight is that the next problems turned out to need exactly this kind of flexibility.
Once I had a workable path from mountains into geometry, I ran into the next very normal and totally chill problem:
the physical process started arguing back.
Aluminum molds were not scaling well enough, silicone was weird, pours were messy, and it turned out the real adversary was not just terrain data. It was molds and wax.