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

Fri Nov 20 22:43:11 EST 2015

> Could you link to some of those files please?

Sure.

https://opendesignengine.net/projects/yavin-thruster/repository/entry/trunk/tests/chamber/test_cad.py

As you can see from the assert at the bottom, the geometry tests aren't
implemented yet. The time so far has been spent building the infrastructure
and test datasets, but the tests will be taking shape over the next few
weeks. The CadQuery unit tests give some simple examples of checking
geometry, and I also want to add a volume test since the geometry is for a
3D printed part.

https://github.com/dcowden/cadquery/blob/master/tests/TestCadQuery.py#L268

On Fri, Nov 20, 2015 at 5:17 PM, Bryan Bishop <kanzure at gmail.com> wrote:

> 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/164d4c29/attachment.html