stlread returns different numbers of vertices/points

11 visualizaciones (últimos 30 días)
nvmnghia
nvmnghia el 20 de Abr. de 2020
Editada: DGM el 3 de Oct. de 2025 a las 8:58
I'm using MATLAB R2019b. I have to edit a .m file which uses an accompanied stlread(). This one returns a struct stl, and I can use stl.vertices to get the points of the model.
From R2018b onwards, the stlread() and stlwrite() seem to be completely rewritten, returning a triangulation stl. The points are accessed through stl.Points. However, the number of points (as well as the loading time) drastically reduce. This new stlread() loads my sample file 5 times faster, and produces 10 times smaller number of points.
What really changed in the new stlread()? Can I directly modify stl.Points (e.g. rotate the point cloud,...)?

Respuestas (1)

DGM
DGM el 4 de Abr. de 2025
Editada: DGM el 3 de Oct. de 2025 a las 8:58
As far as I know (and I might be wrong), there weren't STL reader/writer tools in the base toolbox until R2018b. At least that's what the release notes say.
If you had a file called stlread() which returned a struct, it was probably this:
As to why it's different, that's just what #22409 does. The STL file doesn't represent the face data as indices into a vertex list. It represents each triangle directly as three points in space. The old #22409 file just reads out all the triangles and stores all the vertices. It doesn't prune the list of duplicates. If you look, you'll have exactly 3x as many vertices as faces. That might be part of why it's slower, but it's probably more likely that the new stlread() is using compiled builtins.
It's worth noting that #22409 does not handle ASCII STL files, and despite having an internal function for throwing an error message when an ASCII file is encountered, the code to detect the encoding type and call that function are disabled. In other words, not only will it not correctly detect the encoding, it won't even try to not decode things it's not capable of decoding, resulting in confusing and misleading errors. I keep a copy around as a reference for things like this, but I never actually use it.
As far as pre-R2018b STL I/O goes, I have recommended FEX #51200 strongly over #22409 and others, but I've since rewritten the core of #51200 as a final improvement on legacy-compatible tools:
The decoders from #51200 and #182013 handle both encodings, and will prune the vertex list and map the face data accordingly. #182013 has more robust type checking, mesh cleanup, and supports some proprietary and nonstandard presentations. It's also significantly faster than #51200 (10-80x binary, 2-3.5x ascii) and #22409 (7-52x binary), though since it's running in m-code, it's still (typically) slower than the built-in tools.

Categorías

Más información sobre Point Cloud Processing en Help Center y File Exchange.

Productos


Versión

R2019b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by