efficiently groove down center of a face

adamohern

Let's say I want to run a groove down a long rectangular face. I can easily achieve that by requiring the user to select three faces: the face for the groove, and the two adjacent (perpendicular) faces. With the perpendicular faces I can easily find a midplane and build my groove from there.

Is there a way to be smarter about it, not requiring the user to select three faces? Could I, for example, select only the groove face and then somehow reliably find a midplane without the perpendicular faces? What if the edges are rounded?

kevin_o_toole_1

One decently robust strategy that's had success for others is to orient everything with respect to the longest linear edge of the face.
From there, you can make a coordinate system out of the edge and the face, take a bounding box of the face, and calculate any other positions you need based on that.

In the cases where that heuristic isn't correct, you can add a boolean to flip it 90º, and/or an option to provide another edge (really any ALLOWS_AXIS) as the primary axis, replacing the longest linear edge above.

adamohern

This is roughly what I expected. Would it be possible to evaluate the face with any edge rounds removed? In other words, can I somehow get the intersection between the groove face and the adjacent planar faces, ignoring any edge rounds that may or may not exist?

kevin_o_toole_1

I assume the edge case you're talking about is where two sides of the face have differently sized fillets, and you still want to make the groove down the center w/r/t the adjacent sides?

For the specific case of ignoring one fillet, you could write logic around evEdgeConvexity or qTangentConnectedFaces to do the job... for instance, look among the planar faces which are edge-adjacent or tangent connected to the given face.

However, I wouldn't think it'd be very robust. Certainly, it wouldn't work if you replace the fillets with chamfers. Maybe we could make a query for faces which are perpendicular and adjacent-for-a-broader-definition-of-adjacent, but even then, there may be useful cases where those faces just aren't there, like if there's a draft involved.

Basically, it does come down to what you care about when defining the groove, and whatever those references are, I usually prefer having them passed in, and not relying on query magic to infer them. That way, the dialog provides good documentation about what the feature does... or at least, it will once we start putting labels in there properly!

I see a few options:

1. Using the face center, as above
2. Using the part center
3. Using a specified distance from a face or edge
4. Using the center of two faces, as you currently have

So maybe an enum which switches between some subset of these methods?

Of course, I'm talking about trying to make a general-purpose feature that other people understand. If your goal is to improve your own workflows and you know the set of possible topologies well, the optimization you're talking about sounds useful.

adamohern

Selecting all three faces isn't a huge deal, specifically if (ahem) we get an auto-advance field functionality so that clicking one face advances the field selection to the next field in the feature definition dialog. Then it'd be just click-click-click done.