Joining half tubes
It's a lot more complicated than rounding numbers. Whenever you truncate
the precision of the vertex coordinates you risk making vertices that were
distinct no longer distinct and that breaks the topology and has to be
fixed up, which isn't easy.
On Mon, 10 Jun 2019 at 18:50, Dan Shriver tabbydan@gmail.com wrote:
Not to beat a dead horse....
Sounds like floating problems could be fixed with some functions that
round to an input power of 2 (2^-1),(2^-2)....(2^-n). Is there such a
function out there?
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
<#m_-8249479398674947623_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Sat, Jun 8, 2019 at 12:54 PM nop head nop.head@gmail.com wrote:
These sorts of problems are usually caused by creating vertices that due
to numerical error are not exactly coincident but very nearly are. They
then get collapsed due to floating point number representation and that
breaks the topology, creating holes, self intersections or degenerate
triangles. You don't notice until you try to do 3D CSG operations and then
CGAL will barf.
Think of it like this. Suppose you intersect a square with a circle
(which is actually a polygon with sloping sides). Mathematically the
intersection of a diagonal line with a square will create points exactly on
the original lines. In practice though, without infinite precision the
points will be slightly one side or the other. If you then union or
difference it with the original circle you create unimaginably small
slivers.
You need to always make sure vertices are either exactly the same or
significantly different when represented in floating point numbers. It is
OK to stack integer sized cubes with exactly coincident faces but not, for
example, 0.1 cubes because 0.1 is a recurring fraction in binary. In
general there should always be some overlap when doing CSG operations.
On Sat, 8 Jun 2019 at 17:38, Dan Shriver tabbydan@gmail.com wrote:
You are correct. Union with a cube gives an error too. But I can't
tell from the error what is wrong.
If I do half the shape it renders fine and looks correct. How do I
locate the problem?
On Sat, Jun 8, 2019 at 12:20 PM nop head nop.head@gmail.com wrote:
There is probably something wrong with arches2. Try unioning it with a
unit cube.
On Sat, 8 Jun 2019, 17:13 Dan Shriver, tabbydan@gmail.com wrote:
I'm trying to make a complicated shape.
A quick way to imagine it is that I have a half tube on a wishbone
path.
Making half of it (just a call to arches2()) works fine.
However if I use difference and mirror I get errors.
At first I thought it was because I was trying to subtract a mirrored
half tube from a mirrored half tube causing some issues. So I changed it
so (from the first half tube) I subtract the solid version (if a half tube
imagine a half circle being subtracted from it).
However, when I do that I still get problems:
difference() {
arches2(24); //imagine a half tube
mirror([0,0,1]) {
arches2(24,true); //imagine a half circle
}
}
mirror([0,0,1]) {
arches2(24); //adding back in the half tube mirrored
}
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e_below != SHalfedge_handle() File:
/opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
Line: 426
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e_below != SHalfedge_handle() File:
/opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
Line: 426
Geometries in cache: 11
Geometry cache size in bytes: 5770888
CGAL Polyhedrons in cache: 4
CGAL cache size in bytes: 0
Total rendering time: 0 hours, 0 minutes, 14 seconds
Rendering finished.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
<#m_-8249479398674947623_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I'm making individual polygon slices. An arch slices is either a roman
arch type slice, or an ogee arch type slice. I have three of these "basic"
type arches (a fat roman arch, an ogee arch, and a thin roman arch).
Slices between these types are interpolated via abs(sin(0-180)). The
coordinates of an in-between slice are the coordinates of the starting
slice multiplied by sin(angle) and added to the ending slice which is
multiplied by (1-sin(angle)). The midpoint of the bottom of each slice
lies along a curve that is half of an ogee. At the end I use skin to make
a solid out of all the slices.
I'm not "knowingly" doing any truncation- but I do imagine I get lots of
horrible numbers that don't fit nicely into powers of two, and every time I
do an operation on those the errors probably compound.
Can you suggest an approach to avoid my problems?
Fortunately, by itself it will render (even though it isn't a valid solid),
which gives me an idea of how it looks:
[image: image.png]
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon
Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Mon, Jun 10, 2019 at 2:06 PM nop head nop.head@gmail.com wrote:
It's a lot more complicated than rounding numbers. Whenever you truncate
the precision of the vertex coordinates you risk making vertices that were
distinct no longer distinct and that breaks the topology and has to be
fixed up, which isn't easy.
On Mon, 10 Jun 2019 at 18:50, Dan Shriver tabbydan@gmail.com wrote:
Not to beat a dead horse....
Sounds like floating problems could be fixed with some functions that
round to an input power of 2 (2^-1),(2^-2)....(2^-n). Is there such a
function out there?
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
<#m_8423988058787747195_m_-8249479398674947623_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Sat, Jun 8, 2019 at 12:54 PM nop head nop.head@gmail.com wrote:
These sorts of problems are usually caused by creating vertices that due
to numerical error are not exactly coincident but very nearly are. They
then get collapsed due to floating point number representation and that
breaks the topology, creating holes, self intersections or degenerate
triangles. You don't notice until you try to do 3D CSG operations and then
CGAL will barf.
Think of it like this. Suppose you intersect a square with a circle
(which is actually a polygon with sloping sides). Mathematically the
intersection of a diagonal line with a square will create points exactly on
the original lines. In practice though, without infinite precision the
points will be slightly one side or the other. If you then union or
difference it with the original circle you create unimaginably small
slivers.
You need to always make sure vertices are either exactly the same or
significantly different when represented in floating point numbers. It is
OK to stack integer sized cubes with exactly coincident faces but not, for
example, 0.1 cubes because 0.1 is a recurring fraction in binary. In
general there should always be some overlap when doing CSG operations.
On Sat, 8 Jun 2019 at 17:38, Dan Shriver tabbydan@gmail.com wrote:
You are correct. Union with a cube gives an error too. But I can't
tell from the error what is wrong.
If I do half the shape it renders fine and looks correct. How do I
locate the problem?
On Sat, Jun 8, 2019 at 12:20 PM nop head nop.head@gmail.com wrote:
There is probably something wrong with arches2. Try unioning it with a
unit cube.
On Sat, 8 Jun 2019, 17:13 Dan Shriver, tabbydan@gmail.com wrote:
I'm trying to make a complicated shape.
A quick way to imagine it is that I have a half tube on a wishbone
path.
Making half of it (just a call to arches2()) works fine.
However if I use difference and mirror I get errors.
At first I thought it was because I was trying to subtract a mirrored
half tube from a mirrored half tube causing some issues. So I changed it
so (from the first half tube) I subtract the solid version (if a half tube
imagine a half circle being subtracted from it).
However, when I do that I still get problems:
difference() {
arches2(24); //imagine a half tube
mirror([0,0,1]) {
arches2(24,true); //imagine a half circle
}
}
mirror([0,0,1]) {
arches2(24); //adding back in the half tube mirrored
}
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e_below != SHalfedge_handle() File:
/opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
Line: 426
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e_below != SHalfedge_handle() File:
/opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
Line: 426
Geometries in cache: 11
Geometry cache size in bytes: 5770888
CGAL Polyhedrons in cache: 4
CGAL cache size in bytes: 0
Total rendering time: 0 hours, 0 minutes, 14 seconds
Rendering finished.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
<#m_8423988058787747195_m_-8249479398674947623_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I'm making individual polygon slices. An arch slices is either a roman
arch type slice, or an ogee arch type slice. I have three of these "basic"
type arches (a fat roman arch, an ogee arch, and a thin roman arch).
Slices between these types are interpolated via abs(sin(0-180)). The
coordinates of an in-between slice are the coordinates of the starting
slice multiplied by sin(angle) and added to the ending slice which is
multiplied by (1-sin(angle)). The midpoint of the bottom of each slice
lies along a curve that is half of an ogee. At the end I use skin to make
a solid out of all the slices.
Have you tried to reduce your problem to the minimal case that causes the
problem? I think that until you nail down what the problem is---until you
know for sure rather than just guessing---it's hard to speculate about how
to solve it. Are you sure that your procedure produces a valid polyhedron,
without self-intersections? I'm not sure I understand exactly how round-off
error creates problems, but it seems like the solution is to never compute a
point that is supposed to be the same a second time. Then any round-off
would necessarily be consistent. What happens if you build up your problem
with just two slices? Just three lices? When does it break?
Once you understand exactly how it's broken you will be able to figure out
how to avoid the problem. But again, you need to figure out what the
problem is, and the way to do that is to start cutting away parts of your
model until the problem goes away so that you can clearly identify what
addition causes the problem. If you can post some code that demonstrates
your problem which is reasonably short and accessible then somebody may be
able to give you suggestions, but figuring out your full code is too much
work, at least for me.
--
Sent from: http://forum.openscad.org/