wolph / numpy-stl

Simple library to make working with STL files (and 3D objects in general) fast and easy.
http://numpy-stl.readthedocs.org/
BSD 3-Clause "New" or "Revised" License
605 stars 103 forks source link

Computing the Max Z-height for double rotation #216

Closed agen49 closed 9 months ago

agen49 commented 9 months ago

Thank ou for the useful tool. When I do double rotation, The Z-height value I get from Numpy-stl is different than the one I get from slicing software(e.g., Cura), may I ask why? Am I doing something wrong?

Rotate # degrees over the Y axis

your_mesh.rotate([0.0, 1.0, 0.0], math.radians(15))

Rotate # degrees over the X axis

your_mesh.rotate([1.0, 0.0, 0.0], math.radians(15))

And I commute the Z-height using:

z_height = your_mesh.z.max() - your_mesh.z.min() z_height

wolph commented 9 months ago

I'm not sure to be honest... your code looks correct and if I try it with a mesh for myself locally it all looks good as well so I've got no clue why it would be different. Especially since Cura uses this library internally ;) https://github.com/Ultimaker/Cura/blob/6002b0aa9d80135eaf3962a9964a5ec7e3623317/requirements.txt#L246-L247

Is the difference large?

agen49 commented 9 months ago

Thanks for the response. The difference is around 25 mm. The discrepancy arises when dealing with double rotation only, a single rotation works as expected.

wolph commented 9 months ago

I'm thinking it might simply be inaccuracies of the rotation process. All numbers are stored as 32 bit floating point according to the STL standard. Long story short, with lossy operations such as rotations this can cause small errors: https://docs.python.org/3/tutorial/floatingpoint.html

Because of this, something as simple as this won't work: 0.1 + 0.1 + 0.1 == 0.3 and every operation you perform can decrease the precision.