manifold stl has errors; CGAL stl does not?
the small stl you attached throws no errors in orca slicer.
FWIW, a few weeks ago, I had a large stl generated by openscad which was
distorted in orca. Importing it back into openscad, it showed the errors
too.
I exported the original as .obj file, and had no errors.
Orca is based on bbl slicer (itself a fork of Prusa) but bbl has messed
with .3mf, no idea with what else.
On 16/05/2025 23:52, Adrian Mariano via Discuss wrote:
Ok. I've got a small example, but you will unfortunately have to
update to the latest BOSL2 to run it. I discovered the issue while
developing a print-in-place hinge for BOSL2, so it occurs with a
just-added new feature.
include<BOSL2/std.scad>
include<BOSL2/hinges.scad>
$fn=32;
knuckle_hinge(length=25, segs=3, offset=3, inner=true, in_place=true);
The model looks like this:
image.png
The STL file is small, so I'm attaching it as well. Maybe someone
with other software than PrusaSlicer can tell us what's wrong with the
model without having to mess with BOSL2. With this model PrusaSlicer
reports "Auto-repaired 256 errors".
On Thu, May 15, 2025 at 10:34 PM pca006132 john.lck40@gmail.com wrote:
I guess you can try Meshlab as well.
Also, maybe try 3mf, it should preserve the topology information.
On Fri, May 16, 2025, 9:58 AM Marius Kintel via Discuss
<discuss@lists.openscad.org> wrote:
Not sure, but if you share it I can have a look.
Do you also have an easy way to reproduce? I’m not familiar
with Prusaslicer.
-Marius
On May 15, 2025, at 21:47, Adrian Mariano <avm4@cornell.edu>
wrote:
Is the hinge model a small enough example or do I need to try
to reduce it somehow?
On Thu, May 15, 2025 at 9:35 PM Marius Kintel
<marius@kintel.net> wrote:
Due to limitations in CGAL, we have to quantize vertices
when moving between OpenSCAD and CGAL, and when exporting
from CGAL. This causes vertices to have less precision,
but at the risk of making destructive topology changes.
With Manifold, we have a more robust pipeline and can
maintain the natural (64-bit doubles) vertex precision
end-to-end.
-Marius
On May 15, 2025, at 21:32, Adrian Mariano
<avm4@cornell.edu> wrote:
The example is a single hinge part produced from BOSL2.
Is that small enough?
Why would there be a difference in vertex precision
between manifold and CGAL?
On Thu, May 15, 2025 at 9:10 PM Marius Kintel
<marius@kintel.net> wrote:
On May 15, 2025, at 18:31, Adrian Mariano via
Discuss <discuss@lists.openscad.org> wrote:
I noticed that if I make my model in the snapshot
2025.04.29.snap that when I load it into
prusaslicer it says it's correcting 1796 errors. If
I make my stl in the same program but enable CGAL
then it says "no errors detected". That doesn't
seem ideal. Anybody know why this is happening?
Can you share a smallish example?
My best cold guess would be that Prusaslicer cannot
handle the precision of the vertices and ends up
merging close vertices causing zero area triangles
and it complains. Such repairs are _typically_
benign, unless they cause topology collapse.
Bad news is that there is no general solution to fix
this; even with a native solution in OpenSCAD, you’d
eventually have to make destructive changes to
topology if you need to limit vertex precision.
-Marius
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
I tried CGAL and the report for the STL is 802 facets and no errors.
On Fri, May 16, 2025 at 7:25 PM Raymond West via Discuss <
discuss@lists.openscad.org> wrote:
the small stl you attached throws no errors in orca slicer.
FWIW, a few weeks ago, I had a large stl generated by openscad which was
distorted in orca. Importing it back into openscad, it showed the errors
too.
I exported the original as .obj file, and had no errors.
Orca is based on bbl slicer (itself a fork of Prusa) but bbl has messed
with .3mf, no idea with what else.
On 16/05/2025 23:52, Adrian Mariano via Discuss wrote:
Ok. I've got a small example, but you will unfortunately have to update
to the latest BOSL2 to run it. I discovered the issue while developing a
print-in-place hinge for BOSL2, so it occurs with a just-added new
feature.
include<BOSL2/std.scad>
include<BOSL2/hinges.scad>
$fn=32;
knuckle_hinge(length=25, segs=3, offset=3, inner=true, in_place=true);
The model looks like this:
[image: image.png]
The STL file is small, so I'm attaching it as well. Maybe someone with
other software than PrusaSlicer can tell us what's wrong with the model
without having to mess with BOSL2. With this model PrusaSlicer reports
"Auto-repaired 256 errors".
On Thu, May 15, 2025 at 10:34 PM pca006132 john.lck40@gmail.com wrote:
I guess you can try Meshlab as well.
Also, maybe try 3mf, it should preserve the topology information.
On Fri, May 16, 2025, 9:58 AM Marius Kintel via Discuss <
discuss@lists.openscad.org> wrote:
Not sure, but if you share it I can have a look.
Do you also have an easy way to reproduce? I’m not familiar with
Prusaslicer.
-Marius
On May 15, 2025, at 21:47, Adrian Mariano avm4@cornell.edu wrote:
Is the hinge model a small enough example or do I need to try to reduce
it somehow?
On Thu, May 15, 2025 at 9:35 PM Marius Kintel marius@kintel.net wrote:
Due to limitations in CGAL, we have to quantize vertices when moving
between OpenSCAD and CGAL, and when exporting from CGAL. This causes
vertices to have less precision, but at the risk of making destructive
topology changes. With Manifold, we have a more robust pipeline and can
maintain the natural (64-bit doubles) vertex precision end-to-end.
-Marius
On May 15, 2025, at 21:32, Adrian Mariano avm4@cornell.edu wrote:
The example is a single hinge part produced from BOSL2. Is that small
enough?
Why would there be a difference in vertex precision between manifold
and CGAL?
On Thu, May 15, 2025 at 9:10 PM Marius Kintel marius@kintel.net
wrote:
On May 15, 2025, at 18:31, Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
I noticed that if I make my model in the snapshot 2025.04.29.snap
that when I load it into prusaslicer it says it's correcting 1796 errors.
If I make my stl in the same program but enable CGAL then it says "no
errors detected". That doesn't seem ideal. Anybody know why this is
happening?
Can you share a smallish example?
My best cold guess would be that Prusaslicer cannot handle the
precision of the vertices and ends up merging close vertices causing zero
area triangles and it complains. Such repairs are typically benign,
unless they cause topology collapse.
Bad news is that there is no general solution to fix this; even with a
native solution in OpenSCAD, you’d eventually have to make destructive
changes to topology if you need to limit vertex precision.
-Marius
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Here's a pretty minimal raw-OpenSCAD demonstration:
$fn = 4;
cube([10,10,8.2], center=true);
rotate_extrude(angle = 360, start = 180) {
polygon(points = [[0, 0], [2, 0], [2, 4.1], [1, 5], [0, 5]]);
}
Removing the cube has both CGAL and Manifold producing STLs that
PrusaSlicer doesn't like.
(Design/Display CSG Tree is your friend when you're trying to strip away
the complexity of a library to get to the raw geometry, though it would
be nice if it could elide the boring group() nodes.)
Here is an excerpt of the OBJ of Jordan's minimal raw-OpenSCAD:
OpenSCAD obj exporter
v -5 -5 -4.1
v -5 -5 4.1
v -5 5 -4.1
v -5 5 4.1
v -2 -0 4.1
v -2 -0 4.1
v -1 -0 5
v 5 -5 -4.1
v -0 -2 4.1
v -0 -2 4.1
v -0 -1 5
v 5 -5 4.1
v 5 5 -4.1
v -0 -0 5
Here is an excerpt of the ASCII STL of Jordan's minimal raw-OpenSCAD:
facet normal 1 0 0
outer loop
vertex 5 5 4.1
vertex 5 -5 4.1
vertex 5 5 -4.1
endloop
endfacet
facet normal -0.7071067811865476 -0.7071067811865476 0
outer loop
vertex -2 0 4.1
vertex 0 -2 4.100000001490116
vertex -2 0 4.100000001490116
endloop
endfacet
facet normal -0.7071067811865476 -0.7071067811865476 0
outer loop
vertex 0 -2 4.1
vertex 0 -2 4.100000001490116
vertex -2 0 4.1
On Fri, May 16, 2025 at 7:56 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
Here's a pretty minimal raw-OpenSCAD demonstration:
$fn = 4;
cube([10,10,8.2], center=true);
rotate_extrude(angle = 360, start = 180) {
polygon(points = [[0, 0], [2, 0], [2, 4.1], [1, 5], [0, 5]]);
}
Removing the cube has both CGAL and Manifold producing STLs that
PrusaSlicer doesn't like.
(Design/Display CSG Tree is your friend when you're trying to strip away
the complexity of a library to get to the raw geometry, though it would be
nice if it could elide the boring group() nodes.)
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
FWIW, none of the images attached to this thread have made it thru to
thunderbird beta here.
On 5/16/25 22:12, Leonard Martin Struttmann via Discuss wrote:
Here is an excerpt of the OBJ of Jordan's minimal raw-OpenSCAD:
OpenSCAD obj exporter
v -5 -5 -4.1
v -5 -5 4.1
v -5 5 -4.1
v -5 5 4.1
v -2 -0 4.1
v -2 -0 4.1
v -1 -0 5
v 5 -5 -4.1
v -0 -2 4.1
v -0 -2 4.1
v -0 -1 5
v 5 -5 4.1
v 5 5 -4.1
v -0 -0 5
Here is an excerpt of the ASCII STL of Jordan's minimal raw-OpenSCAD:
facet normal 1 0 0
outer loop
vertex 5 5 4.1
vertex 5 -5 4.1
vertex 5 5 -4.1
endloop
endfacet
facet normal -0.7071067811865476 -0.7071067811865476 0
outer loop
vertex -2 0 4.1
vertex 0 -2 4.100000001490116
vertex -2 0 4.100000001490116
endloop
endfacet
facet normal -0.7071067811865476 -0.7071067811865476 0
outer loop
vertex 0 -2 4.1
vertex 0 -2 4.100000001490116
vertex -2 0 4.1
On Fri, May 16, 2025 at 7:56 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
Here's a pretty minimal raw-OpenSCAD demonstration:
$fn = 4;
cube([10,10,8.2], center=true);
rotate_extrude(angle = 360, start = 180) {
polygon(points = [[0, 0], [2, 0], [2, 4.1], [1, 5], [0, 5]]);
}
Removing the cube has both CGAL and Manifold producing STLs that
PrusaSlicer doesn't like.
(Design/Display CSG Tree is your friend when you're trying to strip away
the complexity of a library to get to the raw geometry, though it would be
nice if it could elide the boring group() nodes.)
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis