Future CQ Development

[jmwright]

There has been some informal discussion about making CQ work with multiple kernels, and I'd like to try to get a conversation started on the nuts and bolts of doing that.

[jmwright]

It seems like for maximum benefit the feature tree, this AST work, and the code/feature highlighting in the GUI all need to be done in concert. They don't have to be tightly coupled, just developed in parallel so that they can inform each other's development process.

[emdash]

I think the feature tree comes first. At least, that's the part that in my mind I have the least understanding of. It seems that there needs to be two or three parallel trees:

1) The input tree, which defines the model in terms of BREP primatives and operations. This is what results directly from evaluating the python code. 2) The output tree is what we actually send to PyOCC. 3) Possibly an intermediate tree between 1) and 2) which would track the intermediate objects that result from processing the input tree. May be needed for implementing some of the selectors, for example.

Also, the input tree is really a graph. A given node can appear in multiple places.

[jmwright]

I've started experimenting with possible components for the new CQ GUI, and want to get some feedback from the ground up. I've created a short video where I do a test drive of the 3D viewer that's embedded with PythonOCC so that all of you can comment on how it works and looks. As @emdash has pointed out in this discussion, solid 3D viewer interaction is a must-have in CAD software.

The video is very poor quality. I did it in one take with no prep. The purpose of the video was to let the CQ community see the viewer and comment on it, not make quality content.

The first comment I have is that the right click and drag to zoom seems redundant (already taken care of with the mouse wheel). I would also like to reserve the right click for the code interaction features that we hope will be an integral part of the new CQ GUI. I'll wait to make more comments to give others a chance to chime in.

If you want to test drive this PythonOCC 3D viewer yourself, you can use the pythonocc_oce_setup script on any Ubuntu 14.04 flavor. Then you can run the example from the directory that I show in the video.

[dcowden]

I watched the video-- that viewer would certainly be good enough to start with. I agree that right click would be good to use for menus and stuff.

I'm interested in the edge/face selection. If it does that, it could be really useful. If we tracked a map of what CQ features produced which edges/faces, we could use edge/face selection to select subfeatures in the feature tree, and maybe even highlight the code that produced that feature.

On Sat, Mar 7, 2015 at 11:54 PM, Jeremy Wright notifications@github.com wrote:

I've started experimenting with possible components for the new CQ GUI, and want to get some feedback from the ground up. I've created a short video http://youtu.be/Z54LUHjwEgU where I do a test drive of the 3D viewer that's embedded with PythonOCC so that all of you can comment on how it works and looks. As @emdash https://github.com/emdash has pointed out in this discussion, solid 3D viewer interaction is a must-have in CAD software.

The video is very poor quality. I did it in one take with no prep. The purpose of the video was to let the CQ community see the viewer and comment on it, not make quality content.

The first comment I have is that the right click and drag to zoom seems redundant (already taken care of with the mouse wheel). I would also like to reserve the right click for the code interaction features that we hope will be an integral part of the new CQ GUI. I'll wait to make more comments to give others a chance to chime in.

If you want to test drive this PythonOCC 3D viewer yourself, you can use the pythonocc_oce_setup https://github.com/jmwright/pythonocc_oce_setup script on any Ubuntu 14.04 flavor. Then you can run the example from the directory that I show in the video.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-77733282.

[jmwright]

Yeah, the face/edge selection caught my attention too. The source code also seems to support vertex selection, but it doesn't work in the viewer. Shouldn't be hard to add that support though.

[emdash]

This is really exciting. I am going to take a look when I get home. :)

On Sun, Mar 8, 2015 at 9:42 AM, Jeremy Wright notifications@github.com wrote:

Yeah, the face/edge selection caught my attention too. The source code also seems to support vertex selection, but it doesn't work in the viewer. Shouldn't be hard to add that support though.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-77760109.

[jmwright]

Started an issue on pythonocc-core about bundling PythonOCC and OCE within an application. That way I can share any work being done on the new CQ GUI mock-up more easily.

[jmwright]

I don't have OCE embedded, but I put together a proof-of-concept UI using PyQode (the FreeCAD module's editor), the OCCViewer, and PySide.

I'm probably only 4 to 8 hours away from having a decent GUI that will execute straight PythonOCC code and render it in the viewer. That state of the GUI would allow us to experiment with the PythonOCC port of CQ easily, but probably won't do us much good until we have time to work on that port.

[emdash]

This is actually really good news. When the GUI is functional, I can start tinkering with PyOCC in my off-time. The goal would just be to get a feel for the library at first, and then eventually contribute to the task of re-implementing the CQ API.

While I like the CQ concept, the shortcomings of the current implementation (the lack of polygon offsetting for proper clearances, in particular) really limit what I can use CQ for. At least this way, I can get back to constructing models programmatically, even if the API is a little verbose. I think I would learn a lot from doing at least a few projects directly in PyOCC.

One thing that I really need is a way to render translucent objects. I've found that this is really important for evaluating model features, especially when you are trying to create interlocking parts, and thin-shelled solids. It can also be a useful tool for debugging programmatic CAD. I.e. you can have translucent representations of intermediate shapes, like OpenSCAD.

--Brandon

On Wed, Mar 18, 2015 at 11:45 AM, Jeremy Wright notifications@github.com wrote:

I don't have OCE embedded, but I put together a proof-of-concept UI using PyQode (the FreeCAD module's editor), the OCCViewer, and PySide.

[image: cq_experimental_gui] https://cloud.githubusercontent.com/assets/1015439/6716546/9ec3aa0e-cd7c-11e4-8386-acc65529f662.png

I'm probably only 4 to 8 hours away from having a decent GUI that will execute straight PythonOCC code and render it in the viewer. That state of the GUI would allow us to experiment with the PythonOCC port of CQ easily, but probably won't do us much good until we have time to work on that port.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-83117865.

[jmwright]

One thing that I really need is a way to render translucent objects.

@emdash The current release of the CQ module for FreeCAD allows you to set and render part colors and transparency. The OCCViewer is supposed to support this as well

[emdash]

Right, what I'm saying is that making sure this works in the OCC viewer would be key.

On Wed, Mar 18, 2015 at 2:10 PM, Jeremy Wright notifications@github.com wrote:

One thing that I really need is a way to render translucent objects.

@emdash https://github.com/emdash The current release of the CQ module for FreeCAD allows you to set and render part colors and transparency. The OCCViewer is supposed to support this as well

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-83178068.

[jmwright]

OK, got it. Thanks.

[emdash]

It's been a while since there was an update on this issue.. How are things going?

[dcowden]

Hi there:

In short, not much. I've been pulled off onto other projects for a bit. @jmwright has been making progress on a pythonOCC branch of CQ, but its also been slow going.

On Mon, Jun 1, 2015 at 7:54 PM, emdash notifications@github.com wrote:

It's been a while since there was an update on this issue.. How are things going?

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-107749058.

[emdash]

Is his work public? If so, I wouldn't mind a link to it.

[dcowden]

sure, hes working on the pythonocc branch of cadquery:

https://github.com/dcowden/cadquery/tree/pythonocc

On Mon, Jun 1, 2015 at 8:00 PM, emdash notifications@github.com wrote:

Is his work public? If so, I wouldn't mind a link to it.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-107749772.

[emdash]

Thanks, I'll take a look when I get home :)

--Brandon

On Mon, Jun 1, 2015 at 5:10 PM, Dave Cowden notifications@github.com wrote:

sure, hes working on the pythonocc branch of cadquery:

https://github.com/dcowden/cadquery/tree/pythonocc

On Mon, Jun 1, 2015 at 8:00 PM, emdash notifications@github.com wrote:

Is his work public? If so, I wouldn't mind a link to it.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-107749772.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-107750854.

[jmwright]

That branch is me experimenting with a PythonOCC implementation that lives along side the FreeCAD implementation. It's not an attempt to implement any of our more advanced ideas, it's just a direct port. I got enough experience with PythonOCC to contribute a port of the classic OCC bottle example to pythonocc-core, but just got bogged down after that. With @dcowden busy, I'm the main contributor right now and don't have the free time to keep the current version moving forward, and do the PythonOCC impl too. Here's some more if our conversation in this - https://github.com/dcowden/cadquery/issues/89

I was building the TestPythonOCC test up as I wrote the implementation, so that would be the place to start. The test covers pythonocc_impl/geom only for right now.

[emdash]

OK. I am still interested in potentially contributing, but I am wondering what the next stop on the roadmap would be. OCC has a ridiculously verbose API, I've noticed. I have this feeling that really only a small fraction of it is relevant to a project like CadQuery, and I'd be curious to read any notes you might have on it.

--Brandon

On Mon, Jun 1, 2015 at 6:01 PM, Jeremy Wright notifications@github.com wrote:

That branch is me experimenting with a PythonOCC implementation that lives along side the FreeCAD implementation. It's not an attempt to implement any of our more advanced ideas, it's just a direct port. I got enough experience with PythonOCC to contribute a port of the classic OCC bottle example to pythonocc-core, but just got bogged down after that. With @dcowden https://github.com/dcowden busy, I'm the main contributor right now and don't have the free time to keep the current version moving forward, and do the PythonOCC impl too. Here's some more if our conversation in this - #89 https://github.com/dcowden/cadquery/issues/89

I was building the TestPythonOCC test up as I wrote the implementation, so that would be the place to start. The test covers pythonocc_impl/geom only for right now.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-107760129.

[dcowden]

I support the pythonOCC direction. Yes the API is very verbose. But its attractive because its the only game in town that provides low-level access to all of the features of OpenCascade-- which is the most capable O/S kernel available.

FreeCAD (FC) is limiting. Though existing CQ is decent, many of the things we would need to do next are not available in FC. @jmwright has spent some time asking them for changes, and they are not receptive at all to contributions and new ideas. They border on downright uncooperative. In short, we've both concluded that if CQ needs to grow, it will be very slow as long as FC is underneath. PythonOCC, in contrast, is supported by two folks who are super helpful and responsive, and willing to accept contributions. Thomas and Jelle are both super excited, and would accept contributes to pythonOCC from us in a second. I've even considered making CQ part of pythonOCC.

Most of the other possible directions involve using one of many CSG kernels. My gut feeling is that these will ultimately make matters even worse than using pythonOCC, because things that need to be easy, like filleting and extrusion, become a lot more work in CSG. There's a reason why all of the top professionally used CAD packages are BREP based and not CSG based.

Its not ideal, but i think its the best strategy.

On Tue, Jun 2, 2015 at 11:54 AM, emdash notifications@github.com wrote:

OK. I am still interested in potentially contributing, but I am wondering what the next stop on the roadmap would be. OCC has a ridiculously verbose API, I've noticed. I have this feeling that really only a small fraction of it is relevant to a project like CadQuery, and I'd be curious to read any notes you might have on it.

--Brandon

On Mon, Jun 1, 2015 at 6:01 PM, Jeremy Wright notifications@github.com wrote:

That branch is me experimenting with a PythonOCC implementation that lives along side the FreeCAD implementation. It's not an attempt to implement any of our more advanced ideas, it's just a direct port. I got enough experience with PythonOCC to contribute a port of the classic OCC bottle example to pythonocc-core, but just got bogged down after that. With @dcowden https://github.com/dcowden busy, I'm the main contributor right now and don't have the free time to keep the current version moving forward, and do the PythonOCC impl too. Here's some more if our conversation in this - #89 < https://github.com/dcowden/cadquery/issues/89>

I was building the TestPythonOCC test up as I wrote the implementation, so that would be the place to start. The test covers pythonocc_impl/geom only for right now.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-107760129.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-107997972.

[emdash]

Just wrapping up a project that should give me a little more time to tinker with CadQuery. I got the pythonocc_oce_setup script to build on an ubuntu VM. But I'm a little confused about what needs to happen next. It sounds like @jmwright has a different branch that I should be messing with?

[jmwright]

@emdash - Check out the pythonocc branch. https://github.com/dcowden/cadquery/tree/pythonocc?files=1

It's got a cadquery/pythonocc_impl directory, and I started in geom.py. It's pretty rigged in its current state. I was just building and running the tests manually as I went. There's no integration with the wider library yet because it will throw all sorts of import errors because the implementation isn't complete.

Let me know if you have questions.

[emdash]

Just one. Are you available on-line at all this week to help me get bootstrapped on it?

--Brandon

On Tue, Jun 30, 2015 at 9:20 PM, Jeremy Wright notifications@github.com wrote:

@emdash https://github.com/emdash - Check out the pythonocc branch. https://github.com/dcowden/cadquery/tree/pythonocc?files=1

It's got a cadquery/pythonocc_impl directory, and I started in geom.py. It's pretty rigged in its current state. I was just building and running the tests manually as I went. There's no integration with the wider library yet because it will throw all sorts of import errors because the implementation isn't complete.

Let me know if you have questions.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-117430161.

[jmwright]

This week's pretty booked. I might be able to on Sunday evening.

[jmwright]

@emdash Did you ever get a chance to start experimenting with PythonOCC?

[emdash]

I kindof played with the viewer, but I haven't had time to get into PythonOCC itself.

[emdash]

I'll add that I finished a big project that I was doing, and now I have some more free time, and some lighter-weight projects, so this might be a relatively good time to try fiddling with it.

[jmwright]

Cool.

[jmwright]

This discussion has been moved to the new Google Group since it's long-running and not directly related to an issue in the codebase. https://groups.google.com/forum/?hl=en&nomobile=true#!topic/cadquery/AahXUjscM10

If you're a participant in this discussion, please join the group so that we can continue the discussion there.

[jmwright]

@emdash and @dcowden Can you guys give some more specifics on the keypad idea above? I'm experimenting with another GUI framework, and want to try that idea out. I use a 3D mouse when I do CAD, and I have the two buttons on it set up to switch to the isometric view and zoom to fit. I would like to have both of those operations still available with the keypad.

I was thinking that button 5 might be front view, then the other keys would be as follows. If you hit them once they just snap you to that view, but if you hold them down they could keep rotating the view. Maybe holding down on 5 or pushing it multiple times could toggle you between the front and back views?

8 - top view 4 - left side view 6 - right side view 2 - bottom view

7 - top left ISO 8 - top right ISO 1 - bottom left ISO 3 - bottom right ISO

There are also the mathematical operation keys. Maybe I can attach the zoom to fit operation to one of those?