> 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.
naasking 358 days ago [-]
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.
Zopieux 358 days ago [-]
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.
omeid2 358 days ago [-]
The readme is much better, but generally, this kind of CAD is a bit like OpenGL, very few primitives to create crazy staff.
Also, it is written in Haskell, so maybe there is finally some other useful project in Haskell other than the Haskell Compiler, as the joke goes.
Libfive is the closest successor. Blender also starts to support implicit modeling. https://libfive.com/
mytwoscents 358 days ago [-]
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 ;)
ValentinA23 358 days ago [-]
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.
358 days ago [-]
w4rh4wk5 357 days ago [-]
Is there support for rounding / chamfering edges?
I no longer use OpenSCAD because its annoyingly complicated to do for non-trivial shapes.
itishappy 357 days ago [-]
Second example from the repository:
//example2.escad -- A rounded union of a square and a circle.
union(r=14) {
square([80,80]);
translate ([80,80]) circle(30);
}
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?
adfm 357 days ago [-]
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
Centigonal 358 days ago [-]
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.
johnnyApplePRNG 358 days ago [-]
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.
iancmceachern 357 days ago [-]
Solidworks is the same way, I just run windows, it's worth it.
Animats 358 days ago [-]
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.
bmicraft 358 days ago [-]
Okay so this is a from-the-ground-up rewrite of OpenSCAD with a couple of bonus features?
DidYaWipe 358 days ago [-]
"Bet your expecting"
After that I'm not expecting much.
358 days ago [-]
358 days ago [-]
dvh 358 days ago [-]
Not in Ubuntu repository
injidup 356 days ago [-]
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.
358 days ago [-]
Rendered at 10:24:01 GMT+0000 (Coordinated Universal Time) with Vercel.
> 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.
It is entirely possible to write broken software in Haskell.
https://openscad.org
https://www.implicitcad.org/docs/faq
https://github.com/Haskell-Things/ImplicitCAD/blob/master/Ex...
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.
Also, it is written in Haskell, so maybe there is finally some other useful project in Haskell other than the Haskell Compiler, as the joke goes.
https://github.com/Haskell-Things/ImplicitCAD
I no longer use OpenSCAD because its annoyingly complicated to do for non-trivial shapes.
https://www.rhino3d.com/for/jewelry/
Source - Dad was a master jeweler and my parents ran a shop for nearly 40 years
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.
After that I'm not expecting much.