OpenSCAD 3D rendering just got an order of magnitude faster

I suppose there's no accounting for taste.

It might be best to think of it as a platypus: An interesting element of the ecosystem, but disappointing if you need a duck.

Alternative viewpoint:

1) It depends on the kind of object you want to model: for simple, geometric shapes, OpenSCAD is by far the best choice. Unless you don't know how to code, in which case it's unusable.

2) When you start to need chamfers and fillets, OpenSCAD simply doesn't work and Fusion is by far the superior solution. Also, if your model starts to become really complex (lots of boolean), OpenSCAD becomes very slow and eventually unusable, even with the change described by the OP.

3) If you need to model organic shapes neither freecad, fusion or OpenSCAD are unusable. Blender is way better for this use case.

4) If you are a programmer and enjoy building truly parametric models, as in: models that you can build with scripts and Makefiles, then neither freecad nor fusion are a fit. Cadquery is slowly getting to the sweet spot OpenScad occupies, but it's not there yet.

5) Fusion is proprietary, closed-source and costs money. Worse, you are basically at the mercy of the vendor. In particular, it's a complete black box: there is exactly zero guarantees that your carefully crafted model will still work 10 years down the road.

6) Freecad's UI is basically a nightmare and the CAD engine (the terminolgy in the CAD world for some reason it is called the "kernel") is the same that cadquery uses, and it's an old and clunky NURBS engine called OpenCascade (if I'm not mistaken). It is definitely not up to par with Fusion's engine.

7) Fusion is lousy at talking to the rest of the ecosystem. Proprietary and opaque file format that no other product outside of the AutoDesk ecosystem can read, lousy at reading things created with other softwares.

Exp: https://www.thingiverse.com/thing:2029895/files

Broom holder. You can't share an STL that will fit every possible broom diameter. But what you can do is programmatically generate one, and let the users change the variables.

Also, it's extremely reassuring to have a description of your model that wasn't generated by a program. In earlier versions of FreeCAD, my model would often not be saved correctly and be totally broken when I opened it again. FreeCAD also crashed randomly on me quite often. In contrast, all you need for editing .scad files is a text editor, and that probably won't crash that often. :)

* Fasteners (screws, nuts, etc.) * Gears, sprockets, etc. * Computational art

99% of the time you want real parametric CAD (Solidworks etc.). Nobody is going to design a motorbike or a door handle or a vice with OpenSCAD.

It is really a product of open source 3d printers who were seeking a way to describe complex 3d objects, reliably version them, and then spread them around the internet.

It's a cool idea, but it's toolchain has always been sub par. It is my understanding that most of the people working on it are more concerned with getting it good enough, and the bulk of their development energy on 3d printing slicing engines. But I wouldn't want to use OpenSCAD to do any traditional design work or drafting, or really even to design any object that will have to be made with subtractive manufacturing. It's a happy medium that FreeCAD has an OpenSCAD workbench - that way you can do the complicated stuff directly in OpenSCAD for 3D printed parts, and then include them in your FreeCAD assemblies.

I would also love for it to have a variable that rounds off corners to some diameter on the cubes, cylinders, and even polyhedrons. It's possible to round off corners using the intersection operator but it is a lot of work and something that I do in almost everything I build. Nobody likes unnecessary sharp corners.

I have good luck with Blender... much more then with Freecad... haven't tried OpenSCAD though...

Are they though?

E.g. if the determinant of some matrix becomes too close to zero, switch to exact arithmetic.

Implementing robust boolean operations on polyhedral geometry is and has been known for quite a while to be very hard if you do not have arbitrary precision math, or at the very least some sort of interval arithmetic that kind winds back a calculation and increases the precision up to the point where an unambiguous decision can be made about the sign of an expression.

Here's an example: create a sphere, tesselate it to - say - a million triangle (not much these days), make a rotated copy of the original by 0.01 degrees and intersect with the original. I guarantee you the resulting calculation will either crash your floating point based implementation or it'll produce a model that will be non manifold.

Those things needing (to be careful) arbitrary precision can sometimes be truncated back to 64 bit doubles, as long as necessary invariants are maintained.

A simple example: suppose you have a shape at the origin, that is designed for careful CNC, so maybe 1/10,000th of an inch or maybe even 1/100,000th of an inch accuracy. Suppose 1/10,000th accuracy is, say, ~14 bits of mantissa, then making the part 16 inches long is another 4 bits. We're up to 28 bits. Now suppose you do an operation, like intersection with another such part, or a fillet or rounding, whose computation merely needs to square numbers. Now you need 28*28 bits, anf you overflow the mantissa. Or move the part out to coordinate 64, uses another 6 bits. And god forbid you hit an algorithm that needs to cube numbers, which triples the number of bits you need in order to retain accuracy needed for the final part to meet tolerances.

It gets troublesome quite quickly.

https://libfive.com/

Bearer of bad news here: I've tried this on a model I had lying around, and ... :-\

box.scad is an old, somewhat complicated electronics enclosure where I experimented with building a non-trivial, fully filleted model with scad.

The model has quite a lot of "natural" booleans (eg holes and such), but also, the fillets are implemented either:

    - with a ton of procedurally generated minkowski sums (offsets) combined with booleans.

    - with hulls of far-apart spheres

    as far as I can tell, fast-csg does not render the model properly :-(

    speedup with fast-csg is decent (~5x) only at very low $fn

    speedup is entirely underwhelming when $fn gets high

    minkowski offsets likely gobble up the bulk of the render time

Your mileage may get much better if you steer clear of hulls and minkowski sums, and to be fair, I'd need to run a benchmark with no minkski in it.

Benchmark:

    old :   time openscad -o z.stl box.scad

    new :   time openscad-nightly --enable fast-csg -o z.stl box.scad

    $fn = 5
        old                    = 6.8 sec
        new --enable fast-csg  = 1.2 sec
        x 5.6

    $fn = 10
        old                    = 15 sec
        new --enable fast-csg  =  3 sec
        x 5

    $fn = 20
        old                    = 67 sec
        new --enable fast-csg  = 25 sec
        x 2.68

    $fn = 40
        old                    = 427 sec
        new --enable fast-csg  = 369 sec
        x 1.15

Specifically these are hard to do with nodes:

    - for loops                                                                 
                                                                                
    - if <complex condition is met> do this else do that, where <complex condition> requires to look at the evaluated output of an upstream node.
                                                                                
    - recursion                                                                 
                                                                                
    - global variables                                                          
                                                                                
    - self introspection                                                        
                                                                                
    - accessing things by name rather than painfully dragging noodles from one point to the next
                                                                                

They all have that subtle APL-like write-once-read-never feel.

In my experience large code bases are way easier to navigate, refactor, change, test, debug than large node-based models, even when you take care of organizing your node hierarchically.