This was my impression with build123d and Cadquery.
On paper they have a better abstraction than OpenScad. Yet, the code to express the same output is more bloated.
I was never able to get over the yak shaving learning curve to be proficient. Openscad mental model is a lot simpler to sustain momentum to go build something.
How did you get around to prefer Cadquery/build123d?
> Yet, the code to express the same output is more bloated.
But it's trivially ready to be parameterized and reused. Model is easy to change, you could think about relations between features not absolute entities.
It's my 3rd attempt to use code-CAD to be honest. OpenSCAD -> CadQuery -> Build123d. I have past experience with SolveSpace and OnShape. GUI CAD approach with drafting in 2D and making solids as late as possible works perfectly well and you could transfer spatial thinking as-is to model coding.
I have somewhat frustrating experience with OpenSCAD and CadQuery. OpenSCAD is perfect for simple things but gap to complex parameterized models was to big for me. CadQuery looks great in examples, but I could not grasp how to use it for my tasks. State tracking is crazy hard.
There are three major factors it clicked for me with build123d.
First is explicit algebra mode. My little coder brain could not comprehend large object trees from OpenSCAD or hardcore chain dance of cadquery. But I know what an object and mutability are. Build123d is amazingly intuitive and has tight primitive set large enough for complex things and small enough to be memorized by heart. Also Build123d has nice docstrings and type hints. I mainly use IDE help instead of online docs.
Second is a good interactive visualizer. I use yet-another-cad-viewer[1]. It allows to quickly debug issues and use my favorite editor. It's crucial to have visual representation and ability to know object bindings to variable name in source code. Killer features for me are on-hand access to per-object transparency setting and selection tool to measure distances between features. It really helps during learning.
Third is I actually sat down and spent around 10h with TTT practice models[2] :))
I believe I'm already effective with Build123d on the same level as with OnShape.
There is a major weak thing with code-CADs though. It's edge selection for fillets. I think about custom filters to narrow edge location. But now it's largely a guess work with edge visualization on fail.
Looking back at your build123d code, it looks like the biggest differentiator compare to OpenSCAD and CadQuery is the expressiveness to assign shapes to variables, right?
I was able to check that box with PythonSCAD thus far, so that's "solved" for me.
Otherwise, I see a lot of vector/coordinate manipulation that isn't too different from OpenSCAD/PythonSCAD.
However, I can see there's some additional abstraction primitives with arc and tangents that looks nice. That doesn't quite exist in any OpenSCAD based or similar engine since there's no built-in way to get info out of the shapes in a reflection-like way.
Maybe I will give Build123d another go and see if I can sustain some sort of momentum.
The learning curve required a paradigm shifted in abstraction. That was too much.
I just want OpenSCAD simplicity, but with modern programming language syntax.
I ended up settling with PythonScad. I was able to hit the ground running and leverage what I already know about python within a day.
It's new, but the author is extremely active and collaborative on github (https://github.com/gsohler/openscad) and reddit (https://www.reddit.com/r/pythonscad/). The author actually pushed for merging this into OpenSCAD mainline, but got gatekeeped out since OpenSCAD maintainers believed Python went against OpenSCAD's mantra of being 'secure'.
I recommend PythonSCAD to anyone that liked OpenSCAD simplicity in abstraction but feel handicapped by the lack of expressiveness.
> The learning curve required a paradigm shifted in abstraction.
This is true! And I think that brute-force simplicity of OpenSCAD is the appeal. I am still ultimately a CAD greenhorn but it got me started, and I don't blame you.
But I guess the point I am getting to is, that paradigm shift is where you really want to be. It's certainly where I think most competent programmers who want to really build in 3D should want to be.
Because it unlocks the ability to reason about the shapes you're creating, within the code that creates them. You can for example place a feature in the centre of a face of an object you just created, without having to recalculate the location of the centre of the face or the normal etc.
You can write code that is truly parametric with real encapsulations, and without a battery of variable definitions and calculations for every single element -- because you can reflect on what you've already made.
(You can also export STEP files to other packages, import STEP files and reason about/analyse those as objects rather than meshes.)
As someone who's dabbled a little bit with OpenSCAD, SolidWorks, etc:
> Because it unlocks the ability to reason about the shapes you're creating, within the code that creates them. You can for example place a feature in the centre of a face of an object you just created, without having to recalculate the location of the centre of the face or the normal etc.
I can definitely see the appeal of this; would it be possible to refit such capability back into OpenSCAD's model (even if it meant breaking some backwards compatibility)? Like, you're not just executing imperative "drawing" operations, but the models you've created become available as first-class objects to be further referenced & poked at?
> I can definitely see the appeal of this; would it be possible to refit such capability back into OpenSCAD's model
This is where my understanding gets weak, but I think the answer in a practical sense is no. Not with the way that kernel works. It could be somewhat modelled on top, but then you have a layer around the kernel doing essentially the whole task of a bRep kernel.
Thankfully I have been able to do what I want to do without learning the complexity that comes with Build123d etc.
Perhaps someday, but I havent had the need to get there thus far.
Also: Encapsulation etc was achievable with Python, which is something I already know. PythonSCAD checked all the boxes for me without the learning curve.
Another option in this space is using python to directly generate openscad code, which is a fun exercise to sort of quickly visualize simple recursive algorithms in a 3d world and play with tilings, space filling curves, etc. of course building what amounts to a transpiler will be fun for some, or a distraction, depending on how focused you want to be on the 3d part.
But openscad is a cool and minimal instruction set for such experiments, and doing this in a language with better meta programming support would be even more fun.
That is such a popular thing that back when I was maintaining the Shapeoko wiki there was a separate section for that sort of thing and it was hard to keep up:
I really hope that OpenPythonSCAD becomes standard and that it can harness all that energy and creativity --- in particular note that it is now possible to upload a design for sharing using it.
Whatever this is supposed to be criticizing exactly, is misplaced and doesn't matter, because they are right about the limitations of openscad and the real world problems that result from those limitations.
You will discover these problems while still green, and their report is corroborated by anyone else who has used openscad.
You could try it yourself and discover that what they said is true.
If you've tried to use openscad to model more than a cube, then you have run in to the limitations. If you have gone on to spend years building models in openscad, then you know even more limitations and problems than you did while "green".
Even people like myself who use openscad for as much as they can because they love being able to describe an open source model in about 1k of human readable, editable, parametric, gittable text instead of several megs of xml or binary, even we will say that this is all simply true. the more experienced you are, the more you know how true it is.
I will still call myself green because I will simply call myself green about almost everything as simple facet of my character, regardless how many years or how much work I've done with something.
Should such people not advise others on what they have learned? Do self-proclaimed experts largely give better advice than experts, or even mere practitioners, who don't like to self-aggrandize?
Regardless, in this case their statements were all sound. As someone who has spent a lot of time figuring out methods to get things done that a new user would not know yet, I have no notes on this greenorns opinions.
It is a reasonable point. I am a greenhorn in the sense that I've been learning CAD for my own somewhat complex, multi-part projects for three years. And I am not an industrial designer. Or a mathematician! (I am opinionated.)
The point for me is that, as a relative novice, I have got past some really important hurdles recently. So I can explain the benefits of getting past them to people who maybe don't know they are there.
I started off using OpenSCAD because it convinced me I'd be able to make something, quite quickly. My first two or three things were OpenSCAD things. It introduces you to stuff that isn't immediately obvious: the more complex booleans like difference of simple primitives, extrudes, lofts, sweeps, revolves. Great! I made things, I printed them, it was transformative.
(There's also quite a good thread library -- Adrian Schlatter's threadlib -- that I do want to say is very helpful and I learned a lot from.)
But it will likely hold back your development as a CAD user for even modestly complex things. Because you will never get access to the fundamentals of your objects -- the faces, vertexes and edges. Putting aside BOSL and the like, it leaves you stuck with a lot of increasingly complex maths, when if you could use the generated geometry you would not have to be. You would have much simpler operations relative to faces and edges.
This is why I said it would be worth spending at least some time with these tools. So you know what is out there.
This is not true anymore with PythonSCAD.
There is a mesh() function which can yield the points and triangles from any
Object. The User is free to modify these points and faces and finally create a new solid from it "polyhedron"
You could use this to skew your model in a fancy way by altering the point coordinates but it might be more difficult to alter on the triangles.
By "faces" I don't mean triangles. I mean the true geometry of the object.
Say for example a single six-sided die: six faces, twelve edges.
But this would be twelve mesh triangles, right? None of which individually represent a face -- and six of the mesh edges are not edges in the true geometry.
A rounded six-sided die might have 26 faces (including the curved edges, rounded corners). 48 edges between them. etc. But the number of mesh triangles and edges will vary according to the precision.
bRep kernels can give you the geometry information, not just the mesh information.
Triangles quite low level internal data.
mesh could output also 4 point polygons on occasion.
of course we can add an parameter to mesh to let pythonscad combine the faces as mush as possible(sub-faces are coplanar) and you would actually get 6 squares for a dice),
even polygon would accept faces with n points as input.
however, openscad does not have an internal B-REP kernel and you would have to rewrite the program to change that.
Conversely, what if I want to import STEP files and modify them?
You can make an almost perfect analogy with raster and vector image formats. They both have their niches; however: it's trivial to rasterize a vector drawing, but it's a ton of work to vectorize an raster image well.
So, all things being equal, it makes sense to start your designs at the 'high ground'.
bRep apps can handle and work with meshes (though it's probably not the most efficient way to work with them) but no, generally speaking extracting the real geometry requires redrawing them. You can get a long way by decimating meshes and using various tools but you're going to end up breaking the result down and partly redrawing.
Plasticity (the sorta-CAD-sorta-modeller app) has seemingly just added some logic to the recent version to help with extracting the true geometry from meshes. I want to like Plasticity but it's not enough CAD for me right now.
The amazing thing to me is that PythonSCAD is useful just for allowing access to variables and being able to write out files --- and it allows encapsulating those capabilities in "normal" OpenSCAD so that it is then possible to use them in a supporting tool such as:
I can see relation models can be represented as graphs (e.g., table foreign keys to another table are "edges"; fields in the table that are not primary keys are "properties")
However, I am not quite confident in the claim that arbitrary graphs being mappable as relational models. I suspect there are certain graphs that can be difficult to express as relational models.
So question for you: Would you say all Trustfall expressions can be translated to SQL? Or, there are cases where there's no such translation possible?
I'm not sure about arbitrary graphs, because all kinds of weird and wonderful math exists out there :)
But from 7 years of working on graph databases, and even participating in some graph query language standardization work, I know two things:
- Anything a graph database can represent and store, a relational db can also represent and store.
- Trustfall's representational power is broader than what either of those would reasonably represent.
I say reasonably because, for example, with sufficient contortions you could make SQL to give you function-like edges like you'd expect in an API. Table-valued functions are awesome! But if every one of your joins was via a TVF ... you'd have a number of problems.
Examples: in Trustfall, you can write a query that asks for the prime factors of all numbers in a given range, without having precomputed or stored any of that data -- it can be computed and loaded "on-demand". You can also have an edge like `divisors_that_are_multiples(of: Int!)` that requires an integer to be provided before being able to be resolved. Both of these are possible to represent in modern SQL, if you try hard enough. But should you? Absolutely not, or you won't be happy with the outcomes.
To make true datasource-agnostic querying, you can't start with a "preferred datasource" that everything else must translate to. Either all data sources are equal, or else there's a massive incentive to use the preferred one at the expense of all else -- so there are massive incentives to optimize predominantly for the preferred source, and we're right back at square one.
One of my favorite hacks: I made a google appscript that scans a list of RSS feeds to email weekly digests. Surprisingly simple, and much more useful then running a separate RSS reader in my opinion.
I have to confess: little automations like this with low barrier of entry is where I find most value in tech. Simple and practical.
I use a self-hosted RSS reader, I'm curious if you could use something like that and have some email digests generated from that. I know tt-rss supports sending email digests. You could set it up to check sites on a less frequent schedule and then the setup sounds just like what you're talking about.
You may be fine with your solution so this comment is more geared towards others who are interested in a similar solution.
I am sure managed RSS platforms also offer some kind of email digest if you don't want to self-host.
