|
| ▲ | deng 4 days ago | parent | next [-] |
| I agree, text-to-mesh makes much more sense for 3D artist than for CAD. If I'd wanted to have all my parts in text, I'd just use OpenSCAD, writing this down in prose sounds horrible. |
| |
| ▲ | SOLAR_FIELDS 3 days ago | parent [-] | | And lo, OpenSCAD is great, but is basically unused in the professional world... mainly because textual representation of models amounting to anything more complex than basic 3d shapes slapped together is difficult to achieve. You just can't do so many things in OpenSCAD that you need once you start doing professional designn | | |
| ▲ | pbronez 3 days ago | parent | next [-] | | I really appreciate OpenSCAD. It’s my go-to whenever I need to quickly define a basic shape to 3D print. Unfortunately I predictably hit a wall every time the complexity increases beyond the basics. The kernel is not robust to the stupid things I naively ask it to do. Often my code makes sense to me, but OpenSCAD refuses to create an object. Performance falls off a cliff. You can work around it by pausing previews and adjusting resolution, but that’s a big UX compromise. Still, I’ve tried a few other options and keep cycling back to OpenSCAD. The barrier to entry is very low, coding AI does a pretty good job, and there’s a decent ecosystem of community modules. | | |
| ▲ | SOLAR_FIELDS 2 days ago | parent [-] | | I also religiously use OpenSCAD for hobbyist stuff. For making some simple component/replacement stand or enclosure in my house, it's fantastic, don't need the full on parametric modeller for that, plus it's way more modular and extensible with code |
| |
| ▲ | wlesieutre 3 days ago | parent | prev [-] | | Great until you want to fillet or chamfer a complex edge, which professionals do all day long |
|
|
|
| ▲ | nickpinkston 4 days ago | parent | prev | next [-] |
| Though it's possible that generating the STEP first is easier to do, and that the plan could be backporting the feature tree using another method / model would then enable editing. Yes, it would seem post hoc feature tree requires the constraints that come from context in your head, but I could imagine that for most cases a "drafter's intuition" in AI may be sufficient, and you could build an interface to allow that to be mostly given up front and then through iterate post generation. I could imagine the stepwise approach may allow AI training to be more constrained / efficient that trying to do the whole thing in one go. |
|
| ▲ | Blackthorn 3 days ago | parent | prev | next [-] |
| Right. If you can express the constraints in text, why wouldn't you just draw it in a CAD program? |
|
| ▲ | bob1029 4 days ago | parent | prev [-] |
| This is also why SQL is cursed for LLMs. For queries that are actually valuable to the business we tend to have more constraints than these models can tolerate. By the time you get done explaining the meaning of your schema, you might have run out of context. Not that it would matter either way. I've never seen the attention mechanism lock onto more than ~10 hard constraints at a time. |
| |
| ▲ | sjfjfjsjsj 3 days ago | parent [-] | | Maybe you need to approach SQL the way code generation must be approached: don’t develop the whole statement or script at once, instead put together a plan and execute it step-by-step. Not everything must be done via LLMs themselves. You could use one or more tools to help generate parts of the query. You might be interested in this: https://www.pedronasc.com/articles/lessons-building-ai-data-... |
|
