Hacker News new | ask | show | jobs
by vincent-uden 30 days ago
Seeing as I'm attempting to build my own CAD program in Rust I checked out the hosted website. I'm not really sure what is supposed to be working and what isn't.

I can't help but to be skeptical of one person writing ~115k LOC in 4 months which is just the Rust crates, nevermind the frontend (which is another 100k LOC!!!).

I'm curious why you decided to go with "eager" tessellation. Creating a circle immediately results in a bunch of lines which resemble a circle but would fail under tangency constraints quickly. Is this a current limitation or part of the strategy for the kernel?

3 comments

As someone also working on CAD in their spare time, also tried the hosted app. I get the feeling that this is made by someone who has never opened a (professional) CAD app at all. It feels like a mix between a tool like blender and CSG-style CAD, but even all of that doesn't seem to work. Maybe this is the proof that vibe coding does not work, at least not for this kind of application.

In my own project I use LLMs very sparingly and hesitantly, but made the observation that they are not very useful on the hard parts of CAD. I expect this is because of a lack of training material. Most professional CAD applications are proprietary and books on the topic are usually sparse on implementation details. The non-BRep CAD applications such as OpenSCAD and family are probably overrepresented in the training data.

This might also explain why people's experiences with LLMs are very varied. If you stay in the happy path of CRUD web development and stuff all is nice and well, but if you start to veer off this path you get more and more challenged.

Thanks for trying. What doesn't work? What did you try? If you're specific I'm happy to fix it.
Tessellation is simply required to render the IR. The viewport is guiding the cursor to the vertices (perhaps a bug) but the engine is not forcing their use. I also built a ray caster :)

What wasn't working? I would love real feedback -

> I'm curious why you decided to go with "eager" tessellation. Creating a circle immediately results in a bunch of lines which resemble a circle but would fail under tangency constraints quickly. Is this a current limitation or part of the strategy for the kernel?

I’ve seen several vibe coded attempts at a geometric kernel (including several of my own) and this happens every time.

Vibe coding a geometric kernel is practically impossible because sooner or later* the LLM inevitably takes the tessellation shortcut and if you don’t catch it, the codebase is completely compromised. At the end of the day, there isn’t enough training data in architecture or algorithms (opencascade solvespace and truck being the only real examples, all significantly worse than commercial kernels like Parasolid or ACIS).

* usually as soon as you ask it to do anything non-trivial. If you’re lucky you’ll get a naive Newton marching algorithm on analytical bodies, which is slightly better but has the same problem with degenerate and pathological cases (coincidence, tangents, parallels)

Can you give specific examples?