qFarthestAlong not behaving as expected

wickedDesigns

I am working on a FeatureScript which begins by finding the furthest parallel planar face which is part of the same body as a selected planar face.  To do this, I am finding the vector opposite the normal vector of the selected face and using this as the direction for qFarthestAlong; however, debugging this query seems to be showing me the closest plane, not the farthest.  Am I not understanding the expected behavior of qFarthestAlong, or am I doing something else wrong?

Additionally, though less important, does this seem like a reasonable method with which to find the plane I am looking for?  Reading answers to other questions, it sounds like I would be better off not explicitly evaluating queries in my FeatureScript.  Is there a way to find the planar face I am looking for using only queries?

kevin_o_toole_1

Hey all,

Thanks for finding and reporting this. Yes, this is definitely a bug on our end, and looks precisely as you described it: qFarthestAlong is always doing the opposite of what is documented. Passing in the negative vector should always give the correct behavior, and that's the correct fix right now.

Given that the behavior is simply wrong, we will be fixing this bug in a future release. @mahir's point about perhaps not fixing it is well-placed, but we certainly anticipated the need for making small breaking changes like this, and our versioning/upgrading process reflects that need.

Here's the sequence of events w/r/t changes like this:

1. @wickedDesigns and others write code in a custom feature that's dependent on the old behavior.
   
   
2. Onshape releases a new version with the fix, and documents are upgraded.
   
   At this point native features (e.g. extrude) will point to the new latest version of std (and we'll have already done the work on our end to ensure native features behave the same with new versions of the library).
   
   But critically, custom features still point to the old version of std, and the old behaviors are preserved. If you never touch your feature again, it will continue to behave the same way forever, for both existing and new instances of the feature.
   
   
3. Eventually, you may want your custom feature to point to the new version of the standard library (because you want new features, bug fixes, etc). So, you explicitly increase version number on your geometry.fs import to the latest version.
   
   At that point, you'll start getting the new behavior, and it will "break" (because you were relying on the old broken behavior). You'll then need to remove your extraneous negative signs to get the correct behavior back.
   
   
4. Finally, you make a new document version of your custom feature, with both the std upgrade and the associated fixes. Users of your custom feature (who imported the previous version) now also have the choice whether to click the blue icon to update. If they do, they'll now be pointing to a feature which uses the latest std. If they never do, Onshape will preserve their old geometry forever.

The last time we had a breaking change like this, we simplified the way custom valueBounds are defined. This was a breaking change for anyone using the old style of bounds, and all these users needed (or will need) to make minor code changes when upgrading in order for their features to continue working.

Hopefully this structure makes sense. Naturally, this is a pretty embarrassing bug to have, but versioning of CAD and code is something we think quite a lot about at Onshape, and we think this system is the right way to handle it.

mahir

I recreated what you're describing. You can get qFarthestAlong to work the way you want by NOT inverting the face normal vector, but I agree that this isn't how you would expect it to work. It seems to be querying faces in the direction opposite of the direction vector you feed it.

As for finding a better way to do this, I'm sure there are other alternatives, but I don't see anything wrong with doing it this way. In my example evPlane takes all of 1ms to run. No reason to optimize that.

wickedDesigns

Thanks Mahir.  I will use it that way for now.  Should I report this as a bug?

mahir

It wouldn't hurt. Though depending on how many features out there use that particular query, OS may choose not to "fix" it. 

wickedDesigns

I'd love to get some feedback from the designers on whether this is working the intended way or not

mahir

@ilya_baran, what's your take on this?

kevin_o_toole_1

Hey all,

Thanks for finding and reporting this. Yes, this is definitely a bug on our end, and looks precisely as you described it: qFarthestAlong is always doing the opposite of what is documented. Passing in the negative vector should always give the correct behavior, and that's the correct fix right now.

Given that the behavior is simply wrong, we will be fixing this bug in a future release. @mahir's point about perhaps not fixing it is well-placed, but we certainly anticipated the need for making small breaking changes like this, and our versioning/upgrading process reflects that need.

Here's the sequence of events w/r/t changes like this:

1. @wickedDesigns and others write code in a custom feature that's dependent on the old behavior.
   
   
2. Onshape releases a new version with the fix, and documents are upgraded.
   
   At this point native features (e.g. extrude) will point to the new latest version of std (and we'll have already done the work on our end to ensure native features behave the same with new versions of the library).
   
   But critically, custom features still point to the old version of std, and the old behaviors are preserved. If you never touch your feature again, it will continue to behave the same way forever, for both existing and new instances of the feature.
   
   
3. Eventually, you may want your custom feature to point to the new version of the standard library (because you want new features, bug fixes, etc). So, you explicitly increase version number on your geometry.fs import to the latest version.
   
   At that point, you'll start getting the new behavior, and it will "break" (because you were relying on the old broken behavior). You'll then need to remove your extraneous negative signs to get the correct behavior back.
   
   
4. Finally, you make a new document version of your custom feature, with both the std upgrade and the associated fixes. Users of your custom feature (who imported the previous version) now also have the choice whether to click the blue icon to update. If they do, they'll now be pointing to a feature which uses the latest std. If they never do, Onshape will preserve their old geometry forever.

The last time we had a breaking change like this, we simplified the way custom valueBounds are defined. This was a breaking change for anyone using the old style of bounds, and all these users needed (or will need) to make minor code changes when upgrading in order for their features to continue working.

Hopefully this structure makes sense. Naturally, this is a pretty embarrassing bug to have, but versioning of CAD and code is something we think quite a lot about at Onshape, and we think this system is the right way to handle it.