-
-
Notifications
You must be signed in to change notification settings - Fork 890
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
Simplify: fix scaling of maximum area deviation setting #1738
Conversation
meshfix_maximum_extrusion_area_deviation is already in millimeters. using get<coord_t> divides the value by 1000, instead it should be get<size_t> or get<int>.
You're right that this is handled incorrectly. Looking at the front end we use even use I will create a front-end PR to make sure that the values in the profiles, match the changes in this PR. I myself wasn't fully aware that when we grab a |
On second thought I'm not sure if the values in the front-end need to change, since currently the translate to a ridiculous high length deviation value. >>> from pint import UnitRegistry
>>> u = UnitRegistry()
>>> width = 400 * u.um
>>> old_default = 50000 * u.um**2 * 1000
>>> old_length_dev = old_default / width
>>> old_length_dev.to("mm")
<Quantity(125.0, 'millimeter')> I will contact @rijkvanmanen or @pkuiper-ultimaker to discuss how they feel about changing the default values in the front-end profiles |
Discussed this with @rijkvanmanen it looks like we use this as a cap in the simplify function; This never came into play due to the insanely high value because of that multiplication with a factor 1000. Even without that factor the impact of this change seems limited but it is good defensive programming imo and correct usage of the intended value. I'm gonna merge this to main, thanks @Piezoid for contributing this fix |
This shouldn't be in 5.2 I think. I've merged it to main now, but we should probably undo it in the 5.2 branch, |
…scaling"" This reverts commit c13760c.
…eviation_scaling"" This reverts commit 70b4fbf.
meshfix_maximum_extrusion_area_deviation
is already in millimeters. Usingget<coord_t>
divides the value by 1000, instead the setting should be acceded withget<size_t>
orget<int>
.I've already signaled and fixed this in #1710, but maybe this simple fix has a chance of making it into the 5.2 release?
The frontend commits that recently changed the default value Ultimaker/Cura@03c88c1 should probably be re-evaluated.