Re: [OpenSCAD] Odd render behavior
Hi,
This is a usual problem with limit situations. Maybe it is a problem with
CGAL libs, I don't know, a'm not an expert.
I use to alter one of the parameters by a small fractional number to
compensate for that. That procedure has no significant consequences in the
final object.
jpmendes
--
View this message in context: http://forum.openscad.org/Odd-render-behavior-tp15206p15209.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Yes, I know that torus(R,R) has a singularity at the origin for any R>0.
But this seems to be a problem for the render procedure only if there is
something else.
A torus with a singularity is non-manifold. Although it can be constructed
and displayed, you will get problems as soon as GCAL is called to do CSG
operations on it. It aborts with this: -
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e->incident_sface() != SFace_const_handle() File:
/data/OpenSCAD/libraries-mingw64-master/mxe-w64/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_S2/SM_const_decorator.h
Line: 326
Which is why the union fails to give the expected result.
On 18 December 2015 at 17:19, jpmendes jpmendes54@gmail.com wrote:
Hi,
This is a usual problem with limit situations. Maybe it is a problem with
CGAL libs, I don't know, a'm not an expert.
I use to alter one of the parameters by a small fractional number to
compensate for that. That procedure has no significant consequences in the
final object.
jpmendes
--
View this message in context:
http://forum.openscad.org/Odd-render-behavior-tp15206p15209.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
My very first OpenSCAD program was an attempt to make a checkerboard, and
it crashed because I created a "non-manifold object". (The bug has since
been fixed.) Here's the simplest reproduction of that bug I found:
square(10);
translate([10,10])square(10);
This program creates a "non-manifold" object. There is a singularity where
the two squares touch. However, due to some creative bug fixing, this now
renders just fine.
The torus with the singularity in the middle still doesn't render, it
seems. OpenSCAD has a general problem with models that are 3D printable,
but which are considered "non-manifold". Blame CGAL, or blame the decision
to represent 3D printable solid models as meshes. I've been playing with
non-mesh based 3D modelling software recently, which is why this is on my
mind.
On 18 December 2015 at 12:47, nop head nop.head@gmail.com wrote:
Yes, I know that torus(R,R) has a singularity at the origin for any R>0.
But this seems to be a problem for the render procedure only if there is
something else.
A torus with a singularity is non-manifold. Although it can be constructed
and displayed, you will get problems as soon as GCAL is called to do CSG
operations on it. It aborts with this: -
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e->incident_sface() != SFace_const_handle() File:
/data/OpenSCAD/libraries-mingw64-master/mxe-w64/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_S2/SM_const_decorator.h
Line: 326
Which is why the union fails to give the expected result.
On 18 December 2015 at 17:19, jpmendes jpmendes54@gmail.com wrote:
Hi,
This is a usual problem with limit situations. Maybe it is a problem with
CGAL libs, I don't know, a'm not an expert.
I use to alter one of the parameters by a small fractional number to
compensate for that. That procedure has no significant consequences in the
final object.
jpmendes
--
View this message in context:
http://forum.openscad.org/Odd-render-behavior-tp15206p15209.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
You can't print 3D models that are non manifold because it is physically
impossible. Whether you get something that approximates a singularity or a
mess depends on the slicer. Better to reject non manifold constructions and
error as early as possible to avoid confusion. Since real solids are always
manifold why is there a need to model nan-manifold objects?
On 18 December 2015 at 18:09, doug moen doug@moens.org wrote:
My very first OpenSCAD program was an attempt to make a checkerboard, and
it crashed because I created a "non-manifold object". (The bug has since
been fixed.) Here's the simplest reproduction of that bug I found:
square(10);
translate([10,10])square(10);
This program creates a "non-manifold" object. There is a singularity where
the two squares touch. However, due to some creative bug fixing, this now
renders just fine.
The torus with the singularity in the middle still doesn't render, it
seems. OpenSCAD has a general problem with models that are 3D printable,
but which are considered "non-manifold". Blame CGAL, or blame the decision
to represent 3D printable solid models as meshes. I've been playing with
non-mesh based 3D modelling software recently, which is why this is on my
mind.
On 18 December 2015 at 12:47, nop head nop.head@gmail.com wrote:
Yes, I know that torus(R,R) has a singularity at the origin for any R>0.
But this seems to be a problem for the render procedure only if there is
something else.
A torus with a singularity is non-manifold. Although it can be
constructed and displayed, you will get problems as soon as GCAL is called
to do CSG operations on it. It aborts with this: -
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e->incident_sface() != SFace_const_handle() File:
/data/OpenSCAD/libraries-mingw64-master/mxe-w64/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_S2/SM_const_decorator.h
Line: 326
Which is why the union fails to give the expected result.
On 18 December 2015 at 17:19, jpmendes jpmendes54@gmail.com wrote:
Hi,
This is a usual problem with limit situations. Maybe it is a problem with
CGAL libs, I don't know, a'm not an expert.
I use to alter one of the parameters by a small fractional number to
compensate for that. That procedure has no significant consequences in
the
final object.
jpmendes
--
View this message in context:
http://forum.openscad.org/Odd-render-behavior-tp15206p15209.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
doug.moen wrote
I've been playing with non-mesh based 3D modelling software recently,
which is why this is on my mind.
I'm curious about the non-mesh software, can you give an example ?
Ivo
--
View this message in context: http://forum.openscad.org/Odd-render-behavior-tp15206p15215.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
torus(R,R) represents a perfectly real, perfectly printable object. It is
only OpenSCAD that has a problem. For example, Antimony has a torus
primitive. I just tested this: I can create torus(10,10), export it to STL,
then import it into my 3D printing software and render as G-Code. I don't
get an error at any step of the process.
A torus is an idealized mathematical object that can't be exactly
represented by a mesh. The best we can get is an approximation of a torus.
Since we are dealing with approximations anyway, there's no reason why
torus.stl, the STL approximation of 'torus(R,R)', can't be a manifold
object.
On 18 December 2015 at 13:51, nop head nop.head@gmail.com wrote:
You can't print 3D models that are non manifold because it is physically
impossible. Whether you get something that approximates a singularity or a
mess depends on the slicer. Better to reject non manifold constructions and
error as early as possible to avoid confusion. Since real solids are always
manifold why is there a need to model nan-manifold objects?
On 18 December 2015 at 18:09, doug moen doug@moens.org wrote:
My very first OpenSCAD program was an attempt to make a checkerboard, and
it crashed because I created a "non-manifold object". (The bug has since
been fixed.) Here's the simplest reproduction of that bug I found:
square(10);
translate([10,10])square(10);
This program creates a "non-manifold" object. There is a singularity
where the two squares touch. However, due to some creative bug fixing, this
now renders just fine.
The torus with the singularity in the middle still doesn't render, it
seems. OpenSCAD has a general problem with models that are 3D printable,
but which are considered "non-manifold". Blame CGAL, or blame the decision
to represent 3D printable solid models as meshes. I've been playing with
non-mesh based 3D modelling software recently, which is why this is on my
mind.
On 18 December 2015 at 12:47, nop head nop.head@gmail.com wrote:
Yes, I know that torus(R,R) has a singularity at the origin for any
R>0. But this seems to be a problem for the render procedure only if there
is something else.
A torus with a singularity is non-manifold. Although it can be
constructed and displayed, you will get problems as soon as GCAL is called
to do CSG operations on it. It aborts with this: -
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e->incident_sface() != SFace_const_handle() File:
/data/OpenSCAD/libraries-mingw64-master/mxe-w64/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_S2/SM_const_decorator.h
Line: 326
Which is why the union fails to give the expected result.
On 18 December 2015 at 17:19, jpmendes jpmendes54@gmail.com wrote:
Hi,
This is a usual problem with limit situations. Maybe it is a problem
with
CGAL libs, I don't know, a'm not an expert.
I use to alter one of the parameters by a small fractional number to
compensate for that. That procedure has no significant consequences in
the
final object.
jpmendes
--
View this message in context:
http://forum.openscad.org/Odd-render-behavior-tp15206p15209.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
torus(R,R) represents a perfectly real, perfectly printable object.
No it doesn't, it has an infinitely thin singularity in the middle. You
can't print that, the best you can get is one atom thick, or no atoms but
that is a hole. I don't think it classes as 2-manifold mathematically.
When you printed it you may have got lucky and not got a slice exactly
through the singularity, or have a slicer that didn't care. It's pretty
undefined what will happen when you produce non-manifold STLs and slice
them.
Why not model it as torus(R,R - epsilon) which avoids all the problems?
On 18 December 2015 at 22:49, doug moen doug@moens.org wrote:
torus(R,R) represents a perfectly real, perfectly printable object. It is
only OpenSCAD that has a problem. For example, Antimony has a torus
primitive. I just tested this: I can create torus(10,10), export it to STL,
then import it into my 3D printing software and render as G-Code. I don't
get an error at any step of the process.
A torus is an idealized mathematical object that can't be exactly
represented by a mesh. The best we can get is an approximation of a torus.
Since we are dealing with approximations anyway, there's no reason why
torus.stl, the STL approximation of 'torus(R,R)', can't be a manifold
object.
On 18 December 2015 at 13:51, nop head nop.head@gmail.com wrote:
You can't print 3D models that are non manifold because it is physically
impossible. Whether you get something that approximates a singularity or a
mess depends on the slicer. Better to reject non manifold constructions and
error as early as possible to avoid confusion. Since real solids are always
manifold why is there a need to model nan-manifold objects?
On 18 December 2015 at 18:09, doug moen doug@moens.org wrote:
My very first OpenSCAD program was an attempt to make a checkerboard,
and it crashed because I created a "non-manifold object". (The bug has
since been fixed.) Here's the simplest reproduction of that bug I found:
square(10);
translate([10,10])square(10);
This program creates a "non-manifold" object. There is a singularity
where the two squares touch. However, due to some creative bug fixing, this
now renders just fine.
The torus with the singularity in the middle still doesn't render, it
seems. OpenSCAD has a general problem with models that are 3D printable,
but which are considered "non-manifold". Blame CGAL, or blame the decision
to represent 3D printable solid models as meshes. I've been playing with
non-mesh based 3D modelling software recently, which is why this is on my
mind.
On 18 December 2015 at 12:47, nop head nop.head@gmail.com wrote:
Yes, I know that torus(R,R) has a singularity at the origin for any
R>0. But this seems to be a problem for the render procedure only if there
is something else.
A torus with a singularity is non-manifold. Although it can be
constructed and displayed, you will get problems as soon as GCAL is called
to do CSG operations on it. It aborts with this: -
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion
violation! Expr: e->incident_sface() != SFace_const_handle() File:
/data/OpenSCAD/libraries-mingw64-master/mxe-w64/usr/x86_64-w64-mingw32.static/include/CGAL/Nef_S2/SM_const_decorator.h
Line: 326
Which is why the union fails to give the expected result.
On 18 December 2015 at 17:19, jpmendes jpmendes54@gmail.com wrote:
Hi,
This is a usual problem with limit situations. Maybe it is a problem
with
CGAL libs, I don't know, a'm not an expert.
I use to alter one of the parameters by a small fractional number to
compensate for that. That procedure has no significant consequences in
the
final object.
jpmendes
--
View this message in context:
http://forum.openscad.org/Odd-render-behavior-tp15206p15209.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Every odd behavior is bug ;-)
module torus(R, r) {
rotate_extrude(convexity = 4, $fn = 50)
translate([R, 0, 0]) circle(r = r, $fn = 30);
}
// cube(size=15, center = true);
torus(15, 15);
this renders with F6. So torus seems to be fine as long it hasn't passed
through an operator.
cube(size=15, center = true);
torus(15, 15);
this doesn't render with F6. So it seems, that the union() operator is not
working as expected. It might have a problem with the singular point [0, 0,
0] which is deleted anyway, when the cube is centered. So CGAL could check
and neclect this. Once the singularity point is part of both objects it
could decide from the second object.
But what if the objects are not intersecting?
translate([50, 20, 20])
cube(size=15, center = true);
torus(15, 15);
guess what?
So let's look at the translation operator:
translate([50, 20, 20])
torus(15, 15);
it does no harm! But intersection(), union() and difference() do harm. So it
is the boolean operations that change the object.
Of course there are work-arounds like
cube(size=15, center = true);
torus(15, 14.999999999);
but this is not the point.
--
View this message in context: http://forum.openscad.org/Odd-render-behavior-tp15206p15223.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
torus(R,R - epsilon) is a torus. torus(R, R + epsilon) is topologically not
a torus, more like a disc. torus(R,R) is topologically ambiguous. It is no
wonder a program modelling 3D solids has problems with it. The only bug is
it should immediately declare torus(R,R) to be non manifold and refuse to
do anything with it, so as not to confuse people.
On 19 December 2015 at 01:16, Parkinbot rudolf@parkinbot.com wrote:
Every odd behavior is bug ;-)
module torus(R, r) {
rotate_extrude(convexity = 4, $fn = 50)
translate([R, 0, 0]) circle(r = r, $fn = 30);
}
// cube(size=15, center = true);
torus(15, 15);
this renders with F6. So torus seems to be fine as long it hasn't passed
through an operator.
cube(size=15, center = true);
torus(15, 15);
this doesn't render with F6. So it seems, that the union() operator is not
working as expected. It might have a problem with the singular point [0, 0,
0] which is deleted anyway, when the cube is centered. So CGAL could check
and neclect this. Once the singularity point is part of both objects it
could decide from the second object.
But what if the objects are not intersecting?
translate([50, 20, 20])
cube(size=15, center = true);
torus(15, 15);
guess what?
So let's look at the translation operator:
translate([50, 20, 20])
torus(15, 15);
it does no harm! But intersection(), union() and difference() do harm. So
it
is the boolean operations that change the object.
Of course there are work-arounds like
cube(size=15, center = true);
torus(15, 14.999999999);
but this is not the point.
--
View this message in context:
http://forum.openscad.org/Odd-render-behavior-tp15206p15223.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nophead wrote
The only bug is it should immediately declare torus(R,R) to be non
manifold and refuse to
do anything with it, so as not to confuse people.
bug is bug. The easiest solution would be to exclude singular points [0, y]
for rotate_extrude() and throw something like "ERROR: all points for
rotate_extrude() must have same X coordinate sign and must not be singular
with X coordinate equal 0".
Have a look at this:
cube(10);
translate([-10, -10, -10])
cube(10);
This gives a warning only (as the singularity is after the union). By the
way, the warning is the behavior I would expect!
nophead wrote
torus(R, R + epsilon) is topologically not a torus,
Are you sure? I would say, it depends on the sign of epsilon ;-) and on the
semantics of rotate_extrude().
One could do even better and also allow for negative signs and treat
singular [0,Y] points extra. Actually I would implement it like this
- cut off all parts with negative X values in the sense of square(R) }
intersection(){shape2D(); translate([0,-R/2])cube(R) // R chosen
suffiently large
- give a warning on singular [0,Y] points. (for now no language means
exist to express this!)
- Rudolf
--
View this message in context: http://forum.openscad.org/Odd-render-behavior-tp15206p15227.html
Sent from the OpenSCAD mailing list archive at Nabble.com.