Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start: Looking for a certain topic? Check out the categories filter or use Search (upper right).
 Need support? Ask a question to our Community Support category.
 Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
 Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
qFarthestAlong producing unexpected results
Aaron_Hoover
Member Posts: 35 EDU
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
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
Tagged:
0
Best Answer

kevin_o_toole_1 Onshape Employees, Developers, HDM Posts: 565Hi 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 (1e8 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!
– Kevin6
Answers
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.
IR for AS/NZS 1100
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 (1e8 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
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.