Re: Which CAD Kernel Should the FOSS and OSHW Communities Focus On?
370 views
Skip to first unread message
Bryan Bishop
Nov 9, 2015, 11:11:22 PM11/9/15
to Jeremy Wright, Bryan Bishop, Open Manufacturing, cad-d...@mit.edu
On Mon, Nov 9, 2015 at 9:59 PM, Jeremy Wright <wrig...@gmail.com> wrote:
1. OpenCASCADE (B-Rep)2. CGAL (F-Rep)3. OpenNURBS (NURBS)
1. OpenCASCADE requires a tremendous amount of work to become high-quality source code that can be regularly maintained without a legion of bored postdocs. The best effort with OpenCASCADE towards this is the "Community Edition" version over here: https://github.com/tpaviot/oce
my notes taken while reading OpenCASCADE source code: http://diyhpl.us/wiki/cad/opencascade/
2. no comments on CGAL
3. OpenNURBS itself is somewhat high quality source code, and BRLCAD wrote a wrapper around OpenNURBS and then implemented the missing surface-surface intersection methods that Rhino kept closed-source:
The BRLCAD team is highly available over freenode IRC in the #brlcad channel during "normal business hours".
Most recently I have been pointing people towards verbnurbs and solvespace:
verbnurbs:
http://heybryan.org/shots/2015-10-25-101304--verbnurbs-com-examples-surfaceIntersection-html-1445785971891.png
solvespace:
I think a verified kernel sounds like a reasonable think to work on, although not necessary for open-source CAD reasons... I think eventually FreeCAD is going to voluntarily switch to either verbnurbs, solvespace or brlcad under the hood instead of OpenCASCADE.
I also think that cadquery does sane things, and I am eager to convince people to write a cadquery interface around the pythonized version of verbnurbs (it uses haxe which apparently cross-compiles to python, but I haven't investigated whether that works or is reasonable).
John Griessen
Nov 9, 2015, 11:34:26 PM11/9/15
to openmanu...@googlegroups.com
On 11/09/2015 10:11 PM, Bryan Bishop wrote:
> I think a verified kernel sounds like a reasonable think to work on, although not necessary for open-source CAD reasons... I think
> eventually FreeCAD is going to voluntarily switch to either verbnurbs, solvespace or brlcad under the hood instead of OpenCASCADE.
I've used solvespace to make some complex parametric shapes and talked with the main developer a bit.
> I think a verified kernel sounds like a reasonable think to work on, although not necessary for open-source CAD reasons... I think
> eventually FreeCAD is going to voluntarily switch to either verbnurbs, solvespace or brlcad under the hood instead of OpenCASCADE.
It is not going to be able to do the fillets between compound surfaces from that developer. He
is also looking for a CAD engine for that purpose. So, I think it is left to verbnurbs or brlcad.
I just used FreeCAD to import an outline from solvespace, sweep it along a rounded corner hexagon path to
make a "hexagonal" tube. Getting the fillets to work ate much time, but the people on the forum were very helpful.
Export to STL is not for sure yet and caused many freeze/crashes attempting to "clean up" the stl using FreeCAD plugins.
Brlcad has seemed crude and laborious when I've tried it, but not having random dead ends happen as
you try to follow a user manual would be nice. Brlcad had no good user manual for making plastic molding parts
with draft angle and smooth fillets everywhere last I tried.
Clifford Yapp
Nov 10, 2015, 9:49:07 PM11/10/15
to openmanu...@googlegroups.com
On Mon, Nov 9, 2015 at 11:11 PM, Bryan Bishop <kan...@gmail.com> wrote:
> 1. OpenCASCADE requires a tremendous amount of work to become high-quality
> source code that can be regularly maintained without a legion of bored
> postdocs. The best effort with OpenCASCADE towards this is the "Community
> Edition" version over here: https://github.com/tpaviot/oce
> my notes taken while reading OpenCASCADE source code:
> http://diyhpl.us/wiki/cad/opencascade/
Data points worth pointing out on OpenCASCADE:
> 1. OpenCASCADE requires a tremendous amount of work to become high-quality
> source code that can be regularly maintained without a legion of bored
> postdocs. The best effort with OpenCASCADE towards this is the "Community
> Edition" version over here: https://github.com/tpaviot/oce
> my notes taken while reading OpenCASCADE source code:
> http://diyhpl.us/wiki/cad/opencascade/
As of 6.7.0 their license is now LGPLv2.1:
http://www.opencascade.com/content/licensing - this is game changing
in some ways, since a standard license allows them (and programs that
use them) to be included in major Linux distributions.
There has also been recent development activity that sounds interesting:
http://dev.opencascade.org/index.php?q=node/1091
http://dev.opencascade.org/index.php?q=node/1056
Do those improvements sound like they might address enough of the
problems you found with OpenCASCADE to make it more interesting?
> Most recently I have been pointing people towards verbnurbs and solvespace:
>
> verbnurbs:
> https://github.com/pboyer/verb
> https://github.com/pboyer/verb/blob/master/src/verb/eval/Intersect.hx
> http://verbnurbs.com/
> http://verbnurbs.com/examples/surfaceIntersection.html
> http://heybryan.org/shots/2015-10-25-101304--verbnurbs-com-examples-surfaceIntersection-html-1445785971891.png
that perform compared to C/C++ for this application? Could it be
translated to C++, perhaps in combination with OpenNURBS?
> solvespace:
> http://solvespace.com/index.pl
> https://github.com/whitequark/solvespace/blob/for-upstream/src/srf/surfinter.cpp
> https://github.com/whitequark/solvespace
available. This is of course like the SISL products - GPL has to be
workable for your application to be able to use them. Glad to see
them making progress. Does it support any import/export options
besides its own file format?
CY
Bryan Bishop
Nov 11, 2015, 12:39:32 PM11/11/15
to Matt Carney, Bryan Bishop, Open Manufacturing, Jeremy Wright, cad-d...@mit.edu, Daniel Bergey
On Wed, Nov 11, 2015 at 11:24 AM, Matt Carney <mca...@media.mit.edu> wrote:
As an example/challenge: please find me an example of a scripted machine that's more complicated than some laser cut 2D parts, or static 3d printed object.
Just off the top of my head...
robotic arm:
https://thingiverse-production-new.s3.amazonaws.com/assets/32/38/e4/5a/93/RoboArm.scad
automatic transmission:
automatic transmission:
5-cylinder radial engine (single part?)
rover (although this looks mostly 3d printed?):
http://www.thingiverse.com/thing:10057/#files
There are also many OpenSCAD versions of reprap on github, although I don't know which one is relatively recent, last I looked there were some good openscad scripts for prusa reprap but surely that's legacy tech by now.
Also, I think that AutoCAD's autolisp used to be popular back in the day. It was my understanding that many complex machines were specified with piles of lisp scripts? These days I would expect the equivalent to be VBA I guess, since nobody knows lisp in the modern office.
Nancy Ouyang
Nov 11, 2015, 1:43:56 PM11/11/15
to Open Manufacturing, Matt Carney, Bryan Bishop, Jeremy Wright, cad-d...@mit.edu, Daniel Bergey
I program and I CAD.
Very few people seem to argue for text-based circuit-board design, and I only know of one person who designs circuits that way.I don't follow that in 3D things are more amenable to programmatic design. It's certainly possible, but I don't feel that not having a GUI should be a goal.
Very interested to hear more about the CAD kernels.
Thanks,
--Nancy
--You received this message because you are subscribed to the Google Groups "Open Manufacturing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openmanufactur...@googlegroups.com.
To post to this group, send email to openmanu...@googlegroups.com.
Visit this group at http://groups.google.com/group/openmanufacturing.
For more options, visit https://groups.google.com/d/optout.
John Griessen
Nov 11, 2015, 2:46:35 PM11/11/15
to openmanu...@googlegroups.com
On 11/11/2015 12:43 PM, Nancy Ouyang wrote:
> I don't follow that in 3D things are more amenable to programmatic design. It's certainly possible, but I don't feel that not
> having a GUI should be a goal.
I think Nancy has a huge point about CAD. I've done mechanical and chip layout and circuit design and layout.
> I don't follow that in 3D things are more amenable to programmatic design. It's certainly possible, but I don't feel that not
> having a GUI should be a goal.
For 3D or even 2D visual design things from mech to chip design,
There is occasional productivity block that needs some programming, but almost always that
program will be better launched by a GUI than from commands in a visual design setting.
OpenSCAD is nice for mathematical shapes, but try to make a mold for plastic with draft angles
and rounded corners everywhere... That's a simple set of rules to apply, yet wold go nutty
trying to code generate and position it all.
Solvespace for 2D and 3D is incomplete as far as STEP and STL output and fails rendering sometimes,
but has a truly fine GUI for designing parametrically and visually.
I'm using some of its output with freecad and reduction with meshlab to get decent results
Bryan Bishop
Nov 11, 2015, 3:06:04 PM11/11/15
to Nancy Ouyang, Bryan Bishop, Open Manufacturing, Matt Carney, Jeremy Wright, cad-d...@mit.edu, Daniel Bergey
On Wed, Nov 11, 2015 at 12:43 PM, Nancy Ouyang <nancy....@gmail.com> wrote:
Very few people seem to argue for text-based circuit-board design, and I only know of one person who designs circuits that way.
There's millions of lines of source code written in Verilog/VHDL available on github, or http://opencores.org/ is an interesting starting point.
Bryan Bishop
Nov 20, 2015, 5:17:42 PM11/20/15
to Jeremy Wright, Bryan Bishop, Clifford Yapp, Nancy Ouyang, John Griessen, Matt Carney, Open Manufacturing, cad-d...@mit.edu
On Tue, Nov 10, 2015 at 8:20 PM, Clifford Yapp <clif...@gmail.com> wrote:
> http://dev.opencascade.org/index.php?q=node/1091
> http://dev.opencascade.org/index.php?q=node/1056
>
> Do those improvements sound like they might address enough of the
> problems you found with OpenCASCADE to make it more interesting?
> http://dev.opencascade.org/index.php?q=node/1091
> http://dev.opencascade.org/index.php?q=node/1056
>
> Do those improvements sound like they might address enough of the
> problems you found with OpenCASCADE to make it more interesting?
License situation improvement has been good news. I am negative on long-term maintainability of the source code, the low quality of source code, and the lack of tests is unfortunate and makes developing much more difficult. OCE cleans up a few things but by my estimate only a small small tiny slice of the whole pie. Some of this seems even beyond the territory of refactoring; way more progress can be made starting from higher-quality source code.
> I'm somewhat surprised to see verbnurbs is in javascript - how does
> that perform compared to C/C++ for this application? Could it be
> translated to C++, perhaps in combination with OpenNURBS?
verbnurbs is written in haxe, which is apparently a tool that can generate C++ from haxe source code input:
http://haxe.org/
OpenNURBS integration is doable if you compile to C++ first, but I suspect there would be minimal benefit to be had by doing so. A few years ago I was doing a (private/unreleased) rewrite of OpenNURBS in python because why not, and I found that most of it is somewhat trivial, especially since Rhino didn't release the intersection functions. So if you find some value in the OpenNURBS library that is missing from verbnurbs, I would recommend porting the features into verbnurbs directly. Alternative implementations of the surface-surface intersection methods have been written by the BRL-CAD crew, although I have not looked at whether that work is completely redundant with verbnurb's implementation of surface-surface intersection.... this would be a good thing to know, check and figure out.
http://haxe.org/
OpenNURBS integration is doable if you compile to C++ first, but I suspect there would be minimal benefit to be had by doing so. A few years ago I was doing a (private/unreleased) rewrite of OpenNURBS in python because why not, and I found that most of it is somewhat trivial, especially since Rhino didn't release the intersection functions. So if you find some value in the OpenNURBS library that is missing from verbnurbs, I would recommend porting the features into verbnurbs directly. Alternative implementations of the surface-surface intersection methods have been written by the BRL-CAD crew, although I have not looked at whether that work is completely redundant with verbnurb's implementation of surface-surface intersection.... this would be a good thing to know, check and figure out.
> I don't follow that in 3D things are more amenable to programmatic design.
> It's certainly possible, but I don't feel that not having a GUI should be a
> goal.
> It's certainly possible, but I don't feel that not having a GUI should be a
> goal.
Well, when I think about these problems, I approach them from a separation-of-concerns angle, that is to say that the GUI implementation should be independent of the CAD kernel. The GUI implementation is somewhat harder to write if you do not have a specification for the data types, input and output of the CAD engine. So usually when it seems like I am deprioritizing GUI, that's usually because I figure that scripting and APIs and SDKs are faster to implement on top of the same imaginary CAD kernel that the GUI would then be written against.
On Wed, Nov 11, 2015 at 1:46 PM, John Griessen <jo...@industromatic.com> wrote:
> OpenSCAD is nice for mathematical shapes, but try to make a mold for plastic
> with draft angles
> and rounded corners everywhere... That's a simple set of rules to apply,
> yet wold go nutty
> trying to code generate and position it all.
I wonder how much of that is an API problem. I suspect you would have the same difficulties in current versions of cadquery, freecad python, or pythonocc. "If the API doesn't help you reach your goals in a simple and easy manner, then that's a bug."
On Thu, Nov 12, 2015 at 3:07 PM, Matt Carney <mca...@media.mit.edu> wrote:
> Though I still don't see anything of sufficient detail or complexity
Yeah I admit those weren't great examples. I have often considered using one of these scripting languages to show off and make a giant mecha robot or gundam mobile suit with reasonable technological resolution beyond simply "here are some boxes intersecting each other to resemble the popularized image". The point would be to dump some time into a group where the participants are working, perhaps modularly, on open-source CAD scripting a moderately complex mechanical or mechatronic project.
On Fri, Nov 20, 2015 at 3:28 PM, Jeremy Wright <wrig...@gmail.com> wrote:
> This is something we've discussed doing with CadQuery. The CadQuery script
> would basically be the file format, but you could use mouse interaction in
> the GUI exclusively if you wanted to. This model adds other challenges
> though as autogeneration and manipulation of code can get messy/complex.
One way to do this would be an interactive interpreter or REPL for the source code, and then the GUI responds to keypresses (like tabs) to highlight possibilities. Thomas Paviot did some videos of how this works with pythonocc and ipython:
https://www.youtube.com/watch?v=mnQ1IqfjsCs
Perhaps non-coding input would just be stored as an additional STEP file, which would then be imported into the script mode, to avoid auto-generated code bloat. "Then the magic happens" can be hidden away.
> From what I'm hearing, it seems like the issue might be with the quality and
> maintainability of the OpenCASCADE codebase, which seems to be addressed a
Correct. But that's just my assessment, don't let me stop you from looking:
http://diyhpl.us/wiki/cad/opencascade/
> little bit in the first link. I wonder how long it will take those changes
> to make it into OpenCASCADE Community Edition
> (https://github.com/tpaviot/oce).
Not long. Months at most.
> This is something that Mach 30 is experimenting with now. We have scripted
> unit tests (done in CadQuery) to verify geometry automatically.
Could you link to some of those files please?
- Bryan
http://heybryan.org/
On Thu, Nov 12, 2015 at 3:07 PM, Matt Carney <mca...@media.mit.edu> wrote:
> Though I still don't see anything of sufficient detail or complexity
Yeah I admit those weren't great examples. I have often considered using one of these scripting languages to show off and make a giant mecha robot or gundam mobile suit with reasonable technological resolution beyond simply "here are some boxes intersecting each other to resemble the popularized image". The point would be to dump some time into a group where the participants are working, perhaps modularly, on open-source CAD scripting a moderately complex mechanical or mechatronic project.
On Fri, Nov 20, 2015 at 3:28 PM, Jeremy Wright <wrig...@gmail.com> wrote:
> This is something we've discussed doing with CadQuery. The CadQuery script
> would basically be the file format, but you could use mouse interaction in
> the GUI exclusively if you wanted to. This model adds other challenges
> though as autogeneration and manipulation of code can get messy/complex.
One way to do this would be an interactive interpreter or REPL for the source code, and then the GUI responds to keypresses (like tabs) to highlight possibilities. Thomas Paviot did some videos of how this works with pythonocc and ipython:
https://www.youtube.com/watch?v=mnQ1IqfjsCs
Perhaps non-coding input would just be stored as an additional STEP file, which would then be imported into the script mode, to avoid auto-generated code bloat. "Then the magic happens" can be hidden away.
> From what I'm hearing, it seems like the issue might be with the quality and
> maintainability of the OpenCASCADE codebase, which seems to be addressed a
Correct. But that's just my assessment, don't let me stop you from looking:
http://diyhpl.us/wiki/cad/opencascade/
> little bit in the first link. I wonder how long it will take those changes
> to make it into OpenCASCADE Community Edition
> (https://github.com/tpaviot/oce).
Not long. Months at most.
> This is something that Mach 30 is experimenting with now. We have scripted
> unit tests (done in CadQuery) to verify geometry automatically.
Could you link to some of those files please?
- Bryan
http://heybryan.org/
Reply all
Reply to author
Forward
0 new messages