discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

STL processing....

RW
Rogier Wolff
Sun, Jan 7, 2024 6:13 PM

Hi,

I tried cutting a "from the internet" STL in half by using openscad.

But as usual, if you import the STL, difference with the part you
don't want, and try to render you get CGAL errors and "there is no top
level to render". (or something like that).

So I decided to write an STL checker. I first wrote the read function.
(I found a library, but learning a new computer language to be able to
use it was "out of scope" for this weekend). The STL format is simple
enough. Then I wrote an "write STL" function from my internal
datastructures. I get the identical STL back! Great!

Then I wrote my first check function: Process the edges and check that
all of them are traversed exactly twice and once in each
direction. (actually that was the intention, for now I just print the count
and directions seen, and I used grep to verify that there were no not-expected
results.)

My testcube (openscad: cube (10);) works perfectly.

Then the 42Mb STL from the internet and.... Checks out! All edges
traversed exactly once in each direction!

My conclusion is that there cannot be any holes. Absolutely NOT.
A hole would have an edge that is traversed only once.

This means that OPENSCAD (and Slic3r) must be mangling the STL on
import.

Let me say that I consider this "bad form": You guys have convinced me
over the years that many STL files downloaded from the internet are
"bad", so I falsely accused the given STL of being "bad".

I suspect that it's the "snap-to-grid" that is causing this. Is there
a way to disable this without recompiling openscad ?

If I am going to recompile openscad, does anybody have a pointer to
where this is happening in the source code?

Is there any workaround so I can just cut my STL in half and get it
printed?

I'm considering multiplying all coordinates by 1000 in my program for
re-export towards Openscad, and see what happens then....

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

Hi, I tried cutting a "from the internet" STL in half by using openscad. But as usual, if you import the STL, difference with the part you don't want, and try to render you get CGAL errors and "there is no top level to render". (or something like that). So I decided to write an STL checker. I first wrote the read function. (I found a library, but learning a new computer language to be able to use it was "out of scope" for this weekend). The STL format is simple enough. Then I wrote an "write STL" function from my internal datastructures. I get the identical STL back! Great! Then I wrote my first check function: Process the edges and check that all of them are traversed exactly twice and once in each direction. (actually that was the intention, for now I just print the count and directions seen, and I used grep to verify that there were no not-expected results.) My testcube (openscad: cube (10);) works perfectly. Then the 42Mb STL from the internet and.... Checks out! All edges traversed exactly once in each direction! My conclusion is that there cannot be any holes. Absolutely NOT. A hole would have an edge that is traversed only once. This means that OPENSCAD (and Slic3r) must be mangling the STL on import. Let me say that I consider this "bad form": You guys have convinced me over the years that many STL files downloaded from the internet are "bad", so I falsely accused the given STL of being "bad". I suspect that it's the "snap-to-grid" that is causing this. Is there a way to disable this without recompiling openscad ? If I am going to recompile openscad, does anybody have a pointer to where this is happening in the source code? Is there any workaround so I can just cut my STL in half and get it printed? I'm considering multiplying all coordinates by 1000 in my program for re-export towards Openscad, and see what happens then.... Roger. -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
FH
Father Horton
Sun, Jan 7, 2024 6:20 PM

Use Meshmixer for stuff like this.

On Sun, Jan 7, 2024 at 12:14 PM Rogier Wolff via Discuss <
discuss@lists.openscad.org> wrote:

Hi,

I tried cutting a "from the internet" STL in half by using openscad.

But as usual, if you import the STL, difference with the part you
don't want, and try to render you get CGAL errors and "there is no top
level to render". (or something like that).

So I decided to write an STL checker. I first wrote the read function.
(I found a library, but learning a new computer language to be able to
use it was "out of scope" for this weekend). The STL format is simple
enough. Then I wrote an "write STL" function from my internal
datastructures. I get the identical STL back! Great!

Then I wrote my first check function: Process the edges and check that
all of them are traversed exactly twice and once in each
direction. (actually that was the intention, for now I just print the count
and directions seen, and I used grep to verify that there were no
not-expected
results.)

My testcube (openscad: cube (10);) works perfectly.

Then the 42Mb STL from the internet and.... Checks out! All edges
traversed exactly once in each direction!

My conclusion is that there cannot be any holes. Absolutely NOT.
A hole would have an edge that is traversed only once.

This means that OPENSCAD (and Slic3r) must be mangling the STL on
import.

Let me say that I consider this "bad form": You guys have convinced me
over the years that many STL files downloaded from the internet are
"bad", so I falsely accused the given STL of being "bad".

I suspect that it's the "snap-to-grid" that is causing this. Is there
a way to disable this without recompiling openscad ?

If I am going to recompile openscad, does anybody have a pointer to
where this is happening in the source code?

Is there any workaround so I can just cut my STL in half and get it
printed?

I'm considering multiplying all coordinates by 1000 in my program for
re-export towards Openscad, and see what happens then....

     Roger.

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

Use Meshmixer for stuff like this. On Sun, Jan 7, 2024 at 12:14 PM Rogier Wolff via Discuss < discuss@lists.openscad.org> wrote: > Hi, > > I tried cutting a "from the internet" STL in half by using openscad. > > But as usual, if you import the STL, difference with the part you > don't want, and try to render you get CGAL errors and "there is no top > level to render". (or something like that). > > So I decided to write an STL checker. I first wrote the read function. > (I found a library, but learning a new computer language to be able to > use it was "out of scope" for this weekend). The STL format is simple > enough. Then I wrote an "write STL" function from my internal > datastructures. I get the identical STL back! Great! > > Then I wrote my first check function: Process the edges and check that > all of them are traversed exactly twice and once in each > direction. (actually that was the intention, for now I just print the count > and directions seen, and I used grep to verify that there were no > not-expected > results.) > > My testcube (openscad: cube (10);) works perfectly. > > Then the 42Mb STL from the internet and.... Checks out! All edges > traversed exactly once in each direction! > > My conclusion is that there cannot be any holes. Absolutely NOT. > A hole would have an edge that is traversed only once. > > This means that OPENSCAD (and Slic3r) must be mangling the STL on > import. > > Let me say that I consider this "bad form": You guys have convinced me > over the years that many STL files downloaded from the internet are > "bad", so I falsely accused the given STL of being "bad". > > I suspect that it's the "snap-to-grid" that is causing this. Is there > a way to disable this without recompiling openscad ? > > If I am going to recompile openscad, does anybody have a pointer to > where this is happening in the source code? > > Is there any workaround so I can just cut my STL in half and get it > printed? > > I'm considering multiplying all coordinates by 1000 in my program for > re-export towards Openscad, and see what happens then.... > > Roger. > > -- > ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 > ** > ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** > f equals m times a. When your f is steady, and your m is going down > your a is going up. -- Chris Hadfield about flying up the space shuttle. > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >
RW
Rogier Wolff
Sun, Jan 7, 2024 6:27 PM

On Sun, Jan 07, 2024 at 07:13:47PM +0100, Rogier Wolff via Discuss wrote:

I'm considering multiplying all coordinates by 1000 in my program for
re-export towards Openscad, and see what happens then....

Update: I first tried if the original STL withtout the "difference"
would render. To my surprise it worked. I then exported that as STL,
and reimported that. Now turning on the difference and: After the
difference operation, the result is no longer closed. It is the
openscad difference operation that makes a mesh go from closed to
not-closed!

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

On Sun, Jan 07, 2024 at 07:13:47PM +0100, Rogier Wolff via Discuss wrote: > I'm considering multiplying all coordinates by 1000 in my program for > re-export towards Openscad, and see what happens then.... Update: I first tried if the original STL withtout the "difference" would render. To my surprise it worked. I then exported that as STL, and reimported that. Now turning on the difference and: After the difference operation, the result is no longer closed. It is the openscad difference operation that makes a mesh go from closed to not-closed! Roger. -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
JH
Joseph Haas
Sun, Jan 7, 2024 8:28 PM

The Prusa slicer lets you plane cut stl imports. I would be surprised if
other slicers don’t do this.

Imo, that is the easiest way to do it.

Cheers,

Joe

On Sun, Jan 7, 2024 at 12:27 Rogier Wolff via Discuss <
discuss@lists.openscad.org> wrote:

On Sun, Jan 07, 2024 at 07:13:47PM +0100, Rogier Wolff via Discuss wrote:

I'm considering multiplying all coordinates by 1000 in my program for
re-export towards Openscad, and see what happens then....

Update: I first tried if the original STL withtout the "difference"
would render. To my surprise it worked. I then exported that as STL,
and reimported that. Now turning on the difference and: After the
difference operation, the result is no longer closed. It is the
openscad difference operation that makes a mesh go from closed to
not-closed!

     Roger.

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

The Prusa slicer lets you plane cut stl imports. I would be surprised if other slicers don’t do this. Imo, that is the easiest way to do it. Cheers, Joe On Sun, Jan 7, 2024 at 12:27 Rogier Wolff via Discuss < discuss@lists.openscad.org> wrote: > On Sun, Jan 07, 2024 at 07:13:47PM +0100, Rogier Wolff via Discuss wrote: > > I'm considering multiplying all coordinates by 1000 in my program for > > re-export towards Openscad, and see what happens then.... > > Update: I first tried if the original STL withtout the "difference" > would render. To my surprise it worked. I then exported that as STL, > and reimported that. Now turning on the difference and: After the > difference operation, the result is no longer closed. It is the > openscad difference operation that makes a mesh go from closed to > not-closed! > > Roger. > > -- > ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 > ** > ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** > f equals m times a. When your f is steady, and your m is going down > your a is going up. -- Chris Hadfield about flying up the space shuttle. > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >
RW
Rogier Wolff
Sun, Jan 7, 2024 8:29 PM

On Sun, Jan 07, 2024 at 07:27:28PM +0100, Rogier Wolff via Discuss wrote:

On Sun, Jan 07, 2024 at 07:13:47PM +0100, Rogier Wolff via Discuss wrote:

I'm considering multiplying all coordinates by 1000 in my program for
re-export towards Openscad, and see what happens then....

Update2: I've written "calculate the triangles' area.

There is one triangle that's zero-area, up to 6 decimal places. If I
first scale the object by 1000, areas should (and they do!) increase
by a factor of a million, but this zero-area-triangle remains zero.

Could a single zero-area-triangle cause this?

It is this one:

#t139252:
facet normal 0.000000e+00 0.000000e+00 0.000000e+00
outer loop
vertex 1.711380e+02 -4.805237e+00 3.389800e+01
vertex 1.711380e+02 -4.805237e+00 3.390600e+01
vertex 1.711380e+02 -4.805237e+00 3.389400e+01
endloop
endfacet

The vertices are on a line.

as per the edge check, all edges of this triangle are being used
exactly once by other triangles.

Am I correct that I can "fix" this by deleting this triangle and
splitting the triangle that uses the longest edge of this one into two
smaller ones? (change in nr of triangles: none.)

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

On Sun, Jan 07, 2024 at 07:27:28PM +0100, Rogier Wolff via Discuss wrote: > On Sun, Jan 07, 2024 at 07:13:47PM +0100, Rogier Wolff via Discuss wrote: > > I'm considering multiplying all coordinates by 1000 in my program for > > re-export towards Openscad, and see what happens then.... Update2: I've written "calculate the triangles' area. There is one triangle that's zero-area, up to 6 decimal places. If I first scale the object by 1000, areas should (and they do!) increase by a factor of a million, but this zero-area-triangle remains zero. Could a single zero-area-triangle cause this? It is this one: #t139252: facet normal 0.000000e+00 0.000000e+00 0.000000e+00 outer loop vertex 1.711380e+02 -4.805237e+00 3.389800e+01 vertex 1.711380e+02 -4.805237e+00 3.390600e+01 vertex 1.711380e+02 -4.805237e+00 3.389400e+01 endloop endfacet The vertices are on a line. as per the edge check, all edges of this triangle are being used exactly once by other triangles. Am I correct that I can "fix" this by deleting this triangle and splitting the triangle that uses the longest edge of this one into two smaller ones? (change in nr of triangles: none.) Roger. -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
TP
Torsten Paul
Sun, Jan 7, 2024 8:37 PM

On 07.01.24 21:29, Rogier Wolff via Discuss wrote:

Could a single zero-area-triangle cause this?

Yes.

https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_is_my_imported_STL_file_appearing_with_F5_but_not_F6?

I think the reason with CGAL is that it's not possible to determine
if a point is on a specific side of that triangle.

Note that this also applies to triangles with all points on
a single line, so really zero-area, not necessarily all three
points too close together.

Am I correct that I can "fix" this by deleting this triangle and
splitting the triangle that uses the longest edge of this one into two
smaller ones? (change in nr of triangles: none.)

Meshlab calls that fix "Remove T-Vertices by Edge-Flip", there
might be some explanation under that name.

ciao,
Torsten.

On 07.01.24 21:29, Rogier Wolff via Discuss wrote: > Could a single zero-area-triangle cause this? Yes. https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_is_my_imported_STL_file_appearing_with_F5_but_not_F6? I think the reason with CGAL is that it's not possible to determine if a point is on a specific side of that triangle. Note that this also applies to triangles with all points on a single line, so really zero-area, not necessarily all three points too close together. > Am I correct that I can "fix" this by deleting this triangle and > splitting the triangle that uses the longest edge of this one into two > smaller ones? (change in nr of triangles: none.) Meshlab calls that fix "Remove T-Vertices by Edge-Flip", there might be some explanation under that name. ciao, Torsten.
RW
Rogier Wolff
Sun, Jan 7, 2024 9:15 PM

On Sun, Jan 07, 2024 at 09:37:40PM +0100, Torsten Paul via Discuss wrote:

On 07.01.24 21:29, Rogier Wolff via Discuss wrote:

Could a single zero-area-triangle cause this?

Yes.

https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_is_my_imported_STL_file_appearing_with_F5_but_not_F6?

I think the reason with CGAL is that it's not possible to determine
if a point is on a specific side of that triangle.

Note that this also applies to triangles with all points on
a single line, so really zero-area, not necessarily all three
points too close together.

Am I correct that I can "fix" this by deleting this triangle and
splitting the triangle that uses the longest edge of this one into two
smaller ones? (change in nr of triangles: none.)

Meshlab calls that fix "Remove T-Vertices by Edge-Flip", there
might be some explanation under that name.

AH! Ok! I have meshlab, and someone on the internet recommended using
2 of the filters to "repair" STLs. Duh! Probably most of the filters
would have some effect on SOME STLs and his just happened to be fixed
by those two. But I wasn't about to go trying all 30-ish filters...

Thanks for pointing out the right one for me.
....

Meshlab tells me:

LOG: 0 All files opened in 351 msec
meshlab: ./vcglib/vcg/simplex/face/pos.h:196: void vcg::face::Pos<FaceType>::FlipF() [with FaceType = CFaceO]: Assertion `f->FFp(z)->FFp(f->FFi(z))==f' failed.
Abort (core dumped)

That's not good, right? :-)

Might have to write it myself after all.

Roger.

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

On Sun, Jan 07, 2024 at 09:37:40PM +0100, Torsten Paul via Discuss wrote: > On 07.01.24 21:29, Rogier Wolff via Discuss wrote: > > Could a single zero-area-triangle cause this? > > Yes. > > https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_is_my_imported_STL_file_appearing_with_F5_but_not_F6? > > I think the reason with CGAL is that it's not possible to determine > if a point is on a specific side of that triangle. > > Note that this also applies to triangles with all points on > a single line, so really zero-area, not necessarily all three > points too close together. > > > Am I correct that I can "fix" this by deleting this triangle and > > splitting the triangle that uses the longest edge of this one into two > > smaller ones? (change in nr of triangles: none.) > > Meshlab calls that fix "Remove T-Vertices by Edge-Flip", there > might be some explanation under that name. AH! Ok! I have meshlab, and someone on the internet recommended using 2 of the filters to "repair" STLs. Duh! Probably most of the filters would have some effect on SOME STLs and his just happened to be fixed by those two. But I wasn't about to go trying all 30-ish filters... Thanks for pointing out the right one for me. .... Meshlab tells me: LOG: 0 All files opened in 351 msec meshlab: ./vcglib/vcg/simplex/face/pos.h:196: void vcg::face::Pos<FaceType>::FlipF() [with FaceType = CFaceO]: Assertion `f->FFp(z)->FFp(f->FFi(z))==f' failed. Abort (core dumped) That's not good, right? :-) Might have to write it myself after all. Roger. -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
NH
nop head
Sun, Jan 7, 2024 9:22 PM

A 42MB STL is very unlikely to import into OpenSCAD because it is so
detailed that there are going to be some vertices too close together. The
STL has to be perfect, i.e. no holes, degenerate triangles or self
intersections AFTER it has been snapped to the grid. When the detail is so
high it is very likely some vertices will snap to the same point and that
will break it. Also CGAL would be too slow to process it in a reasonable
time. Perhaps Manifold can do it before the death of the universe.

On Sun, 7 Jan 2024 at 21:15, Rogier Wolff via Discuss <
discuss@lists.openscad.org> wrote:

On Sun, Jan 07, 2024 at 09:37:40PM +0100, Torsten Paul via Discuss wrote:

On 07.01.24 21:29, Rogier Wolff via Discuss wrote:

Could a single zero-area-triangle cause this?

Yes.

I think the reason with CGAL is that it's not possible to determine
if a point is on a specific side of that triangle.

Note that this also applies to triangles with all points on
a single line, so really zero-area, not necessarily all three
points too close together.

Am I correct that I can "fix" this by deleting this triangle and
splitting the triangle that uses the longest edge of this one into two
smaller ones? (change in nr of triangles: none.)

Meshlab calls that fix "Remove T-Vertices by Edge-Flip", there
might be some explanation under that name.

AH! Ok! I have meshlab, and someone on the internet recommended using
2 of the filters to "repair" STLs. Duh! Probably most of the filters
would have some effect on SOME STLs and his just happened to be fixed
by those two. But I wasn't about to go trying all 30-ish filters...

Thanks for pointing out the right one for me.
....

Meshlab tells me:

LOG: 0 All files opened in 351 msec
meshlab: ./vcglib/vcg/simplex/face/pos.h:196: void
vcg::face::Pos<FaceType>::FlipF() [with FaceType = CFaceO]: Assertion
`f->FFp(z)->FFp(f->FFi(z))==f' failed.
Abort (core dumped)

That's not good, right? :-)

Might have to write it myself after all.

     Roger.

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

A 42MB STL is very unlikely to import into OpenSCAD because it is so detailed that there are going to be some vertices too close together. The STL has to be perfect, i.e. no holes, degenerate triangles or self intersections AFTER it has been snapped to the grid. When the detail is so high it is very likely some vertices will snap to the same point and that will break it. Also CGAL would be too slow to process it in a reasonable time. Perhaps Manifold can do it before the death of the universe. On Sun, 7 Jan 2024 at 21:15, Rogier Wolff via Discuss < discuss@lists.openscad.org> wrote: > On Sun, Jan 07, 2024 at 09:37:40PM +0100, Torsten Paul via Discuss wrote: > > On 07.01.24 21:29, Rogier Wolff via Discuss wrote: > > > Could a single zero-area-triangle cause this? > > > > Yes. > > > > > https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_is_my_imported_STL_file_appearing_with_F5_but_not_F6 > ? > > > > I think the reason with CGAL is that it's not possible to determine > > if a point is on a specific side of that triangle. > > > > Note that this also applies to triangles with all points on > > a single line, so really zero-area, not necessarily all three > > points too close together. > > > > > Am I correct that I can "fix" this by deleting this triangle and > > > splitting the triangle that uses the longest edge of this one into two > > > smaller ones? (change in nr of triangles: none.) > > > > Meshlab calls that fix "Remove T-Vertices by Edge-Flip", there > > might be some explanation under that name. > > AH! Ok! I have meshlab, and someone on the internet recommended using > 2 of the filters to "repair" STLs. Duh! Probably most of the filters > would have some effect on SOME STLs and his just happened to be fixed > by those two. But I wasn't about to go trying all 30-ish filters... > > Thanks for pointing out the right one for me. > .... > > Meshlab tells me: > > LOG: 0 All files opened in 351 msec > meshlab: ./vcglib/vcg/simplex/face/pos.h:196: void > vcg::face::Pos<FaceType>::FlipF() [with FaceType = CFaceO]: Assertion > `f->FFp(z)->FFp(f->FFi(z))==f' failed. > Abort (core dumped) > > That's not good, right? :-) > > Might have to write it myself after all. > > Roger. > > -- > ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 > ** > ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** > f equals m times a. When your f is steady, and your m is going down > your a is going up. -- Chris Hadfield about flying up the space shuttle. > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >
TP
Torsten Paul
Sun, Jan 7, 2024 9:23 PM

On 07.01.24 22:15, Rogier Wolff via Discuss wrote:

AH! Ok! I have meshlab, and someone on the internet recommended using
2 of the filters to "repair" STLs. Duh!

Yes, there are obviously other issues too, like actual holes or other
those you mentioned earlier.

meshlab: ./vcglib/vcg/simplex/face/pos.h:196: void vcg::face::Pos<FaceType>::FlipF() [with FaceType = CFaceO]: Assertion `f->FFp(z)->FFp(f->FFi(z))==f' failed.
That's not good, right? :-)

I've seen that too once in a while when trying to clean STLs in
MeshLab. There is maybe a combination of zero-area triangle with some
other problem causing this. I do have cases where that filter worked
as it supposed to.

ciao,
Torsten.

On 07.01.24 22:15, Rogier Wolff via Discuss wrote: > AH! Ok! I have meshlab, and someone on the internet recommended using > 2 of the filters to "repair" STLs. Duh! Yes, there are obviously other issues too, like actual holes or other those you mentioned earlier. > meshlab: ./vcglib/vcg/simplex/face/pos.h:196: void vcg::face::Pos<FaceType>::FlipF() [with FaceType = CFaceO]: Assertion `f->FFp(z)->FFp(f->FFi(z))==f' failed. > That's not good, right? :-) I've seen that too once in a while when trying to clean STLs in MeshLab. There is maybe a combination of zero-area triangle with some other problem causing this. I do have cases where that filter worked as it supposed to. ciao, Torsten.
RW
Rogier Wolff
Sun, Jan 7, 2024 9:31 PM

On Sun, Jan 07, 2024 at 10:23:24PM +0100, Torsten Paul via Discuss wrote:

On 07.01.24 22:15, Rogier Wolff via Discuss wrote:

AH! Ok! I have meshlab, and someone on the internet recommended using
2 of the filters to "repair" STLs. Duh!

Yes, there are obviously other issues too, like actual holes or other
those you mentioned earlier.

meshlab: ./vcglib/vcg/simplex/face/pos.h:196: void vcg::face::Pos<FaceType>::FlipF() [with FaceType = CFaceO]: Assertion `f->FFp(z)->FFp(f->FFi(z))==f' failed.
That's not good, right? :-)

I've seen that too once in a while when trying to clean STLs in
MeshLab. There is maybe a combination of zero-area triangle with some
other problem causing this. I do have cases where that filter worked
as it supposed to.

At first i saw the "z" in there and... this straight line is precisely
aligned with the Z axis. Could it be that it's not expecting THAT? But
on closer inspection I think it is verifying a prev->next == current
linked list consistency thingy... It could be that it was tested with
the two involved triangles NOT being consecutive in the list, while in
my STL they just happen to BE consecutive.

It's easy for my read-possibly-process-write STL files program to
randomize the triangle list. I might try that.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

On Sun, Jan 07, 2024 at 10:23:24PM +0100, Torsten Paul via Discuss wrote: > On 07.01.24 22:15, Rogier Wolff via Discuss wrote: > > AH! Ok! I have meshlab, and someone on the internet recommended using > > 2 of the filters to "repair" STLs. Duh! > > Yes, there are obviously other issues too, like actual holes or other > those you mentioned earlier. > > > meshlab: ./vcglib/vcg/simplex/face/pos.h:196: void vcg::face::Pos<FaceType>::FlipF() [with FaceType = CFaceO]: Assertion `f->FFp(z)->FFp(f->FFi(z))==f' failed. > > That's not good, right? :-) > > I've seen that too once in a while when trying to clean STLs in > MeshLab. There is maybe a combination of zero-area triangle with some > other problem causing this. I do have cases where that filter worked > as it supposed to. At first i saw the "z" in there and... this straight line is precisely aligned with the Z axis. Could it be that it's not expecting THAT? But on closer inspection I think it is verifying a prev->next == current linked list consistency thingy... It could be that it was tested with the two involved triangles NOT being consecutive in the list, while in my STL they just happen to BE consecutive. It's easy for my read-possibly-process-write STL files program to randomize the triangle list. I might try that. Roger. -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.