Error using fegeometry (*.stl file read)

Hello,

I have been running fegeometry for some time now, importing 2D sections as .stl from Siemens NX. I ran into an instance where fegeometry errored out:

The coordinates of the input points must be finite values; Inf and NaN are not permitted.

I analyzed the .txt version of the .stl file, and it has nonzero geometry, no instances of infinite or NaN values. This is further proven when I perform an stlread(*.stl), which does not error out.

The geometry is complex, it consists of multiple faces. I am able to perform fegeometry with sections consisting of multiple faces, but this one is a doozy. I can't replicate the error elsewhere. I'll continue looking.

[DGM]

Without seeing the file, my guesses are limited. I don't have the PDE toolbox, so I have to use the forum editor. I'll note that it won't open an STL file with degenerate faces. I don't know if that's a change in error messages between versions, but a degenerate triangle will have non-finite face normals.

unzip degen.zip

% degenerate faces removed during write
gm = fegeometry('degen_cleaned.stl')

gm = 
  fegeometry with properties:

       NumCells: 1
       NumFaces: 4
       NumEdges: 6
    NumVertices: 4
       Vertices: [4×3 double]
           Mesh: []

% degenerate faces included, but with zero normals
gm = fegeometry('degen_zeronorm.stl')

gm = 
  fegeometry with properties:

       NumCells: 1
       NumFaces: 4
       NumEdges: 6
    NumVertices: 4
       Vertices: [4×3 double]
           Mesh: []

% degenerate faces included, but with NaN normals
gm = fegeometry('degen_infnorm.stl')

Unable to read the file. Likely, the data does not conform to the STL format specification.

That said, R2018b stlread() will also throw an error if there are degenerate faces with non-finite normals, so that makes me doubt that it's an issue with normals (unless you're using stlread() from FEX #132048 instead of the built-in stlread()).

Some encoders will not write NaN face normals, but they'll replace them with zeros. In that case, they are pruned during import by both stlread() and fegeometry().

Again, I'm just guessing with doubt.

[ZC]

Hi there, thank you for your response.

I spent some more time today trying to replicate this issue for an arbitrary section I am able to share with you.

I was able to create an arbitrary geometry where I also receive this error. Try this:

Answer 1

[DGM]

unzip test1.zip

% reoriented so all normals are facing up
gm = fegeometry('testflipup.stl')

gm = 
  fegeometry with properties:

       NumCells: 0
       NumFaces: 2
       NumEdges: 33
    NumVertices: 33
       Vertices: [33×3 double]
           Mesh: []

% a minimal example of two triangles with opposite normals
gm = fegeometry('testflipminimal.stl')

The coordinates of the input points must be finite values; Inf and NaN are not permitted.

That's weird. You're right. Everything in the file is finite. The two connected objects do have opposite face normals though. I don't know if that's supposed to work, but apparently it doesn't. If I flip them so they're both pointing in the same direction, it works. It doesn't seem to matter which direction, so long as they're both in the same direction. I don't have the tools, so I can't really dig into them to figure out whether that's a bug or just a misleading error message. I don't know how fegeometry handles 2D inputs.

Assuming the other files are simple 2D things like this, you can get consistent orientation like so:

T = stlread('test.stl');
F = T.ConnectivityList;
V = T.Points;
N = faceNormal(T);

% orient all the normals so they're up
mk = N(:,3) < 0; % the normals facing down
F(mk,:) = F(mk,[3 2 1]); % flip those

stlwrite(triangulation(F,V),'testflipped.stl')

[ZC]

Thank you for your answer,

After applying this *.stl file post-processing, the newly written *.stl file is read properly by fegeometry.

[DGM]

I thought about it when I was on my way to sleep. I can't dig though the code, but in a very loose way, the error message may make sense. If there's only one 2D connected group, it can just presume that the triangulation describes the area of a section/object regardless of which direction it's wound. If there are two opposite windings, it's ambiguous. Regardless of which winding is presumed to be solid, the other might be presumed to be a hole. If it's a hole, then the solid area in which it's placed is not defined, and implicitly extends to fill an infinite plane.

Even if that's what's happening, I think the error message could have been more clear.