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.
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
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.
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
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 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.
ciao,
Torsten.
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.
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
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 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.