STL loader regex issue

[davdtm]

I think I've found an issue on the STL loader. The parseASCII(data) function parses the content of a STL ascii file, and the problematic line looks the following:

var patternFloat = /[\s]+([+-]?(?:\d+.\d+|\d+.|\d+|.\d+)(?:[eE][+-]?\d+)?)/.source;

it seems that 99.9...% of times it works well, however I have a STL file that contains faces like the following:

text: facet normal 1.29316e-07 3.66792e-08 1
outer loop
vertex -0.1641 -0.5387 -2.152e-08
vertex -0.1813 -0.5195 -2e-08
vertex -0.1881 -0.5446 -1.82e-08
end loop
endfacet

The problems happens when the parser gets the 2nd face vertex, i.e. the line

vertex -0.1813 -0.5195 -2e-08

please note that the Z coordinate does not have the dot. Of course, this should be fine, but the patternVertex.exec( text ) call returns a somehow corrupted result:

-0.1813,-0.5195,-2e

which is finally converted by the final "parseFloat" call to:

-0.1813,-0.5195,-2

In conclusion, what originally was -2e-08 is finally stored as -2 with all the evident consequences. I'm not expert enough on regex expressions to propose a solution, however I'm pretty sure there should be something to fix here

Three.js version

• r87

Browser

• Chrome

OS

• Linux

[Mugen87]

@davdtm Can you please share your mentioned STL file for testing purposes?

[davdtm]

Sorry for my late reply. In attachment you can find a simple cube geometry where I've made two manual changes:

I've changed the X coordinate of the first vertex of the first facet as follows:

from:

vertex 0 0 0.8999999985

to:

vertex 2e-8 0 0.8999999985

and the Z coordinate of the second vertex of the second facet as follows:

from:

vertex 0.06666666542 1 0

to:

vertex 0.06666666542 1 2e-8

I've made a quick check and it seems to me that the first change does not give errors, I see my imported geometry without unexpected vertex displacement. On the other hand, the second change shows the problem, so it seems that the Z coordinate is somehow affected by the problem while the X is not. As I said, I just made a very quick test and I could not swear on what I've stated above. It's just a first impression, hope that this may help.

cube_ascii.stl.gz

[Mugen87]

Thanks for the model! The PR seems to solve the problem. I would appreciate if you can also do a quick test.