ASCII .STL Export
|Status:||Fix exists, needs testing||Start date:||03/18/2017|
|Target version:||MakeHuman 1.1.2|
Forum post that makes it seem that there is a problem with the ascii (but not the binary) .stl exporter.
#1 Updated by Rob Baer almost 2 years ago
The .stl specification from http://www.fabbers.com/tech/STL_Format ASCII format section:
"A facet normal coordinate may have a leading minus sign; a vertex coordinate may not."
I'm not sure how strict this specification is, but many of our vertex coordinate "x values" are negated in the ASCII .stl. Could this explain the problems on the left side of the viewport? Does it influence the interpretation of normal direction made by importers?
The ascii and binary specifications are quite different, and without looking at our code it seems feasible that the file generation has been implemented quite differently for the 2 versions of the format.
When looking at face and vertex counts in Blender and meshlab during import of the MH human, we learn the following.
Binary -- 28,796 faces and 86,388 verts initially (3 per face as expected), reduce to 14,444 verts after eliminating duplicates.
What meshlab calls faces, Blender calls tris. But, both report 28,796 faces and 14,444 verts with .dae import and Blender reports the same with .mhx2, .obj, and .fbx import. This coincides with a working binary export/import workflow.
ASCII -- 82,756 faces and 248,268 verts initially (3 per face as expected). reduced to 12,072 after eliminating duplicates. This is consistent with the number of lines in the file when examined with a text editor. There are 579,294 lines in the file with about 7 lines per triangle. The question is why there almost 1 face per vert in the binary file. There also seems to be a massive redundancy that in the end leaves about 2,372 verts missing in the displayed human. Turning on normal display in mesh lab makes it seem the verts are actually missing and not just hidden somehow.
Probably need to check iterators during ASCII stl writing.
I suppose one should wonder whether the duplicate verts that seem to occur even in the binary file export could ulitmately result in downstream problems if not fixed in an app like meshlab. Each vert would seem to have been duplicated about 6 times. I guess this is what would happen if each tri had it edge verts repeated both for itself and its immediate adjacent 3 neighbor tris.
PS Sorry for the comma's - those are not to be confused with European decimal numbers :)
Also available in: Atom