<div dir="ltr">> <span style="font-size:12.8px">If on the other hand we come up with an interesting way to tie a coding interface that can smoothly and natively integrate code with a 3D gui point and click interface then I think we're really onto something cool and useful that leverages what each type of user interface is good at doing.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">There has also been recent development activity that sounds interesting:</span></div>> <a href="http://dev.opencascade.org/index.php?q=node/1091" rel="noreferrer" style="font-size:12.8px" target="_blank">http://dev.opencascade.org/index.php?q=node/1091</a><br style="font-size:12.8px">> <a href="http://dev.opencascade.org/index.php?q=node/1056" rel="noreferrer" style="font-size:12.8px" target="_blank">http://dev.opencascade.org/index.php?q=node/1056</a><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">> Do those improvements sound like they might address enough of the</span><br style="font-size:12.8px"><span style="font-size:12.8px">> problems you found with OpenCASCADE to make it more interesting?</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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 little bit in the first link. I wonder how long it will take those changes to make it into OpenCASCADE Community Edition (<a href="https://github.com/tpaviot/oce" target="_blank">https://github.com/tpaviot/oce</a>).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">For me, programmatic design is another tool in the toolbox. It's not one-size-fits-all but it's great in certain cases, some of which have been stated in this discussion. I think that CAD scripting, along with a strong GUI, is probably going to give the most power, flexibility and usability.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">I wonder if this similar approach could be successfully applied to solidmodeling programs, that is, skip the declarative stuff for design creation, but use declared rules for verifying the part or assembly (fits, clearance, mold flow thickness, t-stacks, etc).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This is something that Mach 30 is experimenting with now. We have scripted unit tests (done in CadQuery) to verify geometry automatically.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">As a related side note, I wrote a blog post for Mach 30 about my thoughts on the topic of open source CAD. </span><span style="font-size:12.8px">I'd be interested in everyone's thoughts (whether you agree or disagree). <a href="http://bit.ly/m30CADblog" target="_blank">http://bit.ly/m30CADblog</a></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I've missed the last two Hangouts, but I've been keeping up on the reading. If I'm understanding correctly, it sounds like F-Rep is a good fit for some cases, but not the silver bullet that you'd want to use to build a replacement for something like the Solidwork's CAD kernel. Is that what other people are getting out of the discussions so far?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Jeremy</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 12, 2015 at 4:42 PM, Daniel Taub <span dir="ltr"><<a href="mailto:dmtaub@gmail.com" target="_blank">dmtaub@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is a great conversation. I don't have anything to add for the<br>
question at hand except that I prefer hybrid textual-graphical design<br>
tools. For example, I love Rhino.<br>
<br>
FWIW, I'm currently employed by Autodesk writing web-based CAD software for<br>
both physical and electrical design via direct-manipulation/GUI --<br>
"Project Wire" -- <a href="http://www.voxel8.co/software/" rel="noreferrer" target="_blank">http://www.voxel8.co/software/</a><br>
<br>
At one point, we also had some scripting for simple electrical<br>
features like solenoids and interleaved fingers for buttons, but that<br>
was lost in the most recent iteration.<br>
<br>
In my personal projects, I prefer OpenSCAD, so I am also very curious about<br>
scripting for design, both electrical and mechanical.<br>
</blockquote></div><br></div>