mystical numerology with render() resize() and extrude()
Mysterious greetings friends,
i have managed to narrow down a mystical singularity to the code below.
i can not figure out which particular combination of magical numbers
would be the border case, but it is reproducible with the following code:
//ERROR: The given mesh is not closed! Unable to convert to
CGAL_Nef_Polyhedron.
$fn=10;
difference()
{
cube(25);
render()
{
translate([0,0,50])
linear_extrude( height = 5, scale=[0.78, 0.75])
resize([47,40]) offset(r = 8)
square(10, center = true);
linear_extrude( height = 100)
resize([47,40]) offset(r = 8)
square(10, center = true);
}
}
i think this mystical conspiracy is also connected to the numbers 5 and
6 since pressing F5 and F6 produces completely different results.
removing the curse "render()" from the magic spell, removes the magic,
solving the issue, but i have to use it to work around model preview
difficulties, when using many extruded bodies.
The boring materialist inside me, says it is all connected to the use of
the "scale" parameter, resize(), offset() and intersections with scaled
linear_extrude'd bodys walls. But he needs to be silent, as he has no
idea, i say.
OK alls the kidding aside, this issue is quite obscure to me, and causes
some headaches, appearing in much more complex context, sadly.
Could any wizard with the Openscad's code knowledge (be it sacred magic
numbers or just plan old c++ ) have a look and perhaps even fix the issue?
That would be so very cool!
Or is it a known issue?
Mysterious Regards
Peter
I don't duplicate the error that you encountered.
Reformatted for readability:
$fn=10;
difference() {
cube(25);
render(){
translate([0,0,50])
linear_extrude( height = 5, scale=[0.78, 0.75])
resize([47,40])
offset(r = 8)
square(10, center = true);
linear_extrude( height = 100)
resize([47,40])
offset(r = 8)
square(10, center = true);
}
}
Some comments:
- The first linear_extrude is flying at Z=50, well over the top of the
cube at Z=25, and so doesn't make any difference. - There's unsurprising Z-fighting at Z=0, where the bottom of the cube
is at the same Z value as the bottom of the extrusion being
subtracted from it. - I haven't used resize in a long time and wouldn't have thought to
use it here. I would have made the square be [23,16] with an offset
of 12, which is almost the same shape but done simpler. - Preview has a known rendering artifact that difference and
intersection don't display right if the camera is inside one of the
objects, so if your camera is a bit close you get artifacts. Mostly
they seem to make the cube look complete, wiping out the
difference. That's independent of whether or not the render() is there.
Net, I'd end up with:
$fn=10;
difference() {
cube(25);
translate([0,0,-1]) linear_extrude( height = 100+1)
offset(r = 12)
square([23,16], center = true);
}
Hope some of that is helpful.
There is a bug. It is convoluted. It may have been fixed.
TL;DR If you get ERROR: The given mesh is not closed! do Flush-cache then F6. (probably 99% of the time)
It is to do with the different internal formats OpenSCAD uses to represent geometry.
Different libraries are used for some operations, offset() uses the Clipper library.
IIRC simple primitives square() cube() etc build a simple mesh in preview, which
is recycled from cache on rendering - either F6 or render(). Whereas if no preview is
done CGAL builds the mesh for these simple objects, ie different code does it than in Preview.
While resize() and others (minkowski() - I'd have to go look to check others) must use CGAL even for preview.
For the final rendering some formats have to get translated into CGAL_Nef_Polyhedron,
the final format it generates, then used to Export etc. Preview does not need to do that conversion.
So this is why sometimes you get errors if you do a Preview then a Render, compared to
never Previewing (or equivalently doing Design/Flush-cache) then rendering.
So this specific problem will be the offset() as Clipper has used integers instead of
doubles used elsewhere (that is not the only possibility tho).
When that integer mesh gets converted to doubles the points of the geometry can get slightly misaligned,
resulting in "The given mesh is not closed!".
Hans has recently changed how this conversion is done, see here https://github.com/openscad/openscad/pull/3794#event-4822259778 .
While I'm not sure he was targeting this bug, I suspect it may overcome some of these problems.
I have not tested that yet.
-----Original Message-----
From: pproj@posteo.de [mailto:pproj@posteo.de]
Sent: Fri, 2 Jul 2021 07:38
To: OpenSCAD general discussion
Subject: [OpenSCAD] mystical numerology with render() resize() and extrude()
Mysterious greetings friends,
i have managed to narrow down a mystical singularity to the code below.
i can not figure out which particular combination of magical numbers
would be the border case, but it is reproducible with the following code:
//ERROR: The given mesh is not closed! Unable to convert to
CGAL_Nef_Polyhedron.
$fn=10;
difference()
{
cube(25);
render()
{
translate([0,0,50])
linear_extrude( height = 5, scale=[0.78, 0.75])
resize([47,40]) offset(r = 8)
square(10, center = true);
linear_extrude( height = 100)
resize([47,40]) offset(r = 8)
square(10, center = true);
}
}
i think this mystical conspiracy is also connected to the numbers 5 and
6 since pressing F5 and F6 produces completely different results.
removing the curse "render()" from the magic spell, removes the magic,
solving the issue, but i have to use it to work around model preview
difficulties, when using many extruded bodies.
The boring materialist inside me, says it is all connected to the use of
the "scale" parameter, resize(), offset() and intersections with scaled
linear_extrude'd bodys walls. But he needs to be silent, as he has no
idea, i say.
OK alls the kidding aside, this issue is quite obscure to me, and causes
some headaches, appearing in much more complex context, sadly.
Could any wizard with the Openscad's code knowledge (be it sacred magic
numbers or just plan old c++ ) have a look and perhaps even fix the issue?
That would be so very cool!
Or is it a known issue?
Mysterious Regards
Peter
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG.
https://www.avg.com
Michael, thanks for the great explanations!
this at least makes me understand the issue much better, removing some
obscurity
i wonder how the issue if affected by Hans's changes. I will give it a
try, when i am bit less busy.
Peter
On 02.07.21 09:25, MichaelAtOz wrote:
There is a bug. It is convoluted. It may have been fixed.
TL;DR If you get ERROR: The given mesh is not closed! do Flush-cache
then F6. (probably 99% of the time)
It is to do with the different internal formats OpenSCAD uses to
represent geometry.
Different libraries are used for some operations, offset() uses the
Clipper library.
IIRC simple primitives square() cube() etc build a simple mesh in
preview, which
is recycled from cache on rendering - either F6 or render(). Whereas
if no preview is
done CGAL builds the mesh for these simple objects, ie different code
does it than in Preview.
While resize() and others (minkowski() - I'd have to go look to check
others) must use CGAL even for preview.
For the final rendering some formats have to get translated into
CGAL_Nef_Polyhedron,
the final format it generates, then used to Export etc. Preview does
not need to do that conversion.
So this is why sometimes you get errors if you do a Preview then a
Render, compared to
never Previewing (or equivalently doing Design/Flush-cache) then
rendering.
So this specific problem will be the offset() as Clipper has used
integers instead of
doubles used elsewhere (that is not the only possibility tho).
When that integer mesh gets converted to doubles the points of the
geometry can get slightly misaligned,
resulting in "The given mesh is not closed!".
Hans has recently changed how this conversion is done, see here
https://github.com/openscad/openscad/pull/3794#event-4822259778.
While I'm not sure he was targeting this bug, I suspect it may
overcome some of these problems.
I have not tested that yet.
-----Original Message-----
From: pproj@posteo.de [mailto:pproj@posteo.de]
Sent: Fri, 2 Jul 2021 07:38
To: OpenSCAD general discussion
Subject: [OpenSCAD] mystical numerology with render() resize() and
extrude()
Mysterious greetings friends,
i have managed to narrow down a mystical singularity to the code below.
i can not figure out which particular combination of magical numbers
would be the border case, but it is reproducible with the following code:
//ERROR: The given mesh is not closed! Unable to convert to
CGAL_Nef_Polyhedron.
$fn=10;
difference()
{
cube(25);
render()
{
translate([0,0,50])
linear_extrude( height = 5, scale=[0.78, 0.75])
resize([47,40]) offset(r = 8)
square(10, center = true);
linear_extrude( height = 100)
resize([47,40]) offset(r = 8)
square(10, center = true);
}
}
i think this mystical conspiracy is also connected to the numbers 5 and
6 since pressing F5 and F6 produces completely different results.
removing the curse "render()" from the magic spell, removes the magic,
solving the issue, but i have to use it to work around model preview
difficulties, when using many extruded bodies.
The boring materialist inside me, says it is all connected to the use of
the "scale" parameter, resize(), offset() and intersections with scaled
linear_extrude'd bodys walls. But he needs to be silent, as he has no
idea, i say.
OK alls the kidding aside, this issue is quite obscure to me, and causes
some headaches, appearing in much more complex context, sadly.
Could any wizard with the Openscad's code knowledge (be it sacred magic
numbers or just plan old c++ ) have a look and perhaps even fix the issue?
That would be so very cool!
Or is it a known issue?
Mysterious Regards
Peter
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
Virus-free. www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Jordan, thanks for your help,
i am not really trying to create something with this code, i am trying
to reproduce the issue, the code issimplified to isolate the issue, not
more not less.
I find it strange, you did not have the same effect on your computer,
look what f5 andf6 produce any openscad from 01.21 and later on ubuntu.
I actually think Michael'S answer is Adressing it more.
but thank you anyway, regards Peter
On 02.07.21 00:09, Jordan Brown wrote:
I don't duplicate the error that you encountered.
Reformatted for readability:
$fn=10;
difference() {
cube(25);
render(){
translate([0,0,50])
linear_extrude( height = 5, scale=[0.78, 0.75])
resize([47,40])
offset(r = 8)
square(10, center = true);
linear_extrude( height = 100)
resize([47,40])
offset(r = 8)
square(10, center = true);
}
}
Some comments:
- The first linear_extrude is flying at Z=50, well over the top of
the cube at Z=25, and so doesn't make any difference. - There's unsurprising Z-fighting at Z=0, where the bottom of the
cube is at the same Z value as the bottom of the extrusion being
subtracted from it. - I haven't used resize in a long time and wouldn't have thought to
use it here. I would have made the square be [23,16] with an
offset of 12, which is almost the same shape but done simpler. - Preview has a known rendering artifact that difference and
intersection don't display right if the camera is inside one of
the objects, so if your camera is a bit close you get artifacts.
Mostly they seem to make the cube look complete, wiping out the
difference. That's independent of whether or not the render() is
there.
Net, I'd end up with:
$fn=10;
difference() {
cube(25);
translate([0,0,-1]) linear_extrude( height = 100+1)
offset(r = 12)
square([23,16], center = true);
}
Hope some of that is helpful.
