YuechenLi

If I were to design it to be manufactured in the states, I would probably go for a simple wooden handle with off the shelf wire mesh instead of chainmail, and the fastening would just be mechanical fit between wrapped wire and handle with no additional fastener, which should massively improve price and manufacturability.

The argument is that Unitree's assembly process is currently very manual because there is no incentive to automate, which is because labor cost isn't the bottleneck here, where in the US labor cost are much higher, therefore the US will have incentive to automate more. Those are reasonable so far, until you try to use that as a conclusion that this is why the West will win?

First of all, what does he think the other 92% of the cost of manufacturing is? A small portion of that is materials and electricity, but the biggest part of the remaining cost is assembly tooling/fixtures for the assembly line, and a fully automated assembly line is much, much more expensive compared to a semi-automated or manual production line.

In other words: it's not that Unitree couldn't build fully automated assembly lines if they wanted to, but spending tens of millions of dollars fully automated assembly line that takes up floor space and requires even more labor for manual maintenance for a product that is only being produced by the hundreds to thousands in quantity every month rather than millions simply does not make economic sense to begin with.

Second, why is he assuming that a fully automated assembly line will be cheaper to build in the US than in China, especially since he toured a factory with fully automated assembly lines at BYD in China immediately after? And sure, I would absolutely argue that American software engineering is more efficient than Chinese when looked at as a whole, but the cost of programming an assembly line is a minor portion of the cost compared to actually getting the assembly line fixtures and tooling built.

Third, his cost estimate is way off if he thinks you can get the same product manufactured in the US for only 50% more. From my own anecdotal experience, a more realistic cost for US manufacturing for pretty much anything is minimum 300% to 1000% more expensive if you are to make the in the US, and the lack of a mature parts supply chain in the US is honestly a bigger issue than worker wage.

I don't even understand how people can spend thousands of dollars a month on LLM tokens since I've accomplished multiple major projects with this setup. In general, Claude's better at frontend and debug and Codex is better at feature implementation and research from what I've found, which is why I have both.

2. No. GPT 6.1 Sol is very token efficient that I pretty much never run out before the end of the week anyways.

3. Default Codex/Claude app. I only use VS/VSCode to hand-edit/git sync things when needed.

4. No. Swarm is a waste of token imo, and a single good human in the loop beats any automated orchestration tool.

5. I find it unnecessary.

Until now.

I've spent the last 7 months working on my Aetheris geometry kernel because I wanted to have a CAD software that uses STEP, specifically, AP242, as its native format instead of just an exchange format. Very happy to say that I've succeeded, as you can add dimensions and GD&T to STEP 203/214 files and convert them to 242 directly.

Directly editing an existing STEP file is still limited to moving through holes around though, but there is no reason why more advanced editing couldn't be done.

So, integration isn't really the difficult part if everybody generates files in the same format.

Bitter lesson, etc, and training an entire VLM to prevent text overlap seems a bit much, especially since GPT 6.* /Claude 5.*'s vision are good enough that it rarely ever happens for me, and if they do make a mistake, it's generally a 5 minute fix?

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

One of my goals when I built the kernel is I want to make building a pro grade CAD software as easy as wrapping a web frontend around the Aetheris libraries. It's still very much an aspirational goal though.

For your application in IFC, the architecture difference between OpenCascade and SMLib doesn't matter as much, but a geometric modeling kernel for mechanical CAD has much stricter requirements in terms of geometric correctness, which is the reason that Rhino, despite being BRep and widely used in architecture, isn't used very much in mechanical CAD at all.

SolveSpace is still fairly limited on what it can do in terms of features such as fillet/chamfers, so it's not really suitable for pro work right now

For projects like SolidCraft, the SMLib kernel they are currently porting to Rust from Nvidia is currently about a decade behind OpenCascade, nevermind Parasolid/ACIS as they are still converting all geometry to NURBS instead of preserving analytical geometry, which means that their initial development is easier but it creates a near infinite amount of edge cases once they start going heavy into booleans and fillet/chamfers.

(I'd like to think my own kernel is little bit ahead of you architecturally though.)

How's the Boolean and fillet/chamfer robustness currently in Popkern?

Also, would you like to collaborate and compare notes? It's a lot of work trying to maintain something like this solo.

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

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

Already made the geometry kernel. So far, nobody has offered me even like 20 dollars to license it yet, nevermind millions of dollars.

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
        }

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.

However, OpenCascade being C++ instead of Rust is the least of its problems, the main issue is OCCT's boolean/blend engines aren't really as robust as the commercial kernels, and handling arbitrary 3D boolean edge cases one by one correctly is one of the main difficulties of a geometry kernel.

Very interested in SolveSpace's progress on this 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.

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.

Just because you can throw tens of thousands of dollars at frontier LLMs doesn't mean what they write would be good, you still need to have some oversight for their 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.

The bigger issue is that OpenCascade is error tolerant to a fault, which allows it to import a lot more legacy geometries, but it also means that it silently exports a lot more bad geometries much more often than commercial kernels

So, there's a reason why commercial solutions don't really use OpenCascade over ACIS/Parasolid for authoring.

Here're are some SIGGRAPH 2026 papers attempting BREP recovery, if you are interested. None of their automated approaches seem to work reliably, and they can only recover generic NURBS instead of analytical geometries like circles/cones/torii, etc.

https://github.com/AutodeskAILab/DualBrep https://github.com/yilinliu77/Brepler https://rilpraa0110.github.io/Img2CADSeq/