This is an area I'd love to see more development - but the existing tools I've used all have quite major drawbacks.
OpenSCAD is simple and relatively intuitive once you get your head around 3D space and how every object sits in it. The concept - code on the left, visualisation on the right is great. However, it's barely had any improvements in the 8 or so years I've been using it. The tooling is very basic and the performance can be very poor. There's often no way to know if a tiny change will crash (or slow down computation for so long it locks up) the environment (because it doesn't seem to have separation between the render thread and the GUI). Things like fillets, which other CAD environments can do seamlessly, are only possible with a hack which increases rendering time by many orders of magnitude (if it even finishes).
CadQuery seems promising, but in the time I spent with it I found the workplane model quite frustrating. I wanted to write small functional geometries which I could reuse again and again - but I didn't find an easy way to do that. It seems to use global coordinates for all the transformations, so you need to know ahead of time what plane something's on. Maybe I just didn't understand the documentation though - it's incomplete and so you have to piece things together based on examples.
These are of course open source tools, so it's great that they exist at all. In the age of 3D printing, laser cutting and CNC machining fully parametric code based model generation is really exciting.
I'm extremely impressed by what it tries to be, although I found it to be rather hit-and-miss stability-wise. Seems to be the work of a single gifted developer. I would love to see this tool mature because it's pretty much exactly what I want.
For programmatic mesh-based modeling - which is popular in the 3d-printing world but basically a non-starter for "real" CAD - Blender is starting to look quite promising. Blender's Python API is actually very nice for dealing with different coordinate systems (albeit a bit baroque when it comes to interacting with blender's knobs and buttons - although it's very discoverable thanks to the helpful API reference in the tooltips).
ZenCad seems to wrap OpenCASCADE [0], which is also used by e.g. FreeCAD. I can't help think FreeCAD could be awesome if it tried to do less. I wonder if you forked it, ripped out stuff for e.g. architecture/finite element analysis/CAM/CNC/etc, then you could spend time on the GUI experience, and end up with a nice CAD tool that works better for fewer use-cases.
I am incredibly glad someone not-me is wrapping OpenCASCADE. It's an incredibly powerful tool, but it's also kind of a beast of an ancient C++ library with all of the trappings that comes with, like its own version of smart pointers and years of accumulated presumably-unused cruft. You know you're in for a bad time when in 2020-something you have to explain to your bindgen what this is;
For sure. I'm not trying to bash ZenCAD or FreeCAD or OpenCASCADE.
What I mean is there's clearly a want or need for open-source CAD packages; and it feels like it's holding the "makersphere" back. A lot of people still use Fusion360, because it works. The open-source options are OpenSCAD and FreeCAD. I doubt the amount of work and investment needed to replace OpenCASCADE would happen; at the same time OpenSCAD's engine clearly has some major limitations. So it's no wonder OpenCASCADE is used.
I want to like FreeCAD, but it's an insanely complicated piece of software. That leaves OpenSCAD for now. With ZenCAD, maybe rewriting stuff FreeCAD already does is worth it, but you have to worry about a small number of maintainers and adoption.
You might be interested in SALOME, which presents as a CFD pre/post-processor but - like most such software - has CAD functions as well. It also uses OpenCASCADE and actually shares a lot of code with FreeCAD. I found it to be rather more stable.
Hello, thanks for your work, this seems very promising and I am very eager to push it a bit to see if it addresses the shortcomings of OpenSCAD, which I am using right now. However, when downloading the MacOS release of the Studio app and running it on my intel MBP, it seems that it cannot open the examples correctly. When opening the files with a text editor, I get the full content, but when opening them with Studio, only the last three lines (set-bounds, set-quality and set-resolution) are loaded into the text editor. I can copy and paste from my text editor and then it works like expected, but it's a bit tedious. Am I missing something or is this a bug ? I can open a ticket on github and provide more information if necessary. :)
Yes, these are now part of libfive's core – Python is an important-enough language that having canonical, first-party bindings seems important.
There was a bunch of infrastructure work to get to this point: the standard library was ported from Scheme to C++, so the shape bindings are now autogenerated for both target languages and use FFI to call into a dynamic library (with a C API).
Guile supports custom readers through read-hash-extend [1]: this lets you associate specific syntax with a custom reader, triggered by a '#' character. For example, this is how comments are implemented with #! ...multiline comment... !#: the first "#!" triggers a custom reader which reads until the termination.
libfive installs custom readers for #0, #1, #2, and so on, which all do the same thing: store the syntax position (row/column/span), then create a free variable with a particular id that's associated with that syntax position.
When pushing and pulling on the surface, it's solving for free variables values that put the surface at your mouse cursor's position. Then, it can splice those values back into the original script using the row/column/span data from before.
Python does the same thing with a magic `var(...)` function, which is used as the target for an AST transform here:
I'd give cxx a shot. I've only written c bindings but I've heard great things about it.
> This library provides a safe mechanism for calling C++ code from Rust and Rust code from C++. It carves out a regime of commonality where Rust and C++ are semantically very similar and guides the programmer to express their language boundary effectively within this regime. CXX fills in the low level stuff so that you get a safe binding, preventing the pitfalls of doing a foreign function interface over unsafe C-style signatures.
If you're interested in chatting with a random inexperienced student about a month into writing his first Rust bindings I'd enjoy sharing approaches. I'm dzfranklin on the Rust language discord. (If you're not already aware of it the channel #black-magic is great for getting help with unsafe code)
While there are lots of similar efforts, the bidirectional interaction struck me as quit promising; you can apparently push/pull on features and have the Scheme code update.
There also seems to be an emphasis on correctness in the code, which sounds great to anyone who ever tried doing real work in FreeCad, though of course the gap in functionality is vast.
I actually don't know of many similar efforts. The only comparable project to this one is curv [0]
Coding shapes with signed distance fields is, unfortunately, highly impractical for CAD; operations tend to compose poorly (most operations a) assume euclidian space and b) distort space away from euclidian). But it's a pretty nice medium for generative art, and Scheme is a beautiful language to do it in.
libfive is unusual in the SDF space in that it doesn't assume Euclidean space, or even Lipshitz continuity! It uses interval arithmetic, so its evaluation is conservative by construction; shapes with weird SDFs may evaluate more slowly, but they won't be wrong.
This means that you can go wild with geometric and coordinate transformations – even weird things like twisting or attract/repel will work fine.
(the only requirement is C0 continuity, which is the bare minimum; otherwise, a point could be both inside and outside the shape depending on which direction you approach it from)
Is there a paper or more in depth resource for this? I've done continuum mechanics and FEM, but im curious to learn how SDF is unique. The projects looks very interesting!
I'd love to make use of this in various open source projects but as far as I know the Mozilla Public Licence has the same problem as LGPL if you ever want to build for Android or iOS.
You can't mingle MPL/LGPL code with non-copyleft code unless it compiles to a separate binary.
And on iOS/Android - you're forced to have a single signed binary for distribution on the official stores.
Have I misunderstood? I would like to use it in conjunction with Apache licenced code. It feels like I'd be complying with the spirit but not the letter of the licence.
I don't believe the MPL requires the ability to re-link; this is one of the reasons I chose it over the LGPL.
(My intentions are to promote development of the libfive by require changes to the library itself to be shared, while not limiting commercial use / distribution / embedding into a larger application; there is at least one commercial CAD company using libfive as a component in their application)
That's great news. I can think of another project using LGPL but (I suspect) with the same intention as you. I will spread the word the MPL might be a better fit.
Apparently you didn't bother to fully read their comment, or even look at the page. It is a subtracted sphere, meaning it could be any shape contained within a sphere, and the one in question has features that give axes, and to me eye appears to have a strange axial rotation
As a matter of fact I even put my finger up to the screen to verify that the edges were not in any way wobbling. The subtracted shape is a gyroid, which in no way has natural axes, so I beg your forgiveness for still not understanding the question.
I think you are referring to first video on home page while other two are talking about first video on examples page. That example has CSG operations on solids that share the vertical axis so the resulting shape should not wobble.
Yes, wrong side of the bed, I usually sleep on the left, but I definitely was on the right side that day, not that it's pertinent.
I meant what I said, that it appeared that you hadn't bothered to read the page, or to fully read the comment. Your question is talking about a sphere (which can, btw, be rotated "off axis"), while the original comment was indicating one of the subtracted spheres from the page. Any of those subtracted spheres could be rotated off axis. So either you were ignoring a pertinent part of the original comment, or hadn't bothered to look at the subjects that comment was directed towards (either of these scenarios would violate HN guidelines).
Off-axis rotation could mean many things in the context of the original comment, as is pointed out by other responses to your first comment. While it's true that a gyroid has no planar natural axes (by design), a gyroid can have many natural axes, depending on the space it is modelled in and the criteria for axis selection. For example, an axis can be found in the radial symmetry about the center of mass of a gyroid, in an infinite number of planes.
A sphere can also be rotated off axis. If the axis of rotation is not projected across the center of mass of the sphere (rotation would be different than the infinite number of natural axes going through center of mass) is one way. Another way would be if the axis of rotation tended toward one of the COM natural axes at both ends, but was non-linear. Another off axis rotation would be if the axis of rotation was the natural axis, but was not co-planar with the rotation of the viewing axis, which would make it appear to wobble.
>Apparently you didn't bother to fully read their comment, or even look at the page.
Was there a need for this attitude (which, by the way, violates HN guidelines)?
I was looking, not unreasonably, at the linked page. I see that indeed the first example on the "Examples" page exhibits this wobble - thanks to user jmiskovic who was actually helpful.
I'll direct you to my second response to you, where I point out why it appeared from what you wrote that you either hadn't read the original comment fully, or had not examined the subject of that comment. I believe pointing this out was not a violation of HN guidelines, while your negative attitude in multiple comments since then is most definitely in violation.
As far as being helpful, I don't think your first comment falls into that category either.
OpenSCAD is simple and relatively intuitive once you get your head around 3D space and how every object sits in it. The concept - code on the left, visualisation on the right is great. However, it's barely had any improvements in the 8 or so years I've been using it. The tooling is very basic and the performance can be very poor. There's often no way to know if a tiny change will crash (or slow down computation for so long it locks up) the environment (because it doesn't seem to have separation between the render thread and the GUI). Things like fillets, which other CAD environments can do seamlessly, are only possible with a hack which increases rendering time by many orders of magnitude (if it even finishes).
CadQuery seems promising, but in the time I spent with it I found the workplane model quite frustrating. I wanted to write small functional geometries which I could reuse again and again - but I didn't find an easy way to do that. It seems to use global coordinates for all the transformations, so you need to know ahead of time what plane something's on. Maybe I just didn't understand the documentation though - it's incomplete and so you have to piece things together based on examples.
These are of course open source tools, so it's great that they exist at all. In the age of 3D printing, laser cutting and CNC machining fully parametric code based model generation is really exciting.