Empathy List Archives

NH

nop head

Sat, Apr 18, 2020 8:48 AM

There are normals in STL files but a lot of applications ignore them and
compute their own.

In the case of OpenSCAD it converts STLs to PolySets that don't have
normals. Then it converts it to nef_3 format for CGAL and presumably CGAL
calculates its own normals.

On Sat, 18 Apr 2020 at 09:13, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

On Fri, Apr 17, 2020 at 05:21:43PM +0200, arnholm@arnholm.org wrote:

On 2020-04-17 15:37, Torsten Paul wrote:

On 17.04.20 06:33, guaranteed_interwoven wrote:

Also seeing:
Error !!!!!!!!!!!!!!!!!!!!!!!

In the terminal. What sort of error message is that?

That you have to ask the CGAL people:

https://github.com/CGAL/cgal/blob/master/Nef_3/include/CGAL/Nef_3/polygon_mesh_to_nef_3.h#L75-L106

Or you could read that code. It says the face normal is a null
vector after computing it with Newell's Method. It means there is a
triangle in the STL that is collapsed. Bad message, but that it what
it means. That can probably be fixed using one of the repair tools.

So it is a zero area triangle. Hmm.

I went ahead and improved the error message. I created a pull request,
and I was told it was accepted. (I don't see it under the link above).

But I thought STLs had normal vectors inside them and that the vector
compared there was from the file. You're saying it is computed and
indicates a zero-surface-area triangle?

     Roger.

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

There are normals in STL files but a lot of applications ignore them and compute their own. In the case of OpenSCAD it converts STLs to PolySets that don't have normals. Then it converts it to nef_3 format for CGAL and presumably CGAL calculates its own normals. On Sat, 18 Apr 2020 at 09:13, Rogier Wolff <R.E.Wolff@bitwizard.nl> wrote: > On Fri, Apr 17, 2020 at 05:21:43PM +0200, arnholm@arnholm.org wrote: > > On 2020-04-17 15:37, Torsten Paul wrote: > > >On 17.04.20 06:33, guaranteed_interwoven wrote: > > >>Also seeing: > > >>Error !!!!!!!!!!!!!!!!!!!!!!! > > >> > > >>In the terminal. What sort of error message is that? > > > > > >That you have to ask the CGAL people: > > > > > > > https://github.com/CGAL/cgal/blob/master/Nef_3/include/CGAL/Nef_3/polygon_mesh_to_nef_3.h#L75-L106 > > > > Or you could read that code. It says the face normal is a null > > vector after computing it with Newell's Method. It means there is a > > triangle in the STL that is collapsed. Bad message, but that it what > > it means. That can probably be fixed using one of the repair tools. > > So it is a zero area triangle. Hmm. > > I went ahead and improved the error message. I created a pull request, > and I was told it was accepted. (I don't see it under the link above). > > But I thought STLs had normal vectors inside them and that the vector > compared there was from the file. You're saying it is computed and > indicates a zero-surface-area triangle? > > Roger. > > > -- > ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 > ** > ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** > The plan was simple, like my brother-in-law Phil. But unlike > Phil, this plan just might work. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

CA

Carsten Arnholm

Sat, Apr 18, 2020 8:50 AM

On 17.04.2020 23:28, guaranteed_interwoven wrote:

Thank you for the help! This is driving me nuts. I used to be able to do
this sort of thing with OpenSCAD all day long and never run into an issue.

floor.stl http://forum.openscad.org/file/t2594/floor.stl

union()
{
translate([0, 0, 6])
scale([0.9842519685, 0.9842519685, 1])
import("floor.stl");
cube([50, 50, 6]);
}

See the fix here, including original bad file + repaired file
https://gist.github.com/arnholm/49c52c130240184460668c281e8307c2

In summary this was fixed easily using AngelCADs polyfix.

$ polyfix floor.stl

Parameters:
input_file = floor.stl

polyhedron 0 ================= volume=10890.5, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=92100 faces=30700
warning: 1 zero area faces.
warning: nonmanifold edges: uc(1)=92100
merged 76748 vertices
removed 1 collapsed or zero area face
split 1 face
total changes=76750
no warnings

iteration 1: vertices=15352 faces=30700
total changes=0
no warnings

Summary:
polyhedron 0: vertices=15352 faces=30700 : no warnings

Writing: floor_1.stl

... polyfix finished, time used: 0d 00h 00m 01s

It detected one zero area face which was removed, another face was split
in 2 parts. After that the repaored file had no warning and was imported
into OpenSCAD and "F6'ed" without any problems

Carsten Arnholm

On 17.04.2020 23:28, guaranteed_interwoven wrote: > Thank you for the help! This is driving me nuts. I *used* to be able to do > this sort of thing with OpenSCAD all day long and never run into an issue. > > floor.stl <http://forum.openscad.org/file/t2594/floor.stl> > > union() > { > translate([0, 0, 6]) > scale([0.9842519685, 0.9842519685, 1]) > import("floor.stl"); > cube([50, 50, 6]); > } > See the fix here, including original bad file + repaired file https://gist.github.com/arnholm/49c52c130240184460668c281e8307c2 In summary this was fixed easily using AngelCADs polyfix. $ polyfix floor.stl Parameters: input_file = floor.stl polyhedron 0 ================= volume=10890.5, dtol=0.01, atol=1e-06, maxiter=10 iteration 0: vertices=92100 faces=30700 warning: 1 zero area faces. warning: nonmanifold edges: uc(1)=92100 merged 76748 vertices removed 1 collapsed or zero area face split 1 face total changes=76750 no warnings iteration 1: vertices=15352 faces=30700 total changes=0 no warnings Summary: polyhedron 0: vertices=15352 faces=30700 : no warnings Writing: floor_1.stl ... polyfix finished, time used: 0d 00h 00m 01s It detected one zero area face which was removed, another face was split in 2 parts. After that the repaored file had no warning and was imported into OpenSCAD and "F6'ed" without any problems Carsten Arnholm

CA

Carsten Arnholm

Sat, Apr 18, 2020 8:54 AM

On 18.04.2020 00:42, MichaelAtOz wrote:

Self intersections, via NetFabb:
http://forum.openscad.org/file/t359/floor-si-Capture.jpg
Note also the thinner triangles to the left.
Unfortunately my Meshlab is crashing when I try anything with it...

Carsten?

https://gist.github.com/arnholm/49c52c130240184460668c281e8307c2

Not every repair tool behaves the same. In this case there were 2
offending faces, one collapsed face and another one needing to be split
in order to make the model 2-manifold.

Looks like Meshlab does not account for one of those (I didn't try).
Polyfix fixed it with ease in this case.

Carsten Arnholm

On 18.04.2020 00:42, MichaelAtOz wrote: > Self intersections, via NetFabb: > <http://forum.openscad.org/file/t359/floor-si-Capture.jpg> > Note also the thinner triangles to the left. > Unfortunately my Meshlab is crashing when I try anything with it... > > Carsten? https://gist.github.com/arnholm/49c52c130240184460668c281e8307c2 Not every repair tool behaves the same. In this case there were 2 offending faces, one collapsed face and another one needing to be split in order to make the model 2-manifold. Looks like Meshlab does not account for one of those (I didn't try). Polyfix fixed it with ease in this case. Carsten Arnholm

CA

Carsten Arnholm

Sat, Apr 18, 2020 9:02 AM

On 18.04.2020 10:12, Rogier Wolff wrote:

But I thought STLs had normal vectors inside them and that the vector
compared there was from the file. You're saying it is computed and
indicates a zero-surface-area triangle?

The STL file format is badly designed. The normal vectors stored is at
best consistent with the vertex coordinates, sometimes they are not.

The best thing to do is to ignore the stored normal and compute it from
the vertex coordinates when required. But different code does different
things in this area, another reason among others why STL files are
probably the worst possible choice for exchanging models between
applications.

I didn't study every detail of the CGAL code, but I guess the normal is
computed yes.

Catrsten Arnholm

On 18.04.2020 10:12, Rogier Wolff wrote: > But I thought STLs had normal vectors inside them and that the vector > compared there was from the file. You're saying it is computed and > indicates a zero-surface-area triangle? The STL file format is badly designed. The normal vectors stored is at best consistent with the vertex coordinates, sometimes they are not. The best thing to do is to ignore the stored normal and compute it from the vertex coordinates when required. But different code does different things in this area, another reason among others why STL files are probably the worst possible choice for exchanging models between applications. I didn't study every detail of the CGAL code, but I guess the normal is computed yes. Catrsten Arnholm

CA

Carsten Arnholm

Sat, Apr 18, 2020 9:25 AM

On 18.04.2020 10:50, Carsten Arnholm wrote:

See the fix here, including original bad file + repaired file
https://gist.github.com/arnholm/49c52c130240184460668c281e8307c2

Something happened when uploading the STLs to github, they became
corrupted during upload. I have re-uploaded them now and it seems ok.

The file should display fine

You can get copies of the files using "git glone" and the URL above

Carsten Arnholm

On 18.04.2020 10:50, Carsten Arnholm wrote: > See the fix here, including original bad file + repaired file > https://gist.github.com/arnholm/49c52c130240184460668c281e8307c2 Something happened when uploading the STLs to github, they became corrupted during upload. I have re-uploaded them now and it seems ok. The file should display fine You can get copies of the files using "git glone" and the URL above Carsten Arnholm

CA

Carsten Arnholm

Sat, Apr 18, 2020 9:28 AM

On 18.04.2020 11:25, Carsten Arnholm wrote:

On 18.04.2020 10:50, Carsten Arnholm wrote:

See the fix here, including original bad file + repaired file
https://gist.github.com/arnholm/49c52c130240184460668c281e8307c2

You can get copies of the files using "git glone" and the URL above

That should be "git clone" obviously. Sorry.

Carsten Arnholm

On 18.04.2020 11:25, Carsten Arnholm wrote: > On 18.04.2020 10:50, Carsten Arnholm wrote: >> See the fix here, including original bad file + repaired file >> https://gist.github.com/arnholm/49c52c130240184460668c281e8307c2 > > You can get copies of the files using "git glone" and the URL above That should be "git clone" obviously. Sorry. Carsten Arnholm

G

guaranteed_interwoven

Mon, Apr 20, 2020 4:17 AM

Perhaps import should always try passing the mesh to CGAL, catch the

exception and report it is a broken STL. That would stop the endless reports
of "I can import my STL and it looks fine but CGS ops fail."

I would certainly appreciate that. When I load the STL in slic3r, there are
certainly no errors being reported and it does report the STL as a manifold,
so I was under the impression the problem was with OpenSCAD, not with the
STL.

--
Sent from: http://forum.openscad.org/

> Perhaps import should always try passing the mesh to CGAL, catch the exception and report it is a broken STL. That would stop the endless reports of "I can import my STL and it looks fine but CGS ops fail." I would certainly appreciate that. When I load the STL in slic3r, there are certainly no errors being reported and it does report the STL as a manifold, so I was under the impression the problem was with OpenSCAD, not with the STL. -- Sent from: http://forum.openscad.org/

G

guaranteed_interwoven

Mon, Apr 20, 2020 4:33 AM

Thank you! I installed angelcad and it worked perfectly.

I am 100% happy with an STL repair tool.

Thank you everyone for your help here!

--
Sent from: http://forum.openscad.org/

Thank you! I installed angelcad and it worked perfectly. I am 100% happy with an STL repair tool. Thank you everyone for your help here! -- Sent from: http://forum.openscad.org/

NH

nop head

Mon, Apr 20, 2020 8:43 AM

The STL has to be perfect for OpenSCAD to accept it. No degenerate
triangles and no self intersections.

I think the CGAL errors are 100% right about the mesh passed to it. I.e. no
false positives but because OpenSCAD snaps everything to a grid it can't
have very close vertices or snapping them will cause degenerate triangles
and self intersections.

On Mon, 20 Apr 2020 at 05:34, guaranteed_interwoven kerryhall@gmail.com
wrote:

Thank you! I installed angelcad and it worked perfectly.

I am 100% happy with an STL repair tool.

Thank you everyone for your help here!

--
Sent from: http://forum.openscad.org/

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

The STL has to be perfect for OpenSCAD to accept it. No degenerate triangles and no self intersections. I think the CGAL errors are 100% right about the mesh passed to it. I.e. no false positives but because OpenSCAD snaps everything to a grid it can't have very close vertices or snapping them will cause degenerate triangles and self intersections. On Mon, 20 Apr 2020 at 05:34, guaranteed_interwoven <kerryhall@gmail.com> wrote: > Thank you! I installed angelcad and it worked perfectly. > > I am 100% happy with an STL repair tool. > > Thank you everyone for your help here! > > > > -- > Sent from: http://forum.openscad.org/ > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

A

arnholm@arnholm.org

Mon, Apr 20, 2020 9:25 AM

On 2020-04-20 06:33, guaranteed_interwoven wrote:

Thank you! I installed angelcad and it worked perfectly.

I am 100% happy with an STL repair tool.

Thank you everyone for your help here!

Thanks for the confirmation and feedback! Repairing STL using such tools
is sometimes possible, but not in every case. STL is such a poor format
that it is possible to write unusable stuff to it.

Carsten Arnholm

On 2020-04-20 06:33, guaranteed_interwoven wrote: > Thank you! I installed angelcad and it worked perfectly. > > I am 100% happy with an STL repair tool. > > Thank you everyone for your help here! Thanks for the confirmation and feedback! Repairing STL using such tools is sometimes possible, but not in every case. STL is such a poor format that it is possible to write unusable stuff to it. Carsten Arnholm

discuss@lists.openscad.org

No longer able to use STLs