qFarthestAlong producing unexpected results

Aaron_Hoover

I have two rectangular bodies intersecting at a right angle, and I've extracted the edges of one of the two large (cap) faces resulting from the intersection. For each of the bodies, I'd like to get the farthest edge that's perpendicular to the long axis of the body. 

I had assumed that passing a direction vector parallel to the long axis of the body (and pointing toward the intersection) to qFarthestAlong would give me that edge. However, the result I get is actually the three edges that are not closest to the center of body. I've tried to capture my results in the image below. 



The vector at the origin of the world coordinate system is the direction vector which is parallel to the long axis of the blue body. Also, if I configure the bodies to meet at an angle greater than 90 degrees, the vector parallel to the long axis of the blue body on the left is not returned by the query, but the one of the right still is. I should also add that calling evDistance between the coordinate system attached to the body and the edges returned by qFarthestAlong gives a larger distance for the edge I want and smaller distances for the other two edges returned. 

What am I misunderstanding about the output of qFarthestAlong?

https://cad.onshape.com/documents/23dc8ff499026deeed6aa19e/w/0031df2b6d633ae1a21ed033/e/017e4642543f95576afa411c

kevin_o_toole_1

Hi Aaron!

qFarthestAlong() considers the furthest extent of every entity, so those two side edges are equally as far along that vector as the end edge. To handle ties like this, qFarthestAlong() just resolves to all entities within length tolerance (1e-8 meters) of being the farthest, so that you can use a different query to break the tie, if needed.

evDistance() measures 3D euclidian distances rather than 1D extents, and without "maximum" set to true, evDistance() considers the closest point of each entity, not the furthest. These two things explain the different results.

If you want your features to work with something that's not a perfect rectangular prism, the right strategy here depends on what you want to do in the general case (like if, say, a notch were cut out of one side, or the edges were filleted). One reasonable place to start is to use evBox3d() on your entities in the cSys you constructed. From there you can easily calculate points to use in qClosestTo() to find your edge, or maybe, forget finding the edge entirely, and instead calculate points to drive your next step directly using the coordinates of that Box3d result.

Let me know if you have more questions!
– Kevin

MBartlett21

@Aaron_Hoover
That is working exactly as it is meant to.
Those edges have an endpoint that is farthest in your direction.
You would then want to filter the lines based on their direction.

kevin_o_toole_1

Hi Aaron!

qFarthestAlong() considers the furthest extent of every entity, so those two side edges are equally as far along that vector as the end edge. To handle ties like this, qFarthestAlong() just resolves to all entities within length tolerance (1e-8 meters) of being the farthest, so that you can use a different query to break the tie, if needed.

evDistance() measures 3D euclidian distances rather than 1D extents, and without "maximum" set to true, evDistance() considers the closest point of each entity, not the furthest. These two things explain the different results.

If you want your features to work with something that's not a perfect rectangular prism, the right strategy here depends on what you want to do in the general case (like if, say, a notch were cut out of one side, or the edges were filleted). One reasonable place to start is to use evBox3d() on your entities in the cSys you constructed. From there you can easily calculate points to use in qClosestTo() to find your edge, or maybe, forget finding the edge entirely, and instead calculate points to drive your next step directly using the coordinates of that Box3d result.

Let me know if you have more questions!
– Kevin

Aaron_Hoover

Thanks, @kevin_o_toole_1! That definitely clarifies the situation. I had assumed that qFarthestAlong() would use the origin of a line representing an edge, but it makes sense that it resolves to the farthest entity. 

I've actually taken a completely different approach to solving the underlying problem (using a Boolean intersection) that doesn't require me to know the exact shape of the intersection. I think it will wind up being far more robust.