Is it possible that the triangle's normal is automatically calculated from vertices? (using righthand orientation)

Added a test for it in this pr #2

I'm including a couple of example files. When trying to read these files, they fail with either of the following messages.

expected 0 or normal f32, got 0.000000000000000000000000000000000000000000001

invalid facet header.

After some investigation I discovered that this was only happening to ASCII files with CRLF (Windows style) line endings.

ASCII-CRLF-STLs.zip

The licensing has changed in the Cargo.toml file without a new release being published.
We blacklist GPL 3 in cargo deny so we cannot use it without a new release with Apache & MIT license.
Would it be possible to make a new release?

I get the following error when reading this ASCII STL file.

expected 0 or normal f32, got 0.000000000000000000000000000000000000000000001

5_overhang_test.stl.zip

I'm not exactly sure what is going on. Looks like it's having trouble with some of the values in this file.

I've been using this library with great pleasure, and have made heavy use of the validate functionality. However when using this function for larger models (4mil tris) this function becomes extremely slow. That is because the validate function runs in O(n^2). If we were to only check on indices, instead of vertex location we could improve this function to run in linear time, see example below.

pub fn validate(indexed_mesh: &stl_io::IndexedMesh) -> Result<(), std::io::Error> {
    let mut unconnected_edges: HashMap<(usize, usize), (usize, usize, usize)> = HashMap::new();

    for (fi, face) in indexed_mesh.faces.iter().enumerate() {
        for i in 0..3 {
            let u = face.vertices[i];
            let v = face.vertices[(i + 1) % 3];
            // Verify that all vertices are different.
            if indexed_mesh.vertices[u].approx_eq(&indexed_mesh.vertices[v], F32Margin::default(),) {
                return Err(::std::io::Error::new(
                    ::std::io::ErrorKind::InvalidData,
                    format!(
                        "face #{} has identical vertices #v{} and #v{}",
                        fi,
                        i,
                        (i + 1) % 3
                    ),
                ));
            }

            if unconnected_edges.contains_key(&(v, u)) {
                unconnected_edges.remove(&(v, u));
            } else {
                unconnected_edges.insert((u, v), (fi, i, (i + 1) % 3));
            }
        }
    }

    if let Option::Some((fi, i1, i2)) = unconnected_edges.values().into_iter().next() {
        Err(::std::io::Error::new(
            ::std::io::ErrorKind::InvalidData,
            format!(
                "did not find facing edge for face #{}, edge #v{} -> #v{}",
                fi,
                i1,
                i2
            ),
        ))
    } else {
        Ok(())
    }
}

Would you accept a pull request for this? alternatively, if you would really like to keep the point location checking (instead of indices checking) I believe we can do some thing similar using trees that would run in O(n log n) but that would be a bit more complex.

The github master has a fix in it that resolves a invalid facet header panic in 0.6.0 of the benchy STL - it would be awesome to get a new version released with that fix.

The troubling STL in question: https://www.thingiverse.com/thing:763622/files

PS. Not sure what's up with the benchy STL but it also broke another Rust parser (nom_stl) as well as this JS implementation: https://github.com/cloud-cnc/unified-3d-loader

PPS. You used to come by Hacklab back when it was on Baldwin St right? Very cool to have stumbled across a fellow hacklabber through a random crates.io search - small world! ^_^

Hi, I may be missing it in the docs and the source, but is there a way to quickly lookup the number of triangles in the stl without counting the triangles in the indexed vector? This value is usually in the stl header. Thanks!

See subject.

Consider this STL:

solid foobar
facet normal -0.18070563127347375 -0.18070563127348263 -0.966794160952634
  outer loop
    vertex -820.4898663002201 -815.9185131898234 -194.9565426805985
    vertex -816.6170868866257 -823.439521166454 -194.2746442247123
    vertex -822.3139805817382 -817.7426274713415 -194.27464422471235
  endloop
endfacet
endsolid foobar

This works. Now we add a space to the solid name:

solid foo bar
facet normal -0.18070563127347375 -0.18070563127348263 -0.966794160952634
  outer loop
    vertex -820.4898663002201 -815.9185131898234 -194.9565426805985
    vertex -816.6170868866257 -823.439521166454 -194.2746442247123
    vertex -822.3139805817382 -817.7426274713415 -194.27464422471235
  endloop
endfacet
endsolid foo bar

This falls over in when parsing endsolid with an "invalid facet header" panic.
How do we know endsolid is the culprit? Because the next example works even though the solid names in beginsolid and endsolid do not match:

solid foo bar
facet normal -0.18070563127347375 -0.18070563127348263 -0.966794160952634
  outer loop
    vertex -820.4898663002201 -815.9185131898234 -194.9565426805985
    vertex -816.6170868866257 -823.439521166454 -194.2746442247123
    vertex -822.3139805817382 -817.7426274713415 -194.27464422471235
  endloop
endfacet
endsolid foobar

I have a request for my program to take input from stdin (which is not seekable) instead of a file. As it stands, I must read all the STL data into a buffer that implements Seek, before passing it to create_stl_reader. It would be nice if this requirement could be removed.