search

tmpvar / stl

parse/serialize stl files
29 stars 7 forks source link

STLs with ASCII description and binary overrunning binary data into description #2

Open stuartpb opened 5 years ago

stuartpb commented 5 years ago

Test case: Download this file and parse it with stl.toObject.

Expected behavior: The object description should be "BRH5-GAUNTLET-LITE", and the rest of the object should contain all the facets defined in the file.

Observed behavior: The object description contains the entire first chunk read.

stuartpb commented 5 years ago

Okay, my initial read of the issue misstated the problem.

I think the bug lies here: when the file is being read in as binary, the description should be truncated at the first null.

tmpvar commented 5 years ago

Hey, sorry it took so long to get my eyes on this. This is basically the dark corner in the STL "spec" and its resolution is ambiguous.

From wikipedia:

A binary STL file has an 80-character header (which is generally ignored, but should never begin with "solid" because that may lead some software to assume that this is an ASCII STL file).

Which is exactly what we are seeing here. Due to the streaming nature of this library, I'm not sure there is a good way to approach this. Here are the constraints that we have to deal with:

So the question is, when do we know that the stl is binary vs ascii when the first bytes are solid?

I think the best course of action here would be to read ahead and make the ascii/binary determination later on when a "facet"/"endfacet" token is reached.

stuartpb commented 5 years ago

Yeah, I mean, the way I was thinking you'd do it is you'd just read the first 81 bytes before emitting anything, and if the 81st character starts a binary STL, that's your clue that the first 80 characters were an ASCII header - it sounds like that's more or less what #4 is set to do.