Live data from Hacker News

Build123d: A Python CAD programming library

github.com

21–30 of 67 posts

Re: Build123d: A Python CAD programming library

#21
post #12

Earlier quoted context omitted.

The fun thing is that onshape itself has a very thin kernel. Most of what you see as built in features are actually featurescript based. Onshape provides the source code for their built in feature set as a reference. https://cad.onshape.com/documents/12312312345abcabcabcdeff/w... You do need an account login ( free ) to view it.

Kernel here is ambiguous.. I get what you mean, but parasolid is usually the thing described as the cad kernel.

You are right but I also kind of did mean it that way. I believe that Parasolid is at heart of Onshape, the true kernel. Then on top of that is a compatibility layer describing the set of low level operations available to featurescript. I'm sure that not everything in Parasolid is available to featurescript and perhaps there are some things added that are not in Parasolid. Featurescript also contains the selector/query logic for programatically picking geometry. Whether that comes from Parasolid I am not sure. I haven't worked with featurescript for a number of years now but when I did I was amazed. I managed to make an operation for taking any solid from the UI and generating customized interlocking ribbing. The idea was hollow surfboard design. It worked and I left it at that. Never built the surfboard!

However the downside with featurescript and I think a big mistake on their part was to use a custom language rather than python or javascript. Featurescript is almost javascript but with some syntax changes and magic DSL's. You are also forced to use the inbuilt editor which is horrible and if you have burned VIM keybinding into your nerve endings, going back to non modal editing is horrible.

Also the discovery of featurescript modules in the community has terrible UX. It's super weird that they have such a great system but finding useful extensions is horrible.

Re: Build123d: A Python CAD programming library

#22
post #16
post #2

These types of CAD scripting tools are great but always try to position themselves as an “alternative” to GUI-driven CAD, whereas in reality they are complementary. OnShape got it right with FeatureScript ( https://cad.onshape.com/FsDoc/ ), which provides a very similar experience to Build123d at the scripting level. However, the insight that OnShape got right is that these scripts automatically become available as p…

I think most GUI CADs have some kind of API like this. In FreeCAD it's Python. In Solidworks, it's VBA or C#. I don't think any are particularly well documented or supported by tutorials.

https://cad.onshape.com/FsDoc/

Re: Build123d: A Python CAD programming library

#23
post #5
post #3

Despite being aware of its existence, I stuck with OpenSCAD out of habit. Only last week did I read through the documentation, and feel strongly that I've been missing out… it seems to solve all of my gripes with OpenSCAD. I'm excited to try it out!

I've been wanting to get into OpenScad. Wondering what you've identified as an issue. I dabbled a little and I think I remember wishing it was more object oriented to make it a bit easier to make reusable adjustable pieces and I had found a python library that does openscad conversions; Wondering what gripes it solves for you.

Off the top of my head, in no particular order:

As the sibling comment mentioned, the classic problem of chamfer/fillet. Inconvenient in OpenSCAD, trivial in build123d.

There are various features I've missed: polylines with rounded corners, extruding along a path, and more I can't recall.

As you mention: code organization. I didn't have the need early on, but over time I often wanted to do add custom things, for example my own hack of an implementation for extruding along a path. And passing data around is just painful and ugly... since you can't read any of your input shapes, you have to pass around all data explicitly -- alongside or instead of shapes -- and then only actually render them in the latest stage. Generally I found it hard to make reusable code, and generally it has to make many assumptions about the calling code.

The OpenSCAD editor is one big IDE, and it's not a great one. My workflow was to keep VSCodium on one side and OpenSCAD on the other, just to use a better editor. I actually thought to myself that a good project direction would be to make it more modular and focus on the unique parts rather than the IDE. And that's indeed how build123d does it: primary repo only handles the rendering, and then suggest compatible viewers, with one shipped as a VS Code extension being the primary suggestion.

Speaking of workflow, a huge difference is local coordinate systems: lacked in OpenSCAD and encouraged in build123d. It fits my brain really well. I just made a shape, now I want to make some holes in it. Previously I've often had to think about what global coordinates to put some volume, but now I'll just select that face and work with those local 2D coordinates.

And another workflow annoyance before is when I'm designing something to be printed in separate parts. First, meticulously fit things together in the global coordinate system so that I can see them in the assembled state. Then to allow printing, also conditionally move all parts to manually specified other coordinates. With build123d one can define the parts separately, place joints in desired locations, and have them automatically snap together for the assembled view. It looks useful for integrating third-party parts as well.

Minor thing, but I'm always slightly annoyed by the fact that a rectangle is called a square and a slab/box called a cube in OpenSCAD...

Oh, and it's often useful to use polar coordinates. More passing around custom data and manually calling your custom conversion function whenever passing to OpenSCAD. build123d has first-party suitable objects for it.

OpenSCAD development seems fairly dormant as well. Latest stable release was five (!) years ago, but by reading around you see that you're supposed to use the nightly version because it's superior. Not very friendly for newcomers. By contrast, build123d seems very active.

I should stop now, because this already got pretty long. As you can see, I had some bottled up though -- thanks for letting me vent!

Re: Build123d: A Python CAD programming library

#24
Why do these tools never have the equivalent of sketch contraints in FreeCAD? That's how I build my models and it avoids a lot of math.

I'd really like a "CAD as code" tool that's basically the FreeCAD Part Design workflow but with code. I know FreeCAD has a python interface but it's far from developer friendly.

Re: Build123d: A Python CAD programming library

#25

Why do these tools never have the equivalent of sketch contraints in FreeCAD? That's how I build my models and it avoids a lot of math. I'd really like a "CAD as code" tool that's basically the FreeCAD Part Design workflow but with code. I know FreeCAD has a python interface but it's far from developer friendly.

I'm working on one with features you mentioned, with the main goal to make the workflow similar to mainstream CAD. Will release the first dev version in less than a month.

Re: Build123d: A Python CAD programming library

#26

Why do these tools never have the equivalent of sketch contraints in FreeCAD? That's how I build my models and it avoids a lot of math. I'd really like a "CAD as code" tool that's basically the FreeCAD Part Design workflow but with code. I know FreeCAD has a python interface but it's far from developer friendly.

build123d has constraints for avoiding math. I'm not familiar with the sketch constraints in FreeCAD though, how do they compare?

https://build123d.readthedocs.io/en/latest/tutorial_constrai...

Re: Build123d: A Python CAD programming library

#27

Why do these tools never have the equivalent of sketch contraints in FreeCAD? That's how I build my models and it avoids a lot of math. I'd really like a "CAD as code" tool that's basically the FreeCAD Part Design workflow but with code. I know FreeCAD has a python interface but it's far from developer friendly.

The reality is build123d is a fairly thin layer over the OCCT kernel with some pythonic affordances. I'm not sure OCCT has a robust constraint solver, so there is little development there. FreeCAD on the other hand (besides being significantly more mature) is also build on OCCT, but also does a lot on top of the kernel to make it more featured and stable.

Re: Build123d: A Python CAD programming library

#28
post #4

I like Build123d but I really want a hybrid mouse/code CAD built around it. I want to be able to click on entities and have them show up in the code editor instead of blindly trying to select edges.

This feature technically already exists in build123d + OCP CAD Viewer (ocp_vscode). You can click a feature in GUI and it will copy the index to clipboard, you can then apply e.g. fillets to it on the code side. See here https://github.com/bernhard-42/vscode-ocp-cad-viewer/blob/ma...

The biggest caveat is that there is currently absolutely zero mitigation for toponaming. This feature is extremely brittle, so I tend not to use it very much -- but I am still glad it exists for those situations when composing a selector is too annoying.

Re: Build123d: A Python CAD programming library

#29
post #8

CAD has needed a proper code-first workflow for years. The existing options always felt like they were built for the GUI first and scripting was bolted on after.

I disagree. Most CAD is inherently visual. These code-based systems work great for highly parametric and regular objects like fasteners and gears, or for procedural art, but those are really the tiny minority of CAD tasks. Most of the time you need to see what you're doing and click on stuff.

Most CAD is more similar to graphic design, painting, etc. You wouldn't expect a "code first workflow" for Illustrator, and as far as I know nobody has ever successfully done anything like that.

The closest I've seen are things like UI design tools that can generate code. But a) they usually suck, and b) that is a much simpler problem than CAD.

Re: Build123d: A Python CAD programming library

#30
post #8

CAD has needed a proper code-first workflow for years. The existing options always felt like they were built for the GUI first and scripting was bolted on after.

I disagree. Most CAD is inherently visual. These code-based systems work great for highly parametric and regular objects like fasteners and gears, or for procedural art, but those are really the tiny minority of CAD tasks. Most of the time you need to see what you're doing and click on stuff. Most CAD is more similar to graphic design, painting, etc. You wouldn't expect a "code first workflow" for Illustrator, and as…

[flagged]
Post reply on HN