Comment by mediaman

Comment by mediaman a day ago

6 replies

View on Hacker News

The problem is that this isn't very useful except for the very earliest ideation stages of industrial design, which hardly need CAD anyway.

Most parts need to fit with something else, usually some set of components. Then there are considerations around draft, moldability, size of core pins, sliders, direction of ejection, wall thickness, coring out, radii, ribs for stiffness, tolerances...

LLMs seem far off from being the right answer here. There is, however, lots to make more efficient. Maybe you could tokenize breps in some useful way and see if transformers could become competent speaking in brep tokens? It's hand-wavy but maybe there's something there.

Mechanical engineers do not try to explain models to each other in English. They gather around Solidworks or send pictures to each other. It is incredibly hard to explain a model in English, and I don't see how a traditional LLM would be any better.

esperent a day ago

You may or may not be right, but your arguments sound like echos of what software developers were saying four or five years ago. And four or five years ago, they were right.

Don't dismiss an AI tool just because the first iterations aren't useful, it'll be iterated on faster than you can believe possible.

Reply View 5 replies
  • mediaman 9 hours ago

    I've created (small, toy) transformers and also modeled injection molded parts in Solidworks.

    There is a really big difference. It's obvious how programming languages can use tokens for an attention mechanism, which gives them excellent ability to have parallelized performance (versus RNNs, the prior way of relating tokens) with much broader ability to maintain coherence.

    I don't know the parallel with brep. What are the tokens here? It's a fundamental architectural question.

    But unlike four or five years ago for programming, when the attention mechanism was clear with transformers and the answer was, basically, just "scale it up", we don't even really know where to begin here. So assuming some magic is going to happen is optimistic.

    It'd be exciting if we could figure it out. Maybe the answer is that we do away with brep and all tree based systems entirely (though I'm a little unclear how we maintain the mathematical precision of brep, especially with curves, which is necessary for machining -- your machinist is going to throw you out if you start giving them meshes, at least for precision work that has anything with a radius).

    Reply View 0 replies
  • littlestymaar a day ago

    While LLMs are a useful tool for software development, if you try asking them the software equivalent of “Create a plastic enclosure sized to go under a desk, ok add a usb receptacle opening, ok add flanges with standard screw holes” you'll end up with the equivalent of “No the other side. No, not like that, at the bottom. Now make it 10mm from the other hole. No the other hole. No, up not sideways. Wait, which way is up? Never mind, I'll do it myself” a lot.

    What works is asking them to implement micro feature that you will specify well enough at first try, not to ask them writing the entire piece of software from top to bottom. The tech is clearly not there yet for the latter.

    The main difference between Code and CAD is that code is language you're writing to the machine to execute already, so it's pretty natural to just use a more abstract/natural language to ask it instead of the formal one of code, whereas CAD is a visual, almost physical task, and it's more pleasant to do a task than describe it in depth with words.

    Reply View 3 replies
    • esperent 21 hours ago

      > Create a plastic enclosure sized to go under a desk, ok add a usb receptacle opening, ok add flanges with standard screw holes

      With vague specifications like these, you'd get garbage from a human too.

      What works for software, and I suspect for other technical fields like CAD too, is to treat it like a junior developer who has an extreme breadth of knowledge but not much depth. You will need to take care to clearly specify your requirements.

      Reply View 2 replies
      • littlestymaar 19 hours ago

        > With vague specifications like these, you'd get garbage from a human too.

        You'll never have better input than this at the beginning of any project from the person that brings the use-case. That's a full job to help them define the needs more accurately. And if you always work with clear specifications it's just because there's someone in front of you that has helped write the spec starting from the loose business requirement.

        > You will need to take care to clearly specify your requirements

        Yes, but as I discussed above, for such tasks it's going to be very frustrating and less efficient than doing things by yourself. The only reason why you'd accept to go through this kind of effort for an intern is that because you expect him to learn and become autonomous at some point. With current tech, an LLM will forever remain as clueless as it started.

        Reply View 1 reply
        • esperent 19 hours ago

          > You'll never have better input than this at the beginning of the project from the person that brings the use-case

          That's as may be, but again, it's not much different to being a software developer.

          Someone might ask you to create a website for their business. It's your job, as the expert, to use the available tools - including AI - to turn their requirements into working code. They might say "put a button for the shopping cart into the top right". It's then your job, as as the technical expert, to get that done. Even the laziest of devs wouldn't expect to just copy/paste that request into a AI tool and get a working result.

          It takes time to learn to use these tools.

          When I'm using AI to help me write code, depending on the complexity of what I'm working on, I generally write something very similar to what I'd write if I was asking other developers for help (although I can be much terser). I must specify the requirements very clearly and in technical language.

          Usually I keep a basic prompt for every project that outlines the technical details, the project requirements, the tools and libraries being used, and so on. It's exactly the same information I'd need to document for another human working on the project (or for myself a year later) so there's no wasted work.

          Reply View 0 replies