numpy-stl: mesh.from_file throws Assertion Error if matplotlib figure is open when speedups=True
I run into troubles loading .stl files with stl.Mesh.from_file
when there is some instance of matplotlib or Qt running in the same process. That is
import stl
import matplotlib.pyplot as plt
mesh=stl.Mesh.from_file(pathToStlFile)
works great. However, if before initiate a matplotlib figure, that is
plt.figure()
mesh=stl.Mesh.from_file(pathToStlFile)
I get the following Assertion Error
:
File "/usr/local/lib/python2.7/dist-packages/stl/stl.py", line 316, in from_file
fh, mode=mode, speedups=speedups)
File "/usr/local/lib/python2.7/dist-packages/stl/stl.py", line 85, in load
name, data = cls._load_binary(fh, header, check_size=True)
File "/usr/local/lib/python2.7/dist-packages/stl/stl.py", line 102, in _load_binary
count, MAX_COUNT)
AssertionError: File too large, got 909389366 triangles which exceeds the maximum of 100000000
Looking through the code in BaseStl
and reading through this issue https://github.com/WoLpH/numpy-stl/issues/37, I realized that this is due to the fallback if _load_ascii
throws a runtime error such as
File "/usr/local/lib/python2.7/dist-packages/stl/stl.py", line 212, in _load_ascii
return _speedups.ascii_read(fh, header)
File "stl/_speedups.pyx", line 132, in stl._speedups.ascii_read (stl/_speedups.c:2613)
RuntimeError: (0, "Can't read vertex (4:vertex 176.46 176.46 0)")
So it seems that somehow the speedup is not working properly (some Cython clash with Qt/matplotlib?). Turns out that
plt.figure()
mesh=stl.Mesh.from_file(pathToStlFile,speedup=False)
works great. This took me a while to figure out and I thought it might be interesting.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 41 (30 by maintainers)
Commits related to this issue
- working around issue #52 — committed to wolph/numpy-stl by wolph 7 years ago
- Merge tag 'v2.2.1' into develop Added workaround for partially broken speedups (works around #52) v2.2.1 — committed to wolph/numpy-stl by wolph 7 years ago
- Merge tag 'v2.2.2' into develop Added workaround for partially broken speedups (works around #52) v2.2.2 — committed to wolph/numpy-stl by wolph 7 years ago
- Added boundary layer mesh to GUI. The boundary layer meshing is an important and powerful tool to improve simulations of FRAP experiments. To make this functionality available in the GUI, boundaryLay... — committed to alexblaessle/PyFRAP by alexblaessle 7 years ago
- Add a a test for failing sscanf See https://github.com/WoLpH/numpy-stl/issues/52 — committed to hroncok/numpy-stl by hroncok 6 years ago
- Add a a test for failing sscanf See https://github.com/WoLpH/numpy-stl/issues/52 — committed to hroncok/numpy-stl by hroncok 6 years ago
- Merge pull request #94 from hroncok/i52 Fix for issue #52 — committed to wolph/numpy-stl by wolph 6 years ago
Yes, that’s the plan. I’m working on a release as we speak 😃
I’ve just remembered something. This might do with locale. My decimal separator is comma, not a dot. I’ll try reset LC_NUMERIC to C.utf-8 and reproduce. Qt + sscanf + LC_NUMERIC is problematic and cura uses Qt. https://stackoverflow.com/questions/20555696/why-does-qt-change-behaviour-of-sscanf
(cannot test it immediately unfortunately, reporting from my cell phone, as this idea came up while I couldn’t sleep)