-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Making largestDimension work as expected #317
Conversation
Nevermind on issue 2. My brain was stuck thinking in terms of 2d vectors, not 3d. 1.76 is correct for a 3d diagonal of a 3d unit cube. |
The value returned now errs on the side of being very slightly larger, which is probably good considering this method's main use it to find the distance for thru cuts.
Reworked the code a little bit which now gives a slightly larger answer. It seems that this method was just created to serve thru cuts by returning a distance that would be sure to be through the object. I think that's where the multiplication by 5 came in. It was was a hard coded overkill value to make sure it always returned a value that was long enough. That's fine when all it does is thru cuts. However, when you try to use this function to aid in setting something like camera distance, it gives the wrong answer. It now gives a correct (and intuitive) answer, while not breaking the tests for thru cuts. |
Codecov Report
@@ Coverage Diff @@
## master #317 +/- ##
=======================================
Coverage 95.38% 95.39%
=======================================
Files 19 19
Lines 4701 4709 +8
=======================================
+ Hits 4484 4492 +8
Misses 217 217
Continue to review full report at Codecov.
|
@adam-urbanczyk It's a small-ish change, but could potentially impact thru cuts. Probably worth a quick check before I merge, even though I know you're busy with OCP. |
Thanks @jmwright ! |
WIP - do not merge.
Intended to address #266 but I've run into a couple of issues.
largestDimension
is used for automatically determining hole depth. I don't think the original method was doing this correctly, and I need to get this sorted out before this PR is viable.Ex:
cadquery/cadquery/cq.py
Line 2347 in 6ecb0fc
I think that's a reason that only the bounding box of the first solid was checked. You wouldn't want the hole depth to be based on all the solids in a compound (or would you?). In any case, I suspect the original implementation was kind of a hack to get hole depth to work properly. I need to think about this a bit to figure out how to refactor the code for hole depth.
Thoughts and guidance welcome.
@adam-urbanczyk @greyltc