I am experiencing a strange issue where:
When I remove the minkowski function it works well. When I add it I only get an error when trying to export the object.
Is this a bug or (more likely) is there something I am missing?
Code:
ball_height = 56;
top_radius = 20;
head_minkow = 3;
threw_hole = 11;
minkowski(){
difference(){
sphere(r=top_radius);
cylinder(r=9, h=top_radius);
for(i=[0:72:360]){
rotate([0,60,i])
cylinder(r=9, h=top_radius);
// rotate([0,120,i])
// cylinder(r=6, h=ball_height/2);
}
}
sphere(r=head_minkow);
}
Output:
Parsing design (AST generation)...
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 16
Geometry cache size in bytes: 1563728
CGAL Polyhedrons in cache: 2
CGAL cache size in bytes: 2523920
Total rendering time: 0 hours, 0 minutes, 0 seconds
Top level object is a 3D object:
Facets: 20088
Rendering finished.
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e->incident_sface() != SFace_const_handle() File: /Users/kintel/code/OpenSCAD/libraries/install/include/CGAL/Nef_S2/SM_const_decorator.h Line: 330
AMF export finished: /Users/caitlin/Desktop/test.amf
Thanks for the help.
~Caitlin
The reason it is slow to preview is because OpenCSG used for preview can't
simulate Minkowski, so it has to be computed geometrically with CGAL. It is
then cached so render is fast.
I think the reason it goes wrong is that the union of the cylinders has
vertices that are too close for OpenSCAD's grid.
[image: image.png]
On Sat, 4 Jan 2020 at 07:58, Caitlin Campbell caitlin@cissols.com wrote:
I am experiencing a strange issue where:
When I remove the minkowski function it works well. When I add it I only
get an error when trying to export the object.
Is this a bug or (more likely) is there something I am missing?
Code:
ball_height = 56;
top_radius = 20;
head_minkow = 3;
threw_hole = 11;
minkowski(){
difference(){
sphere(r=top_radius);
cylinder(r=9, h=top_radius);
for(i=[0:72:360]){
rotate([0,60,i])
cylinder(r=9, h=top_radius);
// rotate([0,120,i])
// cylinder(r=6, h=ball_height/2);
}
}
sphere(r=head_minkow);
}
Output:
Parsing design (AST generation)...
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 16
Geometry cache size in bytes: 1563728
CGAL Polyhedrons in cache: 2
CGAL cache size in bytes: 2523920
Total rendering time: 0 hours, 0 minutes, 0 seconds
Top level object is a 3D object:
Facets: 20088
Rendering finished.
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e->incident_sface() != SFace_const_handle() File:
/Users/kintel/code/OpenSCAD/libraries/install/include/CGAL/Nef_S2/SM_const_decorator.h
Line: 330
AMF export finished: /Users/caitlin/Desktop/test.amf
Thanks for the help.
~Caitlin
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Ahh!
I was not at all aware of this grid system. Do you know if any docs on it?
As for the union of cylinders how would you recommend I resolve this? It’s sort of frustrating that there is arbitrary geometry that does not work.
Caitlin
On Jan 4, 2020, at 2:53 AM, nop head nop.head@gmail.com wrote:
The reason it is slow to preview is because OpenCSG used for preview can't simulate Minkowski, so it has to be computed geometrically with CGAL. It is then cached so render is fast.
I think the reason it goes wrong is that the union of the cylinders has vertices that are too close for OpenSCAD's grid.
<image.png>
On Sat, 4 Jan 2020 at 07:58, Caitlin Campbell <caitlin@cissols.commailto:caitlin@cissols.com> wrote:
I am experiencing a strange issue where:
When I remove the minkowski function it works well. When I add it I only get an error when trying to export the object.
Is this a bug or (more likely) is there something I am missing?
Code:
ball_height = 56;
top_radius = 20;
head_minkow = 3;
threw_hole = 11;
minkowski(){
difference(){
sphere(r=top_radius);
cylinder(r=9, h=top_radius);
for(i=[0:72:360]){
rotate([0,60,i])
cylinder(r=9, h=top_radius);
// rotate([0,120,i])
// cylinder(r=6, h=ball_height/2);
}
}
sphere(r=head_minkow);
}
Output:
Parsing design (AST generation)...
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 16
Geometry cache size in bytes: 1563728
CGAL Polyhedrons in cache: 2
CGAL cache size in bytes: 2523920
Total rendering time: 0 hours, 0 minutes, 0 seconds
Top level object is a 3D object:
Facets: 20088
Rendering finished.
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e->incident_sface() != SFace_const_handle() File: /Users/kintel/code/OpenSCAD/libraries/install/include/CGAL/Nef_S2/SM_const_decorator.h Line: 330
AMF export finished: /Users/caitlin/Desktop/test.amf
Thanks for the help.
~Caitlin
OpenSCAD mailing list
Discuss@lists.openscad.orgmailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Perhaps rotate each cylinder a little so the facets don't line up exactly.
OpenSCAD has multiple problems with vertices that are very close but not
exactly matching due to rounding errors. CGAL computes with
infinite precision rationals but they get converted to doubles and and
snapped to a fine grid and sometimes a course grid here:
https://github.com/openscad/openscad/blob/master/src/grid.h#L19. When an
STL is written they get truncated to floats. This is a major design error
because you can't reduce the resolution of vertices without potentially
creating degenerate triangles and self intersections. These need to be
cleaned up after every truncation but that isn't easy.
On Sat, 4 Jan 2020 at 11:19, Caitlin Campbell caitlin@cissols.com wrote:
Ahh!
I was not at all aware of this grid system. Do you know if any docs on it?
As for the union of cylinders how would you recommend I resolve this? It’s
sort of frustrating that there is arbitrary geometry that does not work.
Caitlin
On Jan 4, 2020, at 2:53 AM, nop head nop.head@gmail.com wrote:
The reason it is slow to preview is because OpenCSG used for preview can't
simulate Minkowski, so it has to be computed geometrically with CGAL. It is
then cached so render is fast.
I think the reason it goes wrong is that the union of the cylinders has
vertices that are too close for OpenSCAD's grid.
<image.png>
On Sat, 4 Jan 2020 at 07:58, Caitlin Campbell caitlin@cissols.com wrote:
I am experiencing a strange issue where:
When I remove the minkowski function it works well. When I add it I only
get an error when trying to export the object.
Is this a bug or (more likely) is there something I am missing?
Code:
ball_height = 56;
top_radius = 20;
head_minkow = 3;
threw_hole = 11;
minkowski(){
difference(){
sphere(r=top_radius);
cylinder(r=9, h=top_radius);
for(i=[0:72:360]){
rotate([0,60,i])
cylinder(r=9, h=top_radius);
// rotate([0,120,i])
// cylinder(r=6, h=ball_height/2);
}
}
sphere(r=head_minkow);
}
Output:
Parsing design (AST generation)...
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 16
Geometry cache size in bytes: 1563728
CGAL Polyhedrons in cache: 2
CGAL cache size in bytes: 2523920
Total rendering time: 0 hours, 0 minutes, 0 seconds
Top level object is a 3D object:
Facets: 20088
Rendering finished.
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e->incident_sface() != SFace_const_handle() File:
/Users/kintel/code/OpenSCAD/libraries/install/include/CGAL/Nef_S2/SM_const_decorator.h
Line: 330
AMF export finished: /Users/caitlin/Desktop/test.amf
Thanks for the help.
~Caitlin
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 04.01.2020 12:18, Caitlin Campbell wrote:
Ahh!
I was not at all aware of this grid system. Do you know if any docs on it?
As for the union of cylinders how would you recommend I resolve this?
It’s sort of frustrating that there is arbitrary geometry that does not
work.
Caitlin
I don't know if that grid system is the problem in this case, but
booleans can be tricky when the facets line up in ambiguous ways and
that can happen with minkowski. Maybe try with different faceting
resolutions ($fn).
Here's your model done differently (not OpenSCAD)
https://gist.github.com/arnholm/02200ed911910fdb22173edcc11bf093
Carsten Arnholm
Can one develop at 100x resolution and then scale the resulting STL, or
does this approach fail for some reason?
On 1/4/2020 6:35 AM, nop head wrote:
OpenSCAD has multiple problems with vertices that are very close but
not exactly matching due to rounding errors. CGAL computes with
infinite precision rationals but they get converted to doubles and and
snapped to a fine grid and sometimes a course grid here:
https://github.com/openscad/openscad/blob/master/src/grid.h#L19. When
an STL is written they get truncated to floats. This is a major design
error because you can't reduce the resolution of vertices without
potentially creating degenerate triangles and self intersections.
These need to be cleaned up after every truncation but that isn't easy.
It seems like this issue, about coordinate errors, gets raised a lot to
explain models that aren't working. And yet, it seems like there's always,
in the end, a different explanation. I'm not sure I've seen an example of a
model where this was really the problem. And when I took a look at this
model, my observation is that the result looks very wrong at a large scale.
(Note that when I rendered and exported the model I did not get an error.)
The facets around the holes should be smooth but instead they are kind of
zig-zagging back and forth at a scale that is a billion times bigger than
where rationals are going to round to each other. (Note for this run I had
$fn=16 in the last call to sphere.)
http://forum.openscad.org/file/t2477/weirdmodel.png
I tried commenting out the for loop, so there is just one cylinder
subtraction, and I got this weird behavior at the top edge (still with
$fn=16 on the last sphere). I'm having a hard time believing that this has
something to do with rounding errors.
http://forum.openscad.org/file/t2477/weird2.png
I tried increasing $fn overall to 128 and got this, which doesn't have any
obvious artifacts:
http://forum.openscad.org/file/t2477/weird3.png
And then I tried decreasing overall $fn to 32 and increasing the last sphere
to $fn=32 as well. That gave me this, which also looks good:
http://forum.openscad.org/file/t2477/weird4.png
I'm trying to run the full model now with $fn=32.
--
Sent from: http://forum.openscad.org/
I didn't look at the minkowski result much because the simple union of the
cylinders in the for loop is already broken when exported to STL. It is
possible for minkowski to heal errors though because it is a union of hulls
and hull doesn't need a manifold, just a point cloud.
I don't use the built in sphere() of OpenSCAD because they tend to be ugly
and that is probably the source of the weirdness at low $fn.
On Sat, 4 Jan 2020 at 14:56, adrianv avm4@cornell.edu wrote:
It seems like this issue, about coordinate errors, gets raised a lot to
explain models that aren't working. And yet, it seems like there's always,
in the end, a different explanation. I'm not sure I've seen an example of
a
model where this was really the problem. And when I took a look at this
model, my observation is that the result looks very wrong at a large
scale.
(Note that when I rendered and exported the model I did not get an
error.)
The facets around the holes should be smooth but instead they are kind of
zig-zagging back and forth at a scale that is a billion times bigger than
where rationals are going to round to each other. (Note for this run I
had
$fn=16 in the last call to sphere.)
http://forum.openscad.org/file/t2477/weirdmodel.png
I tried commenting out the for loop, so there is just one cylinder
subtraction, and I got this weird behavior at the top edge (still with
$fn=16 on the last sphere). I'm having a hard time believing that this has
something to do with rounding errors.
http://forum.openscad.org/file/t2477/weird2.png
I tried increasing $fn overall to 128 and got this, which doesn't have any
obvious artifacts:
http://forum.openscad.org/file/t2477/weird3.png
And then I tried decreasing overall $fn to 32 and increasing the last
sphere
to $fn=32 as well. That gave me this, which also looks good:
http://forum.openscad.org/file/t2477/weird4.png
I'm trying to run the full model now with $fn=32.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
What's wrong with the union of cylinders? I exported it, loaded it into
PrusaSlicer, sliced it. Everything appears to be OK---except that it looks
ugly where they meet, with a little artifact there. That artifact is just a
result of the cylinders being polyhedra instead of actually round, so it's
not wrong.
My run with $fn=32 completed in half an hour, and the rounding of the
circular holes still looks wonky, with weird zig-zags in the facets.
http://forum.openscad.org/file/t2477/weird5.png
--
Sent from: http://forum.openscad.org/
According to Netfabb it is broken. The picture I posted above shows where.
On Sat, 4 Jan 2020 at 15:33, adrianv avm4@cornell.edu wrote:
What's wrong with the union of cylinders? I exported it, loaded it into
PrusaSlicer, sliced it. Everything appears to be OK---except that it looks
ugly where they meet, with a little artifact there. That artifact is just a
result of the cylinders being polyhedra instead of actually round, so it's
not wrong.
My run with $fn=32 completed in half an hour, and the rounding of the
circular holes still looks wonky, with weird zig-zags in the facets.
http://forum.openscad.org/file/t2477/weird5.png
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org