Hacker News Reader

Comment by YuechenLi | Hacker News Reader

> Creating a b-rep kernel is a phenomenal amount of work

Well, I did it, took 6 months, and I think I'm ahead of Truck on that front since as far as I can tell Truck can still only do single edge fillets with Newton's method as their new fillet algorithm, whereas my kernel can do planar fillet chains fairly reliably.

I wish someone would wrap a frontend around it too considering I'm bad at designing UIs, and the architecture is too weird to put a conventional 3D CAD UI on it that I'm honestly hoping someone would throw their LLM at that task.

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

Also, sorry about the excessive self-promotion, but I think most people would be shouting from the mountaintop if they built a BREP geometry kernel from scratch solo too.

View on HN

Fascinating repo, thank you for making it!

I’m curious, what does this part mean?

“ Dangerous operations which may generate degenerate/sliver/zero-dimension geometries are instead blocked from materializing to 3D at a compiler level.”

How is that achieved, or rather what does that mean? What defines a sliver?

A sliver is basically a tiny degenerate geometry in the micro/nanometer scale that's basically the result of ambiguous surface intersections. Basically, if you put two say, cylindrical surfaces against each other in NURBS form, floating point noise would generate these microscopic geometric noises, and a lot of what commercial kernel does is they use what they call "healing" operations to clean up those bad microscopic geometries from the models they generate.

Aetheris took a very obvious approach that not many have seemed to tried before: It throws an error when an operation that may create ambiguous intersections and refuses to materialize bad geometry in the first place, which is not really possible to do with traditional NURBS based kernels, whereas Aetheris can because it is analytical first.

You see slivers in 2D spatial operations as well. Imagine that you have two parcels represented as polygons that don’t perfectly spatially intersect. If you perform a boolean operation to, say, compute the union of these two polygons into a single one, any microscopic difference between the two boundaries below a certain tolerance (like 0.001 square meters) will manifest itself as tiny gaps and slivers. Most GIS engines will merge the two polygons appropriately beyond that tolerance (this is a way simpler problem in 2D space!) but if the data is bad enough you’ll definitely see it.

While this is technically correct behavior, users will interpret that as your software not being able to do something - or as a bug (because it works on one drawing but not another).

Well, this is more similar to a linter/borrow checker than anything else, because if you catch errors at compile time, the bad geometry doesn't persist in the STEP artifact that's being generated, so analogous to the philosophy of Rust vs C++ really.

The current design is meant to be import tolerant but export strict, it imported most STEP file I throw at it fine after a bunch of fixes, but I don't really have a big enough sample corpus know for sure how much real world STEP file it can handle.

Thanks for the explanation, appreciate it!

Sorry for asking for definitions - since Aethris is such a different architecture, I want to make sure we’re using the same language.

When you say “models they generate” do you mean the the nurbs representation, or the tessellated geometry for rendering?

On a related topic how does Aetheris perform when defining a screw thread? Or a nut thread?

Aetheris generates STEP AP242 BREP directly, the tessellated mesh generated is only used for display (although currently, I've switched to a WebGPU based SDF representation so the surfaces can be smooth). One of the key differences in the architecture Aetheris doesn't export rational b-splines outside of debug or STEP passthrough and instead tries to recover and export analytical and non-rational splines instead.

On screw thread, if you mean by "how do you make a screw thread in Aetheris", you can check out the actual code for a threaded bolt I built for a showcase here with the JSON like DSL called Firmament:

https://github.com/yuechen-li-dev/Aetheris/blob/master/fixtu...

So, the high-level surface language of defining a screw thread is basically a struct/record that looks like:

    Thread MainThread {
        Surface: face(Bolt.Shank)
        MajorDiameter: 8mm
        Pitch: 1.25mm
        Length: 47.5mm
        StartOffset: 1.5mm
        }

Which is why I said that it's really hard to think of an editor UI for Aetheris that's not just a text editor or a ComfyUI like graph visual programming or something.

If you mean compile speed wise, not great right now, it wasn't that much of an issue when running on RyuJIT natively since it's still acceptable, but currently WASM cold compile speed for a moderately sized assembly is around 4-5 minutes so there is a lot more work to be done before I'm ready to put it on a cloud server.

I'm not trying to tear this down but if your geometry kernel can't be compiled into a .dll or .so file and then included inside the CAD program I'm not sure people will be interested in running your software.

I'm not critiquing the language choice, it's just that I basically have a thing that is big on dynamic linking and I would rather farm out the geometry kernel to someone else and at this rate I'm kind of forced to port yours over so it works for me and I think that would be a bad outcome for both of us.

Also your .firmament files are good because I'm working on something like that too.

> if they built a BREP geometry kernel from scratch solo too.

But you didn't, Claude did. Your commits display it.

A lay person doesn't have the skill-set to tell Claude how to do something like this. Experts extract much more value out of a domain than amateurs.

Would you tell Terrance Tao that they didn't produce [this conversation](https://chatgpt.com/share/6a5fdc7a-d6f8-83e8-bbea-8deb42cfed...), the model did?

Yes? It's a back and forth discussion, where the model's output (that is much more pluridisciplinary than Terrance will ever be and therefore benefits from the common knowledge of not just an entire field, but thousands of fields over thousands of cultures) actively drives his responses and verifications. Literally, the entire set of messages is "you said X. Does that therefore entail Y in what you said ?". Terrance being an expert knows how to drive the conversation in angles which he explored, but it remains that the bulk of the work is done by Claude.

If I keep asking clarifying questions to Albert Einstein, that doesn't make me the inventor of relativistic physics, no matter how much I know about the subject.

I'm not contradicting OP's expertise on the subject: they seem to at the very least know what they're talking about. But saying "I" did this when all you did is prompt the funny slot machine and approximately none of the code is reviewed (6 commits per day, each being 50+ files on average is not something you have reviewed or understood.) is lying to others and to yourself.

I couldn't build this even with Claude Mythos, I have no freaking clue what this stuff is, and I'm a full time software developer that understands performance optimization and even has used SketchUp a lot.

I'm telling you, I simply couldn't do it. Unless the prompt is "copy every single feature in AutoDesk Fusion 360" and sit back, and even then, I wouldn't even know where to start with testing it, knowing whether it works properly, and whether the various tools are useful, performant, etc.

Let's not assume that the code is the most important part, it's important, but domain knowledge is still very important.

Yes for some reason people are really bad at being honest. For that reason all my AGENT.MD files instruct the AI to write a disclaimer at the end what kind of involvement I had and how much the AI did.

Most of the documents have something like this at the bottom:

"Primarily written by AI based on human design discussions."

And I don't feel ashamed to let the AI do the writing because the output is reasonably good because I let it generate a TOC then I rework the TOC by hand, then for each TOC chapter I just have a discussion giving it the information and then I let it generate the text. I didn't even directly tell it what to write about. Instead there is a loose discussion that contains all the needed information to convey.

So it is really silly to then slap your own name on the final end product and claim you did all of it, even if it took weeks of prompting to finish the document.

Reply on news.ycombinator.com