Request for some more advanced 2D features.

[emdash]

(edit): I had originally requested some features already covered on the roadmap. I have removed those requests, and will just leave you with the following:

1) Create geometric cross-sections of a solid. This would be useful for exporting drawings to SVG. For example, I might design an enclosure, and then export a cross of the front cover section to an image so that I can import it into an electronics CAD package and use it as a PCB outline.

It would be useful also for creating features that derive from a solid shape. I could take a cross section, project it onto a work plane, and extrude the cross-section.

I have not seen this implemented in any other CAD package.

---

Just want to add that this stuff is actually really cool, and off to a very promising start.

[dcowden]

Thanks for the suggestions!

In the long run, we plan to move from a FreeCAD based backend to a direct pythonOCC implementation. This is a lot of work, but will make some of these operations possible. For example, projecting geometry is possible in OCC.

On Sun, Dec 14, 2014 at 1:00 AM, emdash notifications@github.com wrote:

1) Project geometry onto work-planes

I see from some discussion that this might be a FreeCAD limitation. But I just want to re-iterate that it's an important feature.

2) 2D shell / 2D polygon offset.

The 3D shell operation is really cool. But there needs to be a 2D equivalent. It's a common thing to want to produce lips and flanges that have to mate together and you need to be able to account for tolerances. In the one example of a parametric enclosure that I found, the lip on the cover is produced by subtracting the box itself from it's cover. Obviously this doesn't give you any clearance. The right way to do it is to project the inside edge of the box onto the cover, and then cut away from the cover.

A related operation would be to shell a polygon to a given thickness, rather like the "stroke" command in photoshop.

3) Project a 2D cross-section of a solid onto a work-plane as a geometry.

This is probably less useful than (1) and (2), but it's something that I

have not seen implemented anywhere. It might be a cadquery first.

Just want to add that this stuff is actually really cool, and of to a very promising start.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/61.

[emdash]

I saw that discussion in another open issue. I am curious what your time horizon is for that. It seems like it might be a ways out.

[dcowden]

yeah-- its pretty far out yet. I'm not having a lot of time to devote to this project right now.

On Sun, Dec 14, 2014 at 1:50 PM, emdash notifications@github.com wrote:

I saw that discussion in another open issue. I am curious what your time horizon is for that. It seems like it might be a ways out.

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

[jmwright]

Another thing to keep in mind - Up until recently, the active community consisted of @dcowden and I. Now that a broader community is starting to form, part of what @dcowden and I are interested in is seeing where the community wants to drive CQ in the future. So far it looks like the native PythonOCC implementation is what folks want. It's personally my hope that it stays that way. As @dcowden mentioned though, we're fairly hamstrung by his lack of availability right now. However, we'll continue moving forward, and really appreciate any feedback and help that you can give.

[dcowden]

Other contributors are welcome! I'm definitely not the type to keep control if others can move it forward! It won't take much convincing for me to add folks as committers! On Dec 14, 2014 3:03 PM, "Jeremy Wright" notifications@github.com wrote:

Another thing to keep in mind - Up until recently, the active community consisted of @dcowden https://github.com/dcowden and I. Now that a broader community is starting to form, part of what @dcowden https://github.com/dcowden and I are interested in is seeing where the community wants to drive CQ in the future. So far it looks like the native PythonOCC implementation is what folks want. It's personally my hope that it stays that way. As @dcowden https://github.com/dcowden mentioned though, we're fairly hamstrung by his lack of availability right now. However, we'll continue moving forward, and really appreciate any feedback and help that you can give.

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

[emdash]

I also have limited availability, but I believe that programmatic CAD is the future (and the past, and the present). I see the potential, and I want to see it realized for my own purposes. I am extremely frustrated with the available tools -- both free and not. So I am motivated to contribute. But I would also like to know what your vision is, and try to hew as close to that as possible. I would be open to chatting at some point. I can do IRC / skype / FB / whatever. I'm just glad I'm not the only one out there thinking along these lines.

[dcowden]

that would be awesome! Maybe i'll put together a roadmap document up with initial thoughts-- then we can chat after that.

On Mon, Dec 15, 2014 at 1:27 AM, emdash notifications@github.com wrote:

I also have limited availability, but I believe that programmatic CAD is the future (and the past, and the present). I see the potential, and I want to see it realized for my own purposes. I am extremely frustrated with the available tools -- both free and not. So I am motivated to contribute. But I would also like to know what your vision is, and try to hew as close to that as possible. I would be open to chatting at some point. I can do IRC / skype / FB / whatever. I'm just glad I'm not the only one out there thinking along these lines.

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

[emdash]

Cool, looking forward to it.

[dcowden]

alright i started a roadmap here: https://github.com/dcowden/cadquery/wiki/RoadMap

On Mon, Dec 15, 2014 at 2:02 PM, emdash notifications@github.com wrote:

Cool, looking forward to it.

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

[emdash]

I've read through it, and it all seems reasonable given the discussions. When / where would you like to chat?

[dcowden]

I could do it tonight. I dont do FB any more, so skype works the best. Well actually if you happen to have a google account, then google chat is actually best, but barring that, i guess skype would be 2nd choice.

I'm in the eastern timezone, and could probably do it between about 7pm and 9pm. What TZ are you in?

On Tue, Dec 16, 2014 at 12:24 AM, emdash notifications@github.com wrote:

I've read through it, and it all seems reasonable given the discussions. When / where would you like to chat?

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

[emdash]

Pacific. What's your skype handle?

[dcowden]

alright lets do google. i'm dave.cowden@gmail.com on gmail. what time works well for you?

On Tue, Dec 16, 2014 at 2:01 PM, emdash notifications@github.com wrote:

Pacifc. I can do google or skype. My handle is dotsony on both.

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

[emdash]

I sent you a message, I am free now to about 3:30PM my time, so until like 8:30 your time?

[dcowden]

ok. lets test it now and then i can get with you later tonight.

On Tue, Dec 16, 2014 at 2:21 PM, emdash notifications@github.com wrote:

I sent you a message, I am free now to about 3:30PM my time, so until like 8:30 your time?

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

[dcowden]

Hi, emdash:

I put a new page up here with your selector ideas and some others:

https://github.com/dcowden/cadquery/wiki/Selector--Improvement-Ideas

I think for selectors you can also take much inspriation from jQuery:

http://api.jquery.com/category/selectors/

jQuery selectors work really well. If the feature tree is like a DOM, then most jQuery concepts apply.

On Tue, Dec 16, 2014 at 2:21 PM, emdash notifications@github.com wrote:

I sent you a message, I am free now to about 3:30PM my time, so until like 8:30 your time?

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

[emdash]

I'm not totally convinced the feature tree is exactly like the DOM. The reason is that while the DOM is explicitly created by the HTML in the page, the feature tree in CadQuery is implicitly constructed as the intermediate results of a sequence of operations. I haven't had time to think through the consequences of that.

I guess jQuery does allow you to do kindof the same thing, though. TBH, I don't use jQuery that much.

---

Chaining of selectors needs to happen, but I think it's more complicated than simply ANDing them together. Parsing isn't simply going to be a question of splitting on spaces. We might need a proper parser which can handle various operators (&& || ^), as well as being able to handle grouping via parenthesis.

Right now I am struggling to think of examples where you need this. But I suspect this will come up as people build parametric models of sufficient complexity.

Ideas I like

• tagging objects with IDs. this will be important.
• but we can also assign objects to variables and refer to them that way.

In your example what features get tagged?

• Is it the resulting cylinder that gets the tag (i.e. the solid?), or everything produced?
• What if multiple solids result? Do they all get the same ID?

---

Some additional selectors to include:

• interior of
  • would take a container: a closed wire, face, or solid, and return things interior or exterior to that container.

  • [somecontainer]< # next inner thing

  • [somecontainer]<< # innermost thing

• exterior of
  • <[somecontainer]> # next outer thing
  • <<[somecontainer]>> # outermost thing
• Compass Selector
  • would select things based on the cardinal directions (N,W,E,S,NW...)
  • could take an optional plane-like argument (default is the nearest plane-like parent)
  • directions relative to the coordinate system of that argument (i.e. N is always in the direction of (1, 0) in local coordinates.
  • think this would look something like ".NW"
  • read this to mean "north-west-most thing"
  • so it' really a short-hand for "maximize in the direction of"
• nearest to (solid / point / plane / edge)
  • sometimes you just need to pick an arbitrary object and get the nearest things to it.
  • will be useful for models based on skeletal geometry -- i.e. where the model is constructed from a series of reference planes.
  • will also be needed in situations where there's simply no other way to select what you want -- i.e. all the selectors return no matches or multiple matches, and no combination reliably gets you just the thing you want.
• member of
  • for a vertex, the faces and edges it's a part of
  • for an edge or face, the solids it's part of
  • for a solid, perhaps the larger group or assembly it belongs to.
• siblings / neighbors
  • i.e., for a vertex, the other vertices along the same edges / faces / wires it composes
  • for an edge, the other edges along the same face it composes
  • for a face, the other faces adjacent to it in the same solid

---

---

I think we should change the parallel selector from | to =. | usually means OR in expressions. It's also easily confused with capital i (I vs. |). In some fonts you can't even see the difference. This actually confused me in some examples. I (the letter) is often used to denote a coordinate axis in physics.

---

which symbol do we want to use for negation? Conventional choices include:

• !
• ^
• ~

[emdash]

I like the idea of being able to specify the Nth next face. Maybe we need a generic "nth of" selector that subscripts on the results of any previous selector. Example:

(>>Z){5}

This implies that there's an inherent ordering in the results of a selector. So it only works for things like "in the direction of", or "+Z", but not so much for "parallel to" or "perpendicular to". On the other hand, if some child of a selector introduces an ordering, then you should still be able to subscript. So,

(#XZ && +X){3} makes sense, because the +X introduces an ordering. Where it gets messy is when you have: (X+ && Y+). Which one dominates when there's a tie? How is Y ordered relative to X? We could just use the associativity of the && operator to decide.

But I have a feeling this will be tricky to implement.

[dcowden]

thought it is not exactly the same, cQ's applicablility to a feature tree is still similar enough to jQ/dom to be a useful pattern.

regarding logical operators , AND|OR, etc, lets use jQuery as a model. when you chain selectors together in jQ, the are not really AND/OR, they act as subfilters

I've added these proposed selectors to the wiki page: https://github.com/dcowden/cadquery/wiki/Selector--Improvement-Ideas

On Wed, Dec 17, 2014 at 4:21 PM, emdash notifications@github.com wrote:

I'm not totally convinced the feature tree is exactly like the DOM. The reason is that while the DOM is explicitly created by the HTML in the page, the feature tree in CadQuery is implicitly constructed as the intermediate results of a sequence of operations. I haven't had time to think through the consequences of that.

I guess jQuery does allow you to do kindof the same thing, though. TBH, I

don't use jQuery that much.

Chaining of selectors needs to happen, but I think it's more complicated than simply ANDing them together. Parsing isn't simply going to be a question of splitting on spaces. We might need a proper parser which can handle various operators (&& || ^), as well as being able to handle grouping via parenthesis.

Right now I am struggling to think of examples where you need this. But I suspect this will come up as people build parametric models of sufficient complexity.

Ideas I like

• tagging objects with IDs. this will be important.
• but we can also assign objects to variables and refer to them that way.

In your example what features get tagged?

• Is it the resulting cylinder that gets the tag (i.e. the solid?), or everything produced?
• What if multiple solids result? Do they all get the same ID?

---

Some additional selectors to include:

• interior of
  • would take a container: a closed wire, face, or solid, and return things interior or exterior to that container.

  • [somecontainer]< # next inner thing

  • [somecontainer]<< # innermost thing

  • exterior of
  • <[somecontainer]> # next outer thing
  • <<[somecontainer]>> # outermost thing
  • Compass Selector
  • would select things based on the cardinal directions (N,W,E,S,NW...)
  • could take an optional plane-like argument (default is the nearest plane-like parent)
  • directions relative to the coordinate system of that argument (i.e. N is always in the direction of (1, 0) in local coordinates.
  • think this would look something like ".NW"
  • read this to mean "north-west-most thing"
  • so it' really a short-hand for "maximize in the direction of"
  • nearest to (solid / point / plane / edge)
  • sometimes you just need to pick an arbitrary object and get the nearest things to it.
  • will be useful for models based on skeletal geometry -- i.e. where the model is constructed from a series of reference planes.
  • will also be needed in situations where there's simply no other way to select what you want -- i.e. all the selectors return no matches or multiple matches, and no combination reliably gets you just the thing you want.
  • member of
  • for a vertex, the faces and edges it's a part of
  • for an edge or face, the solids it's part of
  • for a solid, perhaps the larger group or assembly it belongs to.
  • siblings / neighbors
  • i.e., for a vertex, the other vertices along the same edges / faces / wires it composes
  • for an edge, the other edges along the same face it composes
  • for a face, the other faces adjacent to it in the same solid

---

---

I think we should change the parallel selector from | to =. | usually means OR in expressions. It's also easily confused with capital i (I vs. |). In some fonts you can't even see the difference. This actually confused me in some examples. I (the letter) is often used to denote a coordinate

axis in physics.

which symbol do we want to use for negation? Conventional choices include:

• !
• ^
• ~

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

[dcowden]

@emdash, BTW your Remote Cover looks great. if you can make it publicly listed, i'll mark it featured!

On Wed, Dec 17, 2014 at 4:29 PM, emdash notifications@github.com wrote:

I like the idea of being able to specify the Nth next face. Maybe we need a generic "nth of" selector that subscripts on the results of any previous selector. Example:

(>>Z){5}

This implies that there's an inherent ordering in the results of a selector. So it only works for things like "in the direction of", or "+Z", but not so much for "parallel to" or "perpendicular to". On the other hand, if some child of a selector introduces an ordering, then you should still be able to subscript. So,

(#XZ && +X){3} makes sense, because the +X introduces an ordering. Where it gets messy is when you have: (X+ && Y+). Which one dominates when there's a tie? How is Y ordered relative to X? We could just use the associativity of the && operator to decide.

But I have a feeling this will be tricky to implement.

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

[emdash]

I haven't done that because some of the parameters seem to be broken. Like, if I update the boolean "exploded", it doesn't do anything. Also, changing length / width / height seems to have no effect. Haven't had time to figure out if this is something I did wrong or not.

[emdash]

One thought for a convention: use ALL_CAPS to denote parameters. I've been doing that in my current project, and it definitely makes the parameters pop out.

[jmwright]

use ALL_CAPS to denote parameters

Even though there aren't technically constants in Python (that I know of), is there a concern that using all caps might conflict with the general programming convention for constants?

[emdash]

I suppose it could. If you have people re-using existing python code within CadQuery. However:

• I don't see people doing this very often (especially in a web environment)
• Technically, parameters are constants within the script.
• The ALL_CAPS convention comes from C, where ALL_CAPS is used for pre-processor macros (which are sometimes but not always used as constants).
  • Douglas Crockford makes the point that the ALL_CAPS convention evolved because pre-processor macros don't be have like normal identifiers.
  • I.e. the purpose of ALL_CAPS really just to warn you about a dangerous feature of the environment.
  • I consider use of ALL_CAPS to denote a constant harmful.

[jmwright]

I'm closing this because the thread is old and I think everything in it has either been implemented our documented elsewhere.

[dcowden]

Thanks for the cleanup