> Author here. Sorry, I abandoned this two or three years ago. Please look at this in the context of a project done several years ago and never completed.
> Honestly, I no longer believe ImplicitCAD was the right approach to the problem, or that there's even as much of a problem as I originally thought. In particular, the system ImplicitCAD uses to represent objects, a variant of f-rep (http://en.wikipedia.org/wiki/Function_representation) has issues.
ImplicitCAD is unusable, the CSG algorithms it uses are not stable and give horrible results. There is zero chance that you can use it to make engineered objects.
It is entirely possible to write broken software in Haskell.
The Wikipedia page doesn't really describe any issues, so I'm not sure what they're supposed to be or if maybe they've been resolved since that comment was written in 2015.
Try and form a clean ring by subtracting a cylinder from it, you have to dial the resolution so high that it takes minutes to get a result that approximates what you can get min milliseconds in openscad.
The team is not interesting in fixing it and shows a fundamental flaw with how they handle thin intersections. ImplicitCad is sadly nothing more than a non-functioning hobby project and should be labeled as such.
Every time this is posted I look at the "API reference" which sadly is severely lacking. Perhaps the software is actually limited to just a few primitives.
https://build123d.readthedocs.io/ is IMO a much better choice than openscad and implicitcad.
Describing your objects in Python is just how things should be (at least for me ;)
Writing a transpiler targeting OpenScad is trivial, at least the part that is comparable to a markup language. Control flow, arithmetic and datastructures can be handled one level above in the transpiled language, because OpenScad never produces data – you can't ask it to determine the volume of an union for instance – so two way communication between your code and the geometric engine is not an issue. Just like build123d it seems.
So i have recently begun learning jewelry design using blender since there are a lot of videos on it out there but i have this sneaking suspicion i should be learning CAD instead... Thoughts?
If you're learning jewelry design, I'd like to point you towards Rhino, which is popular in the jewelry design community. It's not OSS, but since you're learning, I'll point out that they have a generous educational discount.
There are CAD packages specific to the jewelry industry, they really speed up the work. If you are wanting to do it professionally I'd look into learning those.
Source - Dad was a master jeweler and my parents ran a shop for nearly 40 years
They are both useful skillsets. CAD is nice when you want to manufacture your end result, but you have to think more about constraints and parameters up front.
It's mostly the cost aspect that is preventing me from even exploring the jewelry CAD options... Matrix Gold which is apparently the preeminent CAD software in the jewelry industry... Costs a few thousand dollars and only runs on Windows... Both of which are completely out of touch with my open source Linux setup.
It's really surface vs. volume representations. Blender, Maya, and most 3D graphics programs, define surfaces. Modern 3D CAD programs such as FreeCAD, Fusion, and SolidWorks use constructive solid geometry, where everything is a volume. There are exceptions - SketchUp was a constructive solid geometry program, and original AutoCAD was just lines.
The big difference comes when you combine objects or operate on them. Surface-based programs are not that good at combining surfaces. CSG-based programs have to be really good at combining volumes, including subtracting from them. This requires a very difficult geometry program underneath.
Just use onshape and learn to use their API for creating custom nodes in the history tree. Ie write a small module that generates planetary gears and then use them in the context of a standard, sketch and extrude history based CAD system.
> Author here. Sorry, I abandoned this two or three years ago. Please look at this in the context of a project done several years ago and never completed.
> Honestly, I no longer believe ImplicitCAD was the right approach to the problem, or that there's even as much of a problem as I originally thought. In particular, the system ImplicitCAD uses to represent objects, a variant of f-rep (http://en.wikipedia.org/wiki/Function_representation) has issues.