throwgfgfd25

> There's nothing I've not managed to make with openscad yet, though the things I have made are embarrassingly simple (yet highly functional).

It is workable if you have an extremely solid grasp of mathematics, and you don't mind objects that ultimately retain the feel of the combination of a few CSG primitives.

But I make 3D-printed things that for a variety of reasons are little more than rings, plates, discs, and helixes, and I've already very clearly run into situations where the face/vertex/wire model of a proper CAD package is more or less the only way to keep control over a design.

> 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.

Ahh! That was the name, thanks. I was trying to remember it to find the blog post for [3] again. It is uncommonly well-written.

> and as far as I know, OpenSCAD is the only tool supported by the thingiverse customizer

I am sure you are right that this is still the case. This is a big plus for OpenSCAD.

One of the alternatives I mention takes customisation to a different level that makes me hopeful.

Replicad can be used as a library in a web app:

https://replicad.xyz/docs/use-as-a-library

And they have a demo here (a React app):

https://sample-app.replicad.xyz

> e.g. a human says "these holes need to be separated by 2mm", but when we program in OpenSCAD and other CAD languages we usually specify x={-1} for one component and x={1} for the other (just an example of how design intent is being lost)

What you mean there is constraints, I suppose?

And yes -- there's some work to add constraints to CadQuery sketches/cqparts, but it's early.

https://cadquery.readthedocs.io/en/latest/assy.html https://cadquery.readthedocs.io/en/latest/sketch.html#constr...

I suppose the logic has always been that if you control the placement of parts in code, you can build your own quasi-constraint logic to make reactive, parametric designs. And you might argue that "having complete control over this in code" is its own kind of "design intent" with its own potential justifications.

Specifying constraints in the way the CadQuery development does may not be natural.

But both CadQuery and Build123D have kernel-based tools like face finders, vertex finders etc., that are capable of things that OpenSCAD definitionally cannot do at kernel level.

Replicad (a JS OpenCascade environment) has face and vertex finders, face-based sketching, etc.

I ultimately went the other way, and got to FreeCAD from OpenSCAD via CadQuery; it was CadQuery that helped me understand important concepts.

CadQuery may appeal to you? It does have (some) early support for constraints in 2D and 3D I believe.

(CadQuery and Build123D ultimately share both OCP underpinnings and viewer tooling.)

Yes - I haven't bought these yet but I do intend to, because I need to brush up on all three (well, I don't think I ever really learned calculus, to be honest).

Joan Horvath is a superhero -- I've seen a few interviews now.

I will very happily use OpenSCAD for that because it seems like a well-chosen tool for the job.

You said this so much more succinctly than me.

> 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.)

It's also good if your aim is to visualise maths.

The three I suggested above are absolutely as open as OpenSCAD.

(With the addition of developer openness: directly meshing with Python or JS libraries)

This is a totally reasonable question! I am using a throwaway to limit my HN usage, to be honest. I wish I had a better way to manage my addictive social media behaviour than torching accounts after a few discussions. But I do not.

I saw this thread only because it's clearly a followup to the FreeCAD discussion the other day that I have contributed to.

--

People do get oddly grumpy when you criticise OpenSCAD; there is an element of the "I can do maths and refuse to believe CAD needs to be any more than this" militancy about it.

I absolutely don't hate it -- OpenSCAD's mere existence is what unlocked my ability to even reason in 3D, actually. But that quasi-militant tendency is holding back a fascinating, liberating software field.

If you want to do code-CAD for anything substantial and you haven't yet developed a significant dependency on OpenSCAD, do your brain a favour and spend at least some time with CadQuery, Build123D or (if you prefer JS to Python) Replicad.

As impressive as NopSCADlib and BOSL2 are (and OMG they are, when you consider what they have to work with!), OpenSCAD is a one-way, declarative CSG environment that essentially only outputs mesh formats. It's really not that much better than working with three-dimensional pixels. You won't really be able to analyse, iterate over or measure your models, easily build on faces, do easy chamfers or fillets, export STEP files, make use of constraint-based designs, model assemblies, or so many other things that "CAD" means in the 21st century. All the tools that help you do this on OpenSCAD are layers and layers of task-specific hacks and clever bodges.

I totally get wanting to make models with version-controlled text files instead of GUI CAD (which can be a sort of weird battle to learn for a programmer), and I get wanting to avoid FreeCAD. I just don't really get wanting to limit oneself to such a limited concept of a 3D "model"!

The three alternative systems I mention are all based around bindings to (or in Replicad's case, cross-compilation of) OpenCASCADE, which is a bRep CAD kernel capable of much richer interactions. It is not without its faults, but arguably code-CAD spares you from some of the inscrutability that trips up FreeCAD's interactive model.

Yes! Sorry. It's mentioned in the comments here but it should have occurred to me to expand on it.

TNP is really a research-grade problem that all CAD packages have to mitigate -- you can I think still run into issues that stem from face/vertex naming in all CAD packages if you really push them, and there are pathological cases where the solution is only to be consistent in arbitrary choices.

But mainline FreeCAD had no solution for this. A solid proof-of-concept implementation has existed in RealThunder's fork (which was originally used for Assembly 3 development) but since the solution touches an awful lot of the code it was never ported across and got increasingly difficult to port. There was reluctance to just switch wholesale to his fork because it contains some somewhat contentious developments, and it has taken some very deliberate, considered rethinking of the organisation of mainline FreeCAD releases to get the TNP code ported, which it now is.

There are still TNP issues, and there are still things one should not hope to rely on in FreeCAD -- like building on faces generated by chamfers, drafts or thicknesses.

I also think what risks being lost is the wisdom of sometimes deliberately choosing to build some features of a part from the base planes rather than a generated face; it reduces the complexity of dependencies and allows much freer re-working.

It is. The chap they hired to do port his solver has done really great motion solving work in the past (and, amusingly, had an application called "FreeCAD" before FreeCAD existed).

http://www.ar-cad.com

It's very positive that he's working for Ondsel.

I agree that it's more difficult to manage Build123D or CadQuery due to their status as Python packages with heavier dependencies. (Less of a problem with Replicad, which is a client-side JS package)

This is a little bit of why I jumped to FreeCAD from OpenSCAD -- the existence of prebuilt distributions of FreeCAD, and the realisation that I'd always be able to script FreeCAD if I needed it.

Though I think Build123D has the beginnings of momentum (I also think it's not hard to see why):

https://github.com/phillipthelen/awesome-build123d

But OpenSCAD is a terrible, obstinate "standard" choice; I wish it were not seen that way, don't you? Because it's holding everyone back.

(This does make me realise that maybe working on an Electron-based Replicad desktop app would be a good use of my time.)

I am, it should be noted, _fucking terrible_ at soldering. But my TS-101 actually gives me hope. I'm so happy with it.

(It's also incredibly, incredibly useful for heat-set inserts, because you get to decide really precisely how long they will take to insert!)

> but it could be compared to bitmap graphics vs. vector graphics.

This is very much how I internally understand it and explain it to people, yes!

It is a good analogy for e.g. why it's often a challenge to get something milled with a CNC when you only have an STL file.

STL is like a PNG line drawing: it can be high quality, but it's not describing the drawing. STEP is like SVG: it's more effort to render it, but it contains the instructions to draw it.

They didn't pick a winner. They (Ondsel and others) evaluated all the workbenches, chose the best ideas and built a new workbench around a new (well, new to C++) solver.

There was an Ondsel blog post about this:

https://ondsel.com/blog/default-assembly-workbench-7/

The major advantage of Build123D for your use case -- sending it to someone else to fabricate it -- is STEP output support.

This really expands your options for what you can make and who you can ask to make it. There are now some online fabrication places that will do CNC from mesh formats, but really the only way to have proper control is sending them a STEP file.

It was called Path -- in 1.x it has been renamed to CAM, which is a much more sensible name.

That's good to know.

It is C++/Qt/Python/OpenCASCADE, runs on Linux, Windows, Mac.

Pretty low compromise in terms of portability; surprisingly good on Mac, has ARM support. I think on FreeBSD/OpenBSD as well via ports.

It is a bRep GUI CAD system with 2D drafting, 3D CAD, a technical drawing workbench, FEM, mesh tools etc., and now a core CAD assembly tool. It has a "workbench" (think GUI plugins for specific task) approach, supports macro recording of Python macros, has many third-party workbenches, It is constraints-based and fully parametric: designs recompute and reflow when underlying measurements change.

It's also a 20 year labour of love by a bunch of CAD users.

If you are familiar with QGIS, it's really a lot like that but for CAD. It's less like GIMP than some people say, but it is a bit like GIMP (and like GIMP, is in a long battle with a core architectural problem; FreeCAD 1.0 includes a big victory over its worst core problem)

Have you looked at Replicad?

https://replicad.xyz

Similar principles, but a bRep kernel so a much richer API.

Right -- OpenSCAD is an object compiler. You give it code, it gives you an object.

Your object is not something that can then be used to iterate on, except by placing it in space and adding or subtracting other stuff to/from it.

Have you looked at Build123D or CadQuery?

Both are Python packages (different API styles, compatible underpinnings) that do OpenSCAD-type things, but using the OpenCASCADE bRep kernel, so it is less "counterfeit" -- if you want to do something based on a face or edge or vertex that was the product of a previous operation, you can. Both have some constraints support.

In many ways they are both just a prettier alternative to the FreeCAD Python APIs -- indeed there was a CadQuery workbench for CadQuery 1.x.

CAD is never made quickly, I think.

But FreeCAD was just not that sort of project. It's a C++ and Python wrapper around a CAD kernel, supporting a set of tools -- some frustrating tools, some quite powerful or niche, like the ThreadProfile workbench or the guitar workbench -- and it has never bothered the highly technical community of users much to unify things.

They weren't really trying to make a major competitor to commercial CAD: they were trying to have the tools that they individually needed and collaborate on the problems they had in common.

The balance has markedly shifted since 0.18 and now there is that focus, and significant commercial impetus. In the time I have used it -- about three years on and off -- it has clearly become more of a focus to make a complete product.

ETA: there is no doubt that one of the major things that needs to be resolved is the duality between Part workbench and Part Design workbench flows.

There appear to be some discussions about this -- about how to either merge them or create a new, future workflow that makes better use of them.

The crux of it has always been that a section of the community thinks the Part Design feature-oriented flow is a bit of a crutch, being as it is implemented as a set of implicit booleans on top of the basic flow.

Part Design is more fun to use for a beginner, but it is definitely not faster, and one of the real problems is that once you are in the feature flow you are kind of stuck in it -- it's possible to merge in objects made in the Part flow but only in relatively basic ways (starting a PD body with a "base feature", or fusing the PD body with the non-PD stuff at the end).

I would expect future development to look at this much more seriously, but there was and is no point in getting into it in more depth until the major TNP issues are truly behind FreeCAD, because a feature-oriented flow especially relies on there not being problems there.

Replicad is quicker to render complex things than OpenSCAD -- significantly quicker. It uses an emscripten port of OCC.

It's also embeddable as a library, which means being able to make web-based object customisers: client-side, script-driven tools that don't require CAD knowledge for the user. Like the Thingiverse customiser but on steroids. It's a fascinating project.

And I think it's not the statefulness that is the significant thing about CadQuery and Build123D. It's the access to a bRep kernel, so you can do operations with faces and vertices, you can reflect (analyse, measure) the model, etc.

Being able to do operations on a generated face or edge means not needing to know (or recalculate) the location of that face in 3D space; it saves you so much in the way of maths.

If you have very simple (or very mathematical!) models, OpenSCAD can help. But once things get complex you just have file after file of variable definitions.

Functional flows on vertexes, edges and faces created by previous operations is much closer to a code equivalent of GUI CAD.

Yes -- the STEP thing was a big part of why I wanted to switch.

I actually switched via CadQuery: a few minutes with that made it clear that the bits I didn't understand (edges, faces, planes, all that stuff that freaked me out) were simple and logical and had a sort of common sense integrity, and that I might as well try to learn them in the context of FreeCAD.

Had Build123D existed at that point, or Replicad, maybe I'd have pushed on for longer. Build123D is my "fallback toolbox" at this point.

I don't think OpenSCAD can produce STEP, ever. Importing it is another matter; that's a one-way meshing operation. But creating it means having a kernel that understands more than CSG operations -- a bRep kernel like OpenCASCADE, that FreeCAD/Replicad/CadQuery/Build123D etc. use.

You can of course run your OpenSCAD in FreeCAD, but certain operations (hulls, Minkowski I think?) end up as meshes, because there is no easy equivalent. Still, that's better than every operation ending up a mesh.

OpenSCAD is definitely very popular in the maker/microcontroller/electronics world, which is both a good and bad thing, because it is accessible but also limited/frustrating. It enables some good stuff on Thingiverse but it becomes extremely mathematics-focussed quite quickly.

I do wish more of the code-CAD people would look at Replicad, Build123D and CadQuery.

I personally like FreeCAD a lot, but I won't push people onto it; if they like TinkerCad that's fine.

UX work is ongoing.

Stability is good in the latest dev builds on the Mac, though 0.21.2 is the least crashy I've seen it.

But if you mean stability in terms of model stability/robustness when changing things, that's improved a lot with the topological naming mitigations.

It's still not perfect, and I still think FreeCAD is a lifestyle choice. But I enjoy working in it a lot more.

The Mango Jelly Solutions videos on Youtube are very, very worth a watch if you feel inclined to have another go; they have been the best thing for getting my mind into how FreeCAD works as a package (in the sense that it is a "package" at all -- it's really still a collection of overlapping, macro-programmable toolsets gathered around a kernel).