[Cad] Which CAD Kernel Should the FOSS and OSHW Communities Focus On?

[Bryan Bishop]

On Tue, Nov 10, 2015 at 8:20 PM, Clifford Yapp <cliffyapp at 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?

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.

On Wed, Nov 11, 2015 at 12:43 PM, Nancy Ouyang <nancy.ouyang at gmail.com>
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.

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 <john at 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 <mcarney at 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 <wrightjmf at 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/
1 512-203-0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/cad-rg/attachments/20151120/967cb032/attachment-0001.html