Skip to content
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

Losing digits when write ASCII stl file #192

Closed
gregnordin opened this issue Apr 2, 2022 · 4 comments
Closed

Losing digits when write ASCII stl file #192

gregnordin opened this issue Apr 2, 2022 · 4 comments

Comments

@gregnordin
Copy link

The current BaseStl._write_ascii method in stl/stl.py uses a format string, %f %f %f, on lines 312-316 to write normal and vertex values, resulting in output like the following in an ascii STL file for a single facet:

facet normal -0.000000 -0.000000 0.000000
  outer loop
    vertex 0.000000 0.000100 0.000025
    vertex 0.000000 0.000000 0.000000
    vertex 0.000000 0.000000 0.000025
  endloop
endfacet

Can the format string be replaced by %e %e %e to ensure that small numbers do not lose precision? My application is focused on geometric features in the micron range (1e-6 meter), and I'm constrained to use ascii stl files.

Besides this issue, I am loving the flexibility that numpy-stl gives me to manipulate stl files--thank you so much for a great project!

@wolph
Copy link
Owner

wolph commented May 13, 2022

Apologies for the slow response, I've been rather busy :)

With regards to increasing the precision I'm slightly worried that some libraries will not support the scientific notation which would break backwards compatibility.
Additionally, I think a larger problem is that the library currently defaults to the binary STL format which limits precision to 32 bit floating point numbers. So I doubt that this fix will make any real difference...

As a quick fix you can try right now, you could do:

import numpy
from stl import Mesh

Mesh.dtype = numpy.dtype([
    ('normals', numpy.float64, (3, )),
    ('vectors', numpy.float64, (3, 3)),
    ('attr', numpy.uint16, (1, )),
])

That would increase the precision from 32 bit to 64 bit which is likely to solve your issue. But it will break compatibility with binary STL files which are standardized to 32 bit precision

@gregnordin
Copy link
Author

gregnordin commented May 14, 2022

Thanks for the response. No problem about not changing things. For my use case I just edit the numpy-stl package in my virtual environment to use the format string in my original post, and specify ascii mode when I use mesh.Mesh.save. This allows me to do everything I need, which is to load an STL file, sort it's faces, and write sorted faces to separate ascii STL files that I use to create a 3D mesh with labelled faces for computational fluid dynamics simulations with OpenFOAM.

Thanks again for a great package!

@wolph wolph closed this as completed in 906ff9c May 14, 2022
wolph added a commit that referenced this issue May 14, 2022
Made sure floating point numbers are not truncated. Fixes #192 v2.17.1

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEFJMl/RWQTpxOuJ6V6BRE6c4faV0FAmJ/0nkACgkQ6BRE6c4f
# aV3nKBAAm+wyiJHQjcIOVJFyI7ArV4JYlAmnZHyY7nuYAzXuZSogXXJvYWC47HRc
# gXqjeT8MblU29/7bChXY0ya/9wDXs1r1o+9DLVXRgrb+mZ2nqImfaSWvSmUSQ7A+
# 7YFwmCjDxpOF3NrdW/QTpOeMys/dvFndcYoXUz1sx2PtzeB5Oy9vsmw4EcCi9Cno
# O+RKBiJDtVjSkB/PdjSX7ilgDY3bInwlO4LCdVNkLV5K97QB3nXGdSak/yFUkUsb
# xKmYoyjRQgNaGurbCfdHTqQBP85Y4IFU6kzHeDRncYePpdCIRUmm98xSoqyVNsaa
# 2wZZABmIUpGrogCfiN78RrBOeYaZt2L9uJa2iWxEWFyMAqRgX7oGMRtu6bK+EIUO
# 0I/yQXVefNMYNSVZ0vmiXLhMSBEXcj5SrXL1k/yfEWjsCKi0CQjiB23pzpC3olnz
# CYjgyUWyD2x/yf09yIr8z0kK+T043+c9VrAhuUjrmwvQRPR68akT8//CCQ5fkt2/
# hiBYSW6ydofylznQo89DjNOxwD3F/fyZay1nT96c6ob7tkadSYSZh0Dfg7tKxAYA
# vpuEWmPAtRz9ktK+l5FMZ1oYxawuk2FXe2FQe20XClCrIy53PtmMXpQuGR9dcY2C
# pTZq0C+Ko++CxLJ572rBKaGpayphdY8kG50YeM4/x6ZCne9//O0=
# =U6RF
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat May 14 18:02:01 2022 CEST
# gpg:                using RSA key 149325FD15904E9C4EB89E95E81444E9CE1F695D
# gpg: Good signature from "Rick van Hattem <[email protected]>" [ultimate]
# gpg:                 aka "[jpeg image of size 9662]" [ultimate]
@wolph
Copy link
Owner

wolph commented May 14, 2022

I've done a bit more research and you're definitely right, by default %f loses precision. But I found a fix that does not appear to lose any precision: use %r instead.

Can you test if this fixes your issue?
I've created a new release with the fix included so a pip3 install -U numpy-stl should do the trick.

@gregnordin
Copy link
Author

I just tested using %r and it works great! Thank you so much!

wolph added a commit that referenced this issue Dec 14, 2022
Made sure floating point numbers are not truncated. Fixes #192 v3.0.0

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEFJMl/RWQTpxOuJ6V6BRE6c4faV0FAmOZV7AACgkQ6BRE6c4f
# aV2AhxAAmoKOIowi8XpVMTqZgIewdInV583cas72aMpPeVkUklMC8M8qKMLXsFwm
# KkIHwNWMDV5PDZskkENxrZ26pwJTywQJT32j6TFHBqkolYo2cpjNUNVZ2ns3nKfH
# iXFGnYrOTNQINOkQGgBWLGQSqBps9lxTV2ol9QahRT0h8gR7dVc+k5QmZzf6yvI3
# idUKqXW0U76wr9T6vJPg+ayZUqakCcWI2Hr8i60396MJhWJiqQzx3kiR4EwdnppV
# 7cPxr5hD5WVriwn2u1zNhe6a/wgg+XX26R7PmzFboClCu5jdXq4XgiLPDxjZXPEv
# /FyTybF6voFfCsO+md8GVaZusl6kkYCwEQY/FNL6rE4hzWIV6Fr4gqSPYAfr75Q1
# IQR3/ibnNw4dI5/A5UCLN1mz43fo3rUg5jwCoAUUjlnhwJDYnXMbLUCyh81xSN5L
# 7+DA5n5VMSTWQZFN1fkIZVEGrxHGuuEBEewbzOYUCeslc467ID3ZvRUiiA7I2r0O
# vLQaYSCg23emsOKHFCmyyHPkCdQOrtEHD0ITDeA++F8esHkrr48HWqpr13Qcjazs
# r0oH2eMBV9XoRaaTQix2qqdx3tDtefXg4+NhWlX6TQJCQjJnAvf++wT2tEpT4XuE
# 0m9Kz2d/ngUPyB+8ur+t5VES70AXq+XHpVP90y6zIuRop3PdggI=
# =AjOw
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed Dec 14 05:57:20 2022 CET
# gpg:                using RSA key 149325FD15904E9C4EB89E95E81444E9CE1F695D
# gpg: Good signature from "Rick van Hattem <[email protected]>" [ultimate]
# gpg:                 aka "[jpeg image of size 9662]" [ultimate]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants