Ideas
A product is more than its geometry
I started building my own geometry kernel because I wanted to generate configurable products faster and more simply in the browser.
A worktable as a kernel programme: sheet metal, multiplex and box tube.
Sheet metal, profiles, cut-outs, mitres. Not a full CAD replacement, but a light technical base for configurators. The technical playground is at kernel.kubuz.net.
While building, the more interesting question shifted. Not how I make even more geometry, but how I describe the product so that geometry is only one of the possible outputs.
Why write a kernel?
For many configurators you do not need a full CAD system. You want to describe a product variant, generate geometry quickly, let the user look, and then keep usable technical data.
A classic CAD kernel can do much more, but also brings a lot of complexity. My experiment therefore starts from a smaller set close to workshop products: plates, profiles, holes, cut-outs, connections and assemblies.
JSON as a boundary
I want a product to be built from a clear, machine-readable description. Not because JSON itself is special, but because it forms a simple boundary between product knowledge and the systems that do something with it.
A configurator can write it. A viewer can read it. An agent can adjust it. A manufacturing layer can use the same information to make output. That only works if the meaning of that data is sharp enough.
The kernel itself has no expressions. When you change length, width or height of the worktable above, I rewrite the poses from those primary sizes. That is deliberate. The geometry engine builds what you give it. What the product means sits outside it.
From geometry to semantics
Geometry tells you where a hole sits. It does not tell you why that hole is there, which part it is coupled to, which option activated it, or which production rule applies.
That is why I am exploring a semantic layer above the geometry kernel. Concepts such as Parameter, Component, Profile, Plate, Material, Constraint and Relationship get a fixed meaning there. The kernel then is not the product model itself, but one engine that can make geometry from that model.
That difference is why I am doing this research.
Ongoing research
This is still research. I use the kernel to build models, find limits, and test which abstractions still hold when products become more complex.
The worktable above is one of those tests: a folded sheet top, multiplex in the frame, box tube and one or two shelves. No mates. The poses come from a few sizes. JSON, more examples and the editor live in the kernel playground.
Some ideas will disappear. Others will probably move into configurators and engineering tools. I want to show that process here as well.