@baigy Huh. Interesting. I was just doing the final clean-up for something convergent to this research that I had been working on for the past few months. I think I arrived at your thesis (code first semantics from a different direction in CAD, so I think it'd be interesting for us to compare notes.

Have you formalized this into a compiler infrastructure yet? I think Python on its own would be too slow to build complex parts, especially since for triangle mesh, accuracy inversely correlates to performance.

Vision is generally not the most reliable form of checks for LLMs, even on GPT 5.6 Sol, so a recommendation I would have is to instead emit JSON or CSV of the color/topology data for the LLM to inspect directly, and this is the instance where ray query for topology checking will greatly improve accuracy in general. SDFs are a bit more complicated right now, I have a full implementation designed for 3D analysis

My own experimental compiler generated mesh suffers from the spiderweb effect: it's very polygon efficient but not very friendly towards UV unwrapping in general, and I'm struggling to find the correct approach for that. If you have any suggestions, I'd love if you can point me towards the correct approach.

Definitely very interesting though.

▲

baigy 3 hours ago | parent [-]

Would love to compare notes. It's compiler-shaped rn. The generated code is the source and Blender is the current build target. Python directs Blender's native geometry operations only. I also already generate UVs from the coded model before GLB export, while its part structure is still available, which helps avoid recovering everything from one fused spiderweb mesh. Visual checks aren’t the only option either. Having the code gives us direct structural checks too. Btw curious to see your SDF approach.

▲

YuechenLi 2 hours ago | parent [-]

https://github.com/yuechen-li-dev/Aetheris

So, yeah, mine is full geometry kernel that was made for CAD. I'll do a full write-up on Show HN later as there is just way too much stuff to cover for the project. The gist of it is that it is a compiler for 3D models that takes the high-level language, which I named Firmament, and lowers it to STEP AP242 mapped BRep in C#.

So, for SDF, it was originally conceived as a method to solve the general case 3D BRep boolean problem through methodology similar to libfive/Fidget in FRep directly. The problem is that we immediately ran into the same wall that everybody else did attempting to recover mesh/BRep structure from the SDF blob, spent like a week doing BRep patches for it, before we ultimately concluded that it was not really possible to do as FRep is a lower representation than either BRep or mesh. It's probably more useful for continuum physics/fluid dynamics in the future than it is for CAD/solid mechanics/3D modeling, but currently the SDF pipeline is just kinda sitting there as dead code and not being used much.

https://github.com/yuechen-li-dev/Aetheris/tree/master/Aethe...

	▲	baigy 2 hours ago \| parent [-]
		This is super interesting. Especially the high-level language > STEP/BRep lowering. Tt feels very complementary to the mesh path we're exploring and potentially the right backend when exact solids matter. I feel your SDF conclusion is useful too. It's tempting to treat it as a universal intermediate, then discover you've lost the structure you need later. I'll dig into the repos and would compare notes afterwards.