Computing the Max Z-height for double rotation

[agen49]

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

[Rick van Hattem]

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]

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.

[Rick van Hattem]

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.