I'm running into an issue when trying to import 3D-scan data. I have the point cloud data in .stl format. When I choose File-->Import-->STL and pick the file, I get the error message "File is corrupt, facet count is zero.". Yes, I know, it is a point cloud... So - how do I import this data? Spent too much time googling without finding any answers, that's why I'm asking you. The only workaround I've found so far is importing point cloud in Catia, save as STL and voilà, it opens in NX (because Catia has created facets).
Solved! Go to Solution.
An STL-file is per definition triangular facets, meaning that the 3D-scan software already have produced the faceted geometry to be imported, hence the STF format/file. Since you are able to import the STL-file into another system there seems to be some sort of unfortunate incompatibility here. I recommend you to file an issue with GTAC to sort things out. Should you have a sample file, feel free to share it here and maybe we can have a go at it to see if there is something we could help you with.
Thanks for the quick reply. I think there is something more to it, since Catia is only able to open the file with a point cloud specific tool, not by doing as when importing a regular .stl-file. I attached a file that causes the error message in NX 12 I mentioned earlier. Check it out and see if you can find out what's going on. I'm gonna check with the 3d-scan departement to see if they can give any useful information of what the file contains.
I had a quick look at the file and it is an ASCII STL file, so I could look at the contents. The data looks OK (although I obviously didn't check all 1.1 million lines ).
To compare I exported an ASCII STL file from NX (8.5) and the format looked the same except your file had some kind of comment on the first and last lines:
solid H:/Skanning/# FORSKNING/180120-21 CAD-underlag för R&D (6st Volvo-detaljer)/31440364 - NoName - Kort/31440364 - NoName - Kort_less_details.stl facet normal 0.208242 0.058747 0.976311 outer loop vertex -457.061096 -67.985909 1054.078125 vertex -456.844482 -68.143898 1054.041382 vertex -456.963745 -66.830841 1053.987793 endloop endfacet ... ... facet normal 0.025491 0.137724 0.990143 outer loop vertex -188.272400 -67.531357 1022.289795 vertex -187.801788 -67.524590 1022.276733 vertex -188.018021 -67.274460 1022.247498 endloop endfacet endsolid H:/Skanning/# FORSKNING/180120-21 CAD-underlag för R&D (6st Volvo-detaljer)/31440364 - NoName - Kort/31440364 - NoName - Kort_less_details.stl
I deleted these 'comments' so the start and end of the file looked like this:
solid facet normal 0.208242 0.058747 0.976311 outer loop vertex -457.061096 -67.985909 1054.078125 vertex -456.844482 -68.143898 1054.041382 vertex -456.963745 -66.830841 1053.987793 endloop endfacet ... ... facet normal 0.025491 0.137724 0.990143 outer loop vertex -188.272400 -67.531357 1022.289795 vertex -187.801788 -67.524590 1022.276733 vertex -188.018021 -67.274460 1022.247498 endloop endfacet endsolid
Then it imported fine.
Dell 7530 Precision, Win10, 32GB. Developing in: Java | C | KF
Production: [NX12.0.2 MP1]
Looking into this further (to see if this warrants a PR ) I found that the stl file format has an optional "name" attribute that can be used for the "solid" and "endsolid" keywords:
facet normal ni nj nk outer loop vertex v1x v1y v1z vertex v2x v2y v2z vertex v3x v3y v3z endloop endfacet
The value of the name attribute must be the same for both keywords. The problem with this particular stl file was that its name contained a German character "ö". It seems that the Import STL code does not allow for UTF-8 characters (not sure if this is limited to ASCII stl files only). I replaced the character with the English equivalent and the stl file opened without any errors.
Out of interest, I set UGII_LANG=German and tried importing the stl, but it still doesn't import:
If you're interested in pursuing this further, I'd suggest opening up an IR with GTAC and requesting an enhancement (ER) to support UTF-8 characters for the name string in ASCII format STL files. Great job on the initial finding @Inch!!