CadQuery / cadquery

A python parametric CAD scripting framework based on OCCT
https://cadquery.readthedocs.io
Other
3.11k stars 286 forks source link

Cannot Select Edges in Nth Direction #551

Closed jmwright closed 3 years ago

jmwright commented 3 years ago

This question is related to the PR here.

This may be related to some of the discussion around direction selectors lately, but the bottom two (seemingly coplanar) edges in the diagram he provides are seemingly invisible to the direction Nth selector. I've tried experimenting with the tolerances of the selectors as well, and cannot get them to be filtered properly. Can anyone figure out what I'm missing? Here's where I stopped at after doing several experiments.

import cadquery as cq

hookHeight = 50
width = 50
thickness = 2.5

result = (cq.Workplane("XY")
.moveTo(-width/4,1).lineTo(0,hookHeight).lineTo(width/4,1)
.lineTo(width/4+5,0).lineTo(-width/4-5,0).close()
.extrude(thickness*1.5)).edges(">Y[-1]").fillet(0.2)

show_object(result)
marcus7070 commented 3 years ago

I think you are running into exactly this issue https://github.com/CadQuery/cadquery/issues/531.

String selector ">Y[N]", aka. DirectionNthSelector, first runs the object list through ParallelDirSelector. So the first thing that selector does is filter out all edges not parallel to (0, 1, 0) (which filters out every edge in that example).

I'll submit some code to that PR to fillet the desired edges now.

On Thu, 24 Dec 2020 at 09:35, Jeremy Wright notifications@github.com wrote:

This question is related to the PR here https://github.com/Irev-Dev/curated-code-cad/pull/12.

This may be related to some of the discussion around direction selectors lately, but the bottom two (seemingly coplanar) edges in the diagram he provides are seemingly invisible to the direction Nth selector. I've tried experimenting with the tolerances of the selectors as well, and cannot get them to be filtered properly. Can anyone figure out what I'm missing? Here's where I stopped at after doing several experiments.

import cadquery as cq hookHeight = 50width = 50thickness = 2.5 result = (cq.Workplane("XY") .moveTo(-width/4,1).lineTo(0,hookHeight).lineTo(width/4,1) .lineTo(width/4+5,0).lineTo(-width/4-5,0).close() .extrude(thickness*1.5)).edges(">Y[-1]").fillet(0.2) show_object(result)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/CadQuery/cadquery/issues/551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AL7HNIIHU6Y64RAUHQIV4HDSWJZS3ANCNFSM4VHRCY2A .

Irev-Dev commented 3 years ago

Hey,

What I'm proposing here is an entirely different feature set from selectors (I can make it into it's own issue if you like?), but it relates to being able to fillet specific edges.

I've been playing around with a couple of different code-CAD packages lately. and CadQuery's selectors feature certainly is a unique and valuable feature, But I also really like that CascadeStudio taps into a "Sketch" functionality and I'm able to fillet points as I define them. here's an example making the same bird house as the PR @jmwright mentioned. Since both CascadeStudio and CadQuery use OpenCascade under the hood maybe it could be replicated and maybe worth adding?

Side note, there's similar functionality in OpenSCAD with the right libraries (uses a [x, y, radius] API).

jmwright commented 3 years ago

@Irev-Dev I do think what you're proposing would be worth discussing in its own issue.

marcus7070 commented 3 years ago

But I also really like that CascadeStudio taps into a "Sketch" functionality and I'm able to fillet points as I define them. here's an example making the same bird house as the PR @jmwright mentioned. Since both CascadeStudio and CadQuery use OpenCascade under the hood maybe it could be replicated and maybe worth adding?

That looks like a 2D fillet? If so, we have an issue to track that. https://github.com/CadQuery/cadquery/issues/348 It would be a really nice addition.

adam-urbanczyk commented 3 years ago

@jmwright would you agree that this is a duplicate of #531 ?

jmwright commented 3 years ago

@adam-urbanczyk I think it probably is.