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.
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:
To add, there's a new CAD kernal that is in slow development called truck [1]. Is is written in Rust and you script/make models in Rust. It doesn't have any geometric constraints though.
There was a very short attempt at starting to make a GUI for truck [2] but development has seemed to have halted. There was discussion and hype about this here a couple months ago [3].
On the contrary if you're a coder doing anything non-substantial and only rarely need to do some basic 3d modelling I would say definitely look to openscad!
I make models for my 3d printer just a few times a year. I find it much easier to get back into openscad than remember my way around a gui or wrestle with more advanced tools.
There's nothing I've not managed to make with openscad yet, though the things I have made are embarrassingly simple (yet highly functional).
You CAN get things done, but there is no getting around the fundamental problems expressed here.
All my models are about 50% variable declarations and 50% inscrutable equations to express the relationships between the values. Sometimes huge ternary stacks because the language doesn't allow variable changes, so you can't have simple if/else/case to have a simple concept like a default value that maybe gets replaced based on some other condition.
And the lack of things like fillets is simply impossibl. The things you have to do to attain the end result of a fillet without an actual fillet function is ridiculous, and even after doing the ridiculous things, you still have a limited crap result where no matter what you simply can't actually have a fillet wherever you want, but you can compromise and get at least the ones you really need if you're willing to live with a simple design.
That is not a good tool. A good tool gives you the means to express whatever you need to express. Openscad gives you the power to express cubes and spheres and hulls and intersections of those, and even that only in a bafflingly limited way thanks to the language limitations.
It's not a great tool. It's a great proof of concept for a great idea for a great tool.
> 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.
> OpenSCAD is a one-way, declarative CSG environment that essentially only outputs mesh formats
This is why such a basic-seeming thing as “how do i get the bounding box for this CSG frankenobject I’ve created?” comes up again and again on stackoverflow etc. it’s apparently not possible without some hacks.
I’ll take a look at the alternatives you mentioned, thanks.
OpenSCAD is often said to be for programmers, but in some ways it's more for mathematicians. If you know the formula/code for the object, you can calculate the bounding box, but that isn't a way most programmers are used to thinking.
I can calculate the bounding box, or indeed the exact position and orientation of some surface I want to add to, but that’s tedious and so I don’t want to.
It’s like programming without higher level language constructs. Yes, lower level languages are still Turing-complete so can technically do everything. But the necessary housekeeping distracts from the real problem I’m trying to solve.
I’d recommend taking a look at SolidWorks. For hobbyist use, it’s $50 / year or $15 for a month. You will save yourself so much time and headaches and develop a skill that could be useful for your resume.
If you're a U.S. (or Canadian) Veteran it's $20/year.
BUT
for these reduced price options, it's the educational version, and the files are watermarked, and the license precludes commercial use.
That said, if your goal is to learn a CAD program and get a job --- in an industry/region which uses Solidworks_ (for some reason, CAD usage seems to be specific to either certain industries or regions, though SW is almost certainly the most widespread), that is definitely the way to go, along with a Community College course/degree and/or a training certificate:
The main complaint I have with CadQuery et. al. is the API verbs are all coming from the point of view of describing bRep shapes instead of thinking about the design from the standpoint of "how would I make this?".
I think there's an opportunity for a code-first CAD API to incorporate GD&T and manufacturability information directly as part of the modeling process. For example, if I'm making a shaft I want to describe that operation as it will actually be performed in the shop e.g.:
(1) select round stock of nominal dimension X
(2) cut to rough length
(3) chuck in 3-jaw chuck and drill center
(4) flip around in 3-jaw chuck and drill the other center
(5) mount between centers
(6) turn to rough outer dimension
(8) turn down to add the various bosses, threads, chamfers, other details, etc...
With this kind of a process I get all kinds of GD&T information for free--for example, the precision of my 3-jaw chuck determines how much larger my nominal dimension X needs to be than my target rough outer dimension to be able to reliably achieve it.
So I think these APIs are coming at the problem from the wrong point of view--they're all about driving the CAD kernel and telling it how to draw abstract shapes in a computer. Instead what I want is to tell the computer how I intend to make the thing and get an estimate of what the result will look like.
> So I think these APIs are coming at the problem from the wrong point of view--they're all about driving the CAD kernel and telling it how to draw abstract shapes in a computer. Instead what I want is to tell the computer how I intend to make the thing and get an estimate of what the result will look like.
I have certainly learned over time that when you're looking at an object that exists in the real world, one way to start to figure out how to model it is to figure out how it -- or its injection-mould positive -- was physically made. Can it be cut with a mill? Was it glued together in parts?
It absolutely is fun to try to work out how to come up with a shape subtractively from some giant primitive as if it was a block of steel. I often find myself visualising in terms of a scroll saw. I watched a couple of great videos about three-dimensional scroll-saw work and it weirdly affected my understanding of CAD!
The problem of course is that that limits one to straight lines and arc moves.
Are there any really good G-code previewers for lathe work?
For that matter, what is the best 3D G-code previewer which will allow one to see the surface of the cut part in 3D? I'm about to break down and buy tkcnc --- is there something better?
No, I think G-code is too prescriptive and low level for the modelling task. What I'd prefer is some way to specify operations in a fluent, object-oriented API e.g.:
I can see where you are coming from, and I've thought about similar ideas. But ultimately, I think this fails for separation-of-concern reasons. Describing the part is different from describing how to make the part. The same part might be sent to 3D printing for a non-functional fit prototype, sent to a prototyping machine shop to make 5 or so units on basic CNC machines that require 3 set-ups to complete it, and after a few design iterations scaled to production on a multi-spindle Swiss-style lathe that drops finished parts into the basket all night long, lights-out. Those are wildly different programs and work flows.
Something like you propose might be an interesting thing to explore for creating CAM posts. The actual Gcode that your API would emit is going to vary quite a lot even within super-similar machines -- a 3+1 axis job targeting a machine with a FANUC controller is going to be pretty different from the same job targeting a machine with a Heidenhain controller.
> Describing the part is different from describing how to make the part. The same part might be sent to 3D printing for a non-functional fit prototype, sent to a prototyping machine shop to make 5 or so units on basic CNC machines that require 3 set-ups to complete it, and after a few design iterations scaled to production on a multi-spindle Swiss-style lathe that drops finished parts into the basket all night long, lights-out.
I think you might have a point here, but I'm going to push back on the idea that these three parts are the "same part" because they'll all have wildly different mechanical properties, dimensions, and dimensional consistency. They are not all necessarily interchangeable (although they could be, we'd have to integration-test them in an assembly to find out!).
My point is the "abstract part" isn't really a thing, and the real life characteristics of each concrete part are inextricable from the way it's made and what it's made of. I wonder if it would be helpful to force me, the designer, to think about it that way from the start?
3D printing is an odd case that tbh I hadn't really thought of. The things I make are all subtractively manufactured (except for welds which are addictive only in a degenerate sense), and I have no experience with 3D printing.
Too late to edit, but I've been foiled yet again by touchscreen phone autocorrect. While welding is certainly addictive (albeit in an entirely wholesome non-degenerate sense), what I meant above was additive.
The alternatives you suggest look interesting and worth checking out. I certainly have my annoyances with OpenSCAD, but one reason I keep coming back to it is that many of my models have user adjustable parameters, and as far as I know, OpenSCAD is the only tool supported by the thingiverse customizer.
Personally, I rather like the constraint based approach in FreeCAD and miss that a lot in OpenSCAD.
Coming from freecad as my only frame of reference, even though I understand the concepts of build123d, I found it wildly difficult to express anything useful in it.
Not saying it's not possible - I've seen what it can do - but even with my software background it was hard for me to really work with something that isn't based on constraints.
I was extremely excited about Fornjot for both personal and professional reasons, but the author has shared important updates that would deter me from using it outside of hobbyist contexts:
As scary as the last two lines are, it's not the developer abandoning ship, it's just him optimizating the process. Cutting releases was taking time best spent on dev, and commiting to main as a mainly solo project is perfectly reasonable.
Ah these look so much nicer, thanks! OpenSCAD's willful disregard for the entire CAD industry's well established parametric modelling paradigm always annoyed me.
If you would like to point out a library which allows one to use the "CAD industry's well established modeling paradigm" in OpenSCAD, I would be glad to try it out.
I don’t understand the intricacies and much of what you said. I am sure those are legitimate concerns for a professional.
But as a hobbyist, this is the tool I have turned to time and again for making simple parts or objects. I found this to be more intuitive and easier to onboard vs. learning different visual designing tools each with its own quirks.
Oh, I'm a hobbyist. (Well, at the moment. Some things I am making might soon get to the Tindie/Etsy/online sales level.)
And you're right it has a place. I'm not totally advocating switching if it works for you. But for newer users who want to really use code-CAD, out there are tools that are not held back by OpenSCAD's limitations (and which scale less painfully with complexity), and learning about them might help see simpler solutions or even bridge the gap to GUI CAD.
The most significant limitation I can see for a hobbyist maker is reaching the point where you can't make something yourself (or can't make it cost-effectively) and need to get it fabricated elsewhere. That is when you may very well find you would benefit from something OpenSCAD cannot (ever, I think) do: true, efficient STEP export.
As my 3D printed designs get more complex I am pushing closer and closer to the point where I will need a part cut conventionally out of steel or aluminium, or -- most likely sooner -- where I will need custom fasteners. One of the advantages of a workflow that will produce STEP is being able to work with someone who has those specialisations (and/or import work into the software tools they use). So at the earliest point I could, I made sure I was in that world. As a side bonus, it means being able to potentially use home CNC, or even just extract vector faces from generated models for use with a laser cutter or a Silhouette-type machine.
Out of completeness I should note that in that situation you're not totally out of options, as FreeCAD can interpret OpenSCAD in a bRep context with the exception of a few operations like minkowski() that get left as meshes. But it's a real limitation.
CADquery was a neat intro to using code for CAD, but it ended up being kind of a pain when it came down to designing stuff that I'd want to be able to come back to and understand months later (ie being able to tell what exactly each number is referring to), or stuff that might need curves and constraints. I also got into it in part because of the idea of using typical version control to tracks changes and of being able to get Copilot to help out.
Perhaps I just wasn't fully understanding how to use it and it wasn't supposed to be mainly CSG focused, but it ended up being much more effective for me to spend a day just fiddling around in FreeCAD to learn how to use it.
Yes -- despite my comment, I am in the same boat. Code-CAD is actually a backup/toolbox item alongside FreeCAD, for me.
(The programmer in me would love to be able to leave comments in more places on FreeCAD designs. I have spent a lot of time trying to learn how to make the simplest, most self-documenting parametric flow.)
But the reason I framed my comment above in terms of spending at least some time with CadQuery or Build123D etc. over OpenSCAD, is that CadQuery taught me additional CAD concepts that helped me make progress.
I had tried to use FreeCAD before, about 18 months before I finally got my 3D printer, but I was absolutely bamboozled. So when I finally started with my 3D printer, I started with OpenSCAD. I got small stuff done and held it in my hands, but I immediately felt its limitations (partly because I struggle with co-ordinate spaces and maths). Was I really going to be stuck doing all the maths, over and over again, or using libraries of specific functions like BOSL? My maths skills are weaker than I'd like, and it felt like a dead-end.
I stumbled on CadQuery, spent some time working on some key things in it, really immersed myself in the documentation, and this helped me grasp the bRep fundamental ideas of faces, vertexes and edges, normals, orientations, planes, etc. All the higher-order concepts in modern CAD above CSG.
I then had two things I knew could work for me -- CadQuery or in a pinch OpenSCAD. And because as you know there are/were workbenches for both, the knowledge gave me the confidence to spend time with FreeCAD.
Without stumbling on CadQuery I would have been stuck with OpenSCAD and it may have driven me away from trying to make my own things.
There are elements of my designs I will be (re-)building in Build123D to get some code-CAD advantages (scripted customisation). But it's the time with CadQuery that helped me make the transition to CAD thinking.
(N.B. the Replicad studio code editor on that site seems to be broken today, which is a bummer -- it wasn't when I last checked)
CadQuery might not be in Ubuntu repositories on its own (same with Build123D -- these are python libraries really) but have you tried looking for cq-editor? (I think that's in Homebrew as well.)
To be fair I'd probably install the VSCode support for Build123D and CadQuery instead, because 1) this is code-CAD and you really manage it as such, and 2) I'm not that fond of the cq-editor environment.
That is... a weird post to be making from a throwaway account. Do you work for Big OpenSCAD or something? :)
But that said, this is all correct. OpenSCAD is actually an extremely limited environment and much more expressive tools exist in the same "code-based 3D modelling" space.
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.
The awful thing is that you can only export triangles, so you can't make any true curves. If it was capable to true circles it would do everything I have ever needed to make.
I don't understand this. You can make triangles small enough that you can't tell the difference, and define them mathematically in terms of curves..? Isn't this how any rendering will ultimately work? The primitive is triangles.
Yes, but the representation as arcs allows one to defer the conversion to polylines/triangles until a later time.
As an example, if doing V carving, the appearance will be smoother if the geometry is imported so as to have arcs/curves, deferring the conversion to polylines/straight line movements until the last possible moment on the machine.
Arcs/Curves are also easier to work with if one needs to edit, and are more efficient in terms of representation/disk space/storage.
Well, you could export enough triangles to get less than 0.0005" variance, but in practice actual CAM software will choke on it is my impression; I sent some circular objects out to be machined, but they just treated by OpenSCAD-exported files as a secondary reference for them redoing it in real software.
CAM people, for example drive numerically controlled machines and robots. (CNC machines) These machines are driven by lines, arcs, higher order analytic curves, such as the conic, and recent controllers will accept bsplines.
Having path planning done with real geometric entities brings a lot of benefits along for the ride! Accuracy without a bazillion entities for the look ahead system to manage and for program buffers to drip feed (DNC) to a machine that probably does not have a large enough program memory to deal with that bazillion entities.
In many cases, derivative or extrapolated curves do not convey the right shape or path or are difficult and time consuming to force conformance.
We ended up with the big geometry kernels, such as Parasolid, precisely so that CAD could create a brep (boundary representation model) of sufficient fidelity to make other tasks, such as CAM and simulation, as well as derivative designs possible, practical, repeatable.
Those big code bodies have so damn many man hours of development in them it is very hard to replace it all. And that means we are stuck with some things, like many operations being single threaded, which caps CAD design to be a function of sequential compute speeds.
There are ways to build models to eliminate some dependencies, and the same goes for assemblies, so that multi-processing of some sort is possible. That brings our multi-core CPUs into the game.
But those are hard to teach, a lot of software does not yet support multi-threading anywhere near enough to fully exploit the model work, and, and, and...
In the CAD / CAM world, the primitive is the b-spline, and the surfaces it can represent.
Those generate faces, trim boundaries and sets of those create boundary representation models.
And still those can cause grief. They might be open, or just a surface representation. Or, they may self intersect...
Basically, every edge, which boils down to a b-spline curve that matches up to another b-spline curve serving as a trim boundary of a surface, must be shared by two and only two surfaces or the model is not representative of a real world, manufacturable thing.
Another great observation regarding real world objects is there are no edges, just radii, if only a single molecule big. Just an interesting and perhaps useful aside.
And b-splines are constrained to conform to the properties of lower order entities, such as lines, arcs, and the like. This is a part of why wireframe entities are all called "curves" or "sketch curves." They literally are all b-splines constrained by number and or placement of control points.
>You can make triangles small enough that you can't tell the difference, and define them mathematically in terms of curves..?
This doesn't work if you already have a mesh. You need to generate your triangles on demand from the BREP data.
Alternatively you need to use tesselation, but then you need to design your models with tesselation in mind, such as people do in blender.
>Isn't this how any rendering will ultimately work? The primitive is triangles.
Uhm no. 3D printing and CAM do not work with triangles. The slicer and CAM software generate tool paths in gcode.
Importing STEP files into OrcaSlicer/BambuSlicer gives me better quality results and better print speeds than using STL files.
I have personally never understood the love for STL files in the 3D printing community for anything that isn't the result of a blender export. Like, is it really that fun to constantly export different versions of STL files set to different quality levels? Rescaling a print in the slicer is not recommended with STL. You have to re-export the model from blender where the tesselation happens.
You call out 2d and mention mills and routers, so after reading the page I'm thinking I wouldn't be able to design a piece to be put in a CNC lathe ala the hub in the lower right of https://canev.com/cdn/shop/products/CEV5205_1024x1024@2x.png..., which has multiple holes (sometimes threaded), including threaded setscrew holes tangential to the primary axis.
It's not a serious problem I have, just saying I like OpenSCAD, I have been able to generate every shape I've ever needed to create, and it would do everything I want if it was possible to generate true curves (because I farm out the manufacturing).
> People do get oddly grumpy when you criticise OpenSCAD
Most of us don't realize how much our comfort with familiar concepts affects our ability to objectively evaluate them. Moving from dev to being a tech artist, I see the same exact sort of irrational biases, hang-ups and endemic misconceptions with completely different tool chains and types of complexity. When I first started using Houdini, I tried to turn every task into a Python coding problem because that's what I was comfortable with— Python is amazing in Houdini but it's definitely not the best way to accomplish most tasks.
This viewpoint resonates for me. OpenSCAD is a useful tool for hacking together 3D parts quickly, but an excellent tool for exercising the shape rotating parts of your brain.
Currently working through a library using the new Python-enabled OpenPythonSCAD, and at the end of it, hope to work on a project which requires conic sections (which I'm still researching, so if anyone has any good resources on that I'd be glad of them).
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.
That's my experience trying to use OpenSCAD from the cli for some home remodeling projects, there I was, neo-vim open, trying to do 3d with pure text files. But at the end of the day the platform felt very limited. Also "Big OpenSCAD" is hilarious.
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.