Libfive: Solid modeling (CAD) library/tools with Scheme/Python bindings and GUI
libfive.com
libfive.com
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).
#if defined (__alpha) || defined(DECOSF1)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.
The site isn't totally up to date – the Python bindings + API are brand new, and need some examples, but they work great if you know how to use them!
Either way I should probably close https://github.com/libfive/libfive/issues/206 ?
Surprised to be hearing about this here instead of via that issue closing :p
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).
This sounds like a bug, please open a Github issue and I'll investigate.
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:
https://github.com/libfive/libfive/blob/master/libfive/bind/...
[1] http://www.gnu.org/software/guile/manual/guile.html#Reader-E...
If anyone wants to help that would be appreciated heaps.
> 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)
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.
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.
Outside of art and black holes and stuff, of course.
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)
https://www.mattkeeter.com/research/mpr/
https://news.ycombinator.com/item?id=26873691
There's also a good Twitter thread here:
https://twitter.com/CasualEffects/status/1385389913881858054
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)
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.
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.
As far as being helpful, I don't think your first comment falls into that category either.
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.