Evaluating imported STL's
Rudolf,
I had taken mistakenly your scale(0) sphere(). I had assumed (without
testing it) that it is incorrectly evaluated as an empty set. But no, it is
a point: the origin! Preview that:
hull() {
sphere(5);
translate([0,0,12]) scale(0) sphere();
}
The result is mathematically correct: the convex hull of the sphere(5) with
the point [0,0,12]. So, scale(0) (or equivalently your multmatrix stuff)
transform anything into a point, the origin, in a way that can be
translated, rotated and scaled again.
Why didn't you get anything in the stl file? Because there is no facets in
scale(0) sphere() just one vertex.
Besides,
minkovsky() {
cube(5);
translate([0,0,12]) scale(0) sphere();
}
is equivalent to translate([0,0,12]) cube(5), which is correct because
scale(0) sphere() is not the empty set.
--
View this message in context: http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17723.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Interesting concept that of degenerate solids, very interesting
implications:
Say goobye to differentiating 2D from 3D shapes. All objects could be
represented as a set of vertices, and faces. An object with:
- No vertexes is a void().
- One vertex, no faces is a point().
- Two vertexes in a face is a line().
- Several coplanar vertexes and faces is a single 2d face().
- Several watertight faces is a solid().
Best of all is that this would allow us to mix them up in any configuration.
- scale([0,0,0]) degenerates any non-void thing to a point at (0,0,0). Void
stays void. - scale([1,1,0]) would do pretty much the same as project(), by killing off
the Z coordinate, but could be used to project to ZX and ZY planes too. - scale([0,0,1]) could be used to get a line along the Z axis exactly the
same height as out solids. - minkowski() { point(); thing(); } would act exactly as translate thing.
- minkowski() { line(); face(); } would act like linear_extrude, except the
line could be any angle. If the line is coplanar to the original face, then
the result ends up being another face(). - minkowski() { line(); solid(); } would extrude a solid! Pretty much like
a hull(), but would work for concave shapes too. - minkowski() { face1(); face2(); } might end up building a larger face(),
or a solid if faces are not coplanar. - hull() would work on non-coplanar faces() and result in a solid().
However, I assume this would be a massive amount of work, and should not be
expected anytime soon...
--
Lucas Vinicius Hartmann
Dizem que se você rodar o CD do Windows ao contrário ele mostra uma
mensagem demoníaca... Mas isso nem é o pior, se você rodar ele normal ele
instala o Windows!
2016-06-16 13:16 GMT-03:00 Ronaldo rcmpersiano@gmail.com:
Rudolf,
You raised good points but I will keep mine about Minkowski. The example
you
have shown of a vanishing cube is idiosyncratic but for other reasons. I
would expect that
scale(0) sphere;
to be a point, the origin, and not a void set.
In Mathematics, you have a non-void set by doing a Minkowski sum of a point
and a non-void set. I thought we have no way in OpenSCAD to do a Minkowski
sum of a set with only a point or a line segment or a 2D shape due to the
simple fact that we can't express such sets or mix 2D shapes with 3D shapes
in OpenSCAD operations. However, we can at least in Minkowski operations.
minkowski() {
cube(1);
intersection() {
cube(1);
translate([$t-1,$t-1,$t-1]) cube(1);
}
}
And that is not idiosyncratic. It does exactly what I would expect. The
intersection is not void, it is a square that shrinks to the origin when
$t=0. The scaled sphere should do the same.
BTW, the above "technique" may be very usefull for rounding only some edges
of a solid.
There is much more complexities behind the scene... :)
--
View this message in context:
http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17717.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
Unfortunately the point hacked with scale(0) is not well behaved. The code
below crashed openscad every time I asked it to render...
module point(at=[0,0,0]) {
translate(at) scale(0) cube();
}
minkowski() {
point([0,0,0]);
point([1,0,0]);
point([0,1,1]);
point([0,0,1]);
}
--
Lucas Vinicius Hartmann
Dizem que se você rodar o CD do Windows ao contrário ele mostra uma
mensagem demoníaca... Mas isso nem é o pior, se você rodar ele normal ele
instala o Windows!
2016-06-16 18:26 GMT-03:00 Ronaldo rcmpersiano@gmail.com:
Rudolf,
I had taken mistakenly your scale(0) sphere(). I had assumed (without
testing it) that it is incorrectly evaluated as an empty set. But no, it is
a point: the origin! Preview that:
hull() {
sphere(5);
translate([0,0,12]) scale(0) sphere();
}
The result is mathematically correct: the convex hull of the sphere(5) with
the point [0,0,12]. So, scale(0) (or equivalently your multmatrix stuff)
transform anything into a point, the origin, in a way that can be
translated, rotated and scaled again.
Why didn't you get anything in the stl file? Because there is no facets in
scale(0) sphere() just one vertex.
Besides,
minkovsky() {
cube(5);
translate([0,0,12]) scale(0) sphere();
}
is equivalent to translate([0,0,12]) cube(5), which is correct because
scale(0) sphere() is not the empty set.
--
View this message in context:
http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17723.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
Lucas,
Although in Mathematics we can apply the operators convex hull and Minkowski
sum to any set of sets. I did not saw until today how to do it in OpenSCAD.
The properties and object you have summarized open up a whole set of
possibilities to modelling with OpenSCAD. That is why a started a new thread
a while ago showing some of them and to concentrate the discussion on the
subject.
Although hull() works well with 2D, 1D and 0D objects alone, the minkowski()
on fact requires that at least one of the operands to be a real 3D object,
and possibly a manifold. This seems to be a restriction of CGAL.
--
View this message in context: http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17731.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
scale(0) doesn't make a single point. It shrinks the shape to zero size so
all its vertices are coincident and then it is not a manifold hence CGAL
doesn't like it.
On 17 June 2016 at 05:07, Ronaldo rcmpersiano@gmail.com wrote:
Lucas,
Although in Mathematics we can apply the operators convex hull and
Minkowski
sum to any set of sets. I did not saw until today how to do it in OpenSCAD.
The properties and object you have summarized open up a whole set of
possibilities to modelling with OpenSCAD. That is why a started a new
thread
a while ago showing some of them and to concentrate the discussion on the
subject.
Although hull() works well with 2D, 1D and 0D objects alone, the
minkowski()
on fact requires that at least one of the operands to be a real 3D object,
and possibly a manifold. This seems to be a restriction of CGAL.
--
View this message in context:
http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17731.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
scale(0) doesn't make a single point. It shrinks the shape to zero size so
all its vertices are coincident and then it is not a manifold hence CGAL
doesn't like it.
I checked the assumption by substituting the cube by a sphere with $fn=256.
There were no significant increase in processing time. So I think the
vertices are collapsed to a point.
Besides, although CGAL doesn't like non-manifold objects, the whole process
works with this version.
--
View this message in context: http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17750.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Lucas said:
Interesting concept that of degenerate solids, very interesting
implications:
Say goodbye to differentiating 2D from 3D shapes. All objects could be
represented as a set of vertices, and faces. An object with:
- No vertexes is a void().
- One vertex, no faces is a point().
- Two vertexes in a face is a line().
- Several coplanar vertexes and faces is a single 2d face().
- Several watertight faces is a solid().
Best of all is that this would allow us to mix them up in any configuration.
"However, I assume this would be a massive amount of work..."
I'm not sure this would make practical sense, even if you are implementing
a new geometry engine from scratch. Although this idea would work in the
realm of pure mathematics, I don't think it would survive contact with
floating point numbers and STL files. In addition, it might create a lot of
unexpected behaviour.
Our current geometry system considers 2D objects and 3D objects to be
different types, and I think that is necessary for practical reasons. One
issue is that we use different libraries for 2D and 3D objects: CGAL for 3D
CSG operations, Clipper for 2D. Another issue is that this plan implies
that a 2D object could be created as the output of an operation on 3D
objects, and then operations with 2D arguments like rotate_extrude would be
expected to recognize these objects as 2D and accept them as legal input.
In that case, floating point imprecision could be the deciding factor in
whether an object is considered 2D or 3D. It's cleaner and more robust to
distinguish 2D and 3D objects using different types.
The second issue is this: in what situations do operations on 3D objects
produce degenerate results which are then treated as valid input to other
operations?
Suppose you do this:
intersection() {
cube([10,10,10]);
translate([10,10,10]) cube([10,10,10]);
}
Mathematically, these two cubes intersect at exactly one geometric point,
[10,10,10]. Should the intersection operation produce a degenerate 3D
object, which can be used as valid input to minkowski() and other
operators? Currently, the CSG operations discard these kinds of degenerate
results (eg, intersecting at a point, line or plane). Do we really want to
change this behaviour?
If we really wanted to support degenerate objects (eg, because they allow
minkowski() to work in an intuitively correct way in Parkinbot's example),
then I think that degenerate objects would need to have a distinct type,
and objects of this type should only be generated under well defined
circumstances. For example, we could define cube(0), sphere(0) and scale(0)
X to return geometric point objects, and we could explicitly define what
happens when geometric points are passed as arguments to various geometric
operations. For sure, CGAL won't tolerate degenerate input, so we need to
do something different than just feed degenerate input to CGAL like we do
now.
I'm not sure it's worthwhile to formalize geometric points like this. I
think that a higher priority is to make OpenSCAD stop crashing when
degenerate objects are constructed. The simplest fix might be to
discard degenerate objects, or map them onto void whenever they are
constructed. This would break certain uses of minkowski(), but would also
make OpenSCAD have more predictable and robust behaviour. The question then
becomes, how important are these minkowski edge cases?
On 16 June 2016 at 21:33, Lucas Vinicius Hartmann lucas.hartmann@gmail.com
wrote:
Interesting concept that of degenerate solids, very interesting
implications:
Say goobye to differentiating 2D from 3D shapes. All objects could be
represented as a set of vertices, and faces. An object with:
- No vertexes is a void().
- One vertex, no faces is a point().
- Two vertexes in a face is a line().
- Several coplanar vertexes and faces is a single 2d face().
- Several watertight faces is a solid().
Best of all is that this would allow us to mix them up in any
configuration.
- scale([0,0,0]) degenerates any non-void thing to a point at (0,0,0).
Void stays void. - scale([1,1,0]) would do pretty much the same as project(), by killing
off the Z coordinate, but could be used to project to ZX and ZY planes too. - scale([0,0,1]) could be used to get a line along the Z axis exactly the
same height as out solids. - minkowski() { point(); thing(); } would act exactly as translate thing.
- minkowski() { line(); face(); } would act like linear_extrude, except
the line could be any angle. If the line is coplanar to the original face,
then the result ends up being another face(). - minkowski() { line(); solid(); } would extrude a solid! Pretty much like
a hull(), but would work for concave shapes too. - minkowski() { face1(); face2(); } might end up building a larger face(),
or a solid if faces are not coplanar. - hull() would work on non-coplanar faces() and result in a solid().
However, I assume this would be a massive amount of work, and should not
be expected anytime soon...
--
Lucas Vinicius Hartmann
Dizem que se você rodar o CD do Windows ao contrário ele mostra uma
mensagem demoníaca... Mas isso nem é o pior, se você rodar ele normal ele
instala o Windows!
2016-06-16 13:16 GMT-03:00 Ronaldo rcmpersiano@gmail.com:
Rudolf,
You raised good points but I will keep mine about Minkowski. The example
you
have shown of a vanishing cube is idiosyncratic but for other reasons. I
would expect that
scale(0) sphere;
to be a point, the origin, and not a void set.
In Mathematics, you have a non-void set by doing a Minkowski sum of a
point
and a non-void set. I thought we have no way in OpenSCAD to do a Minkowski
sum of a set with only a point or a line segment or a 2D shape due to the
simple fact that we can't express such sets or mix 2D shapes with 3D
shapes
in OpenSCAD operations. However, we can at least in Minkowski operations.
minkowski() {
cube(1);
intersection() {
cube(1);
translate([$t-1,$t-1,$t-1]) cube(1);
}
}
And that is not idiosyncratic. It does exactly what I would expect. The
intersection is not void, it is a square that shrinks to the origin when
$t=0. The scaled sphere should do the same.
BTW, the above "technique" may be very usefull for rounding only some
edges
of a solid.
There is much more complexities behind the scene... :)
--
View this message in context:
http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17717.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
I think hull() and minkowski() (which can be made using hull) are special
cases because they only need to consider the vertices, not edges or faces.
That is why they will accept degenerate shapes and make valid 3D shapes
from them. Perhaps that could be a documented feature of openscad without
having to re-write it.
On 17 June 2016 at 23:43, doug moen doug@moens.org wrote:
Lucas said:
Interesting concept that of degenerate solids, very interesting
implications:
Say goodbye to differentiating 2D from 3D shapes. All objects could be
represented as a set of vertices, and faces. An object with:
- No vertexes is a void().
- One vertex, no faces is a point().
- Two vertexes in a face is a line().
- Several coplanar vertexes and faces is a single 2d face().
- Several watertight faces is a solid().
Best of all is that this would allow us to mix them up in any
configuration.
"However, I assume this would be a massive amount of work..."
I'm not sure this would make practical sense, even if you are implementing
a new geometry engine from scratch. Although this idea would work in the
realm of pure mathematics, I don't think it would survive contact with
floating point numbers and STL files. In addition, it might create a lot of
unexpected behaviour.
Our current geometry system considers 2D objects and 3D objects to be
different types, and I think that is necessary for practical reasons. One
issue is that we use different libraries for 2D and 3D objects: CGAL for 3D
CSG operations, Clipper for 2D. Another issue is that this plan implies
that a 2D object could be created as the output of an operation on 3D
objects, and then operations with 2D arguments like rotate_extrude would be
expected to recognize these objects as 2D and accept them as legal input.
In that case, floating point imprecision could be the deciding factor in
whether an object is considered 2D or 3D. It's cleaner and more robust to
distinguish 2D and 3D objects using different types.
The second issue is this: in what situations do operations on 3D objects
produce degenerate results which are then treated as valid input to other
operations?
Suppose you do this:
intersection() {
cube([10,10,10]);
translate([10,10,10]) cube([10,10,10]);
}
Mathematically, these two cubes intersect at exactly one geometric point,
[10,10,10]. Should the intersection operation produce a degenerate 3D
object, which can be used as valid input to minkowski() and other
operators? Currently, the CSG operations discard these kinds of degenerate
results (eg, intersecting at a point, line or plane). Do we really want to
change this behaviour?
If we really wanted to support degenerate objects (eg, because they allow
minkowski() to work in an intuitively correct way in Parkinbot's example),
then I think that degenerate objects would need to have a distinct type,
and objects of this type should only be generated under well defined
circumstances. For example, we could define cube(0), sphere(0) and scale(0)
X to return geometric point objects, and we could explicitly define what
happens when geometric points are passed as arguments to various geometric
operations. For sure, CGAL won't tolerate degenerate input, so we need to
do something different than just feed degenerate input to CGAL like we do
now.
I'm not sure it's worthwhile to formalize geometric points like this. I
think that a higher priority is to make OpenSCAD stop crashing when
degenerate objects are constructed. The simplest fix might be to
discard degenerate objects, or map them onto void whenever they are
constructed. This would break certain uses of minkowski(), but would also
make OpenSCAD have more predictable and robust behaviour. The question then
becomes, how important are these minkowski edge cases?
On 16 June 2016 at 21:33, Lucas Vinicius Hartmann <
lucas.hartmann@gmail.com> wrote:
Interesting concept that of degenerate solids, very interesting
implications:
Say goobye to differentiating 2D from 3D shapes. All objects could be
represented as a set of vertices, and faces. An object with:
- No vertexes is a void().
- One vertex, no faces is a point().
- Two vertexes in a face is a line().
- Several coplanar vertexes and faces is a single 2d face().
- Several watertight faces is a solid().
Best of all is that this would allow us to mix them up in any
configuration.
- scale([0,0,0]) degenerates any non-void thing to a point at (0,0,0).
Void stays void. - scale([1,1,0]) would do pretty much the same as project(), by killing
off the Z coordinate, but could be used to project to ZX and ZY planes too. - scale([0,0,1]) could be used to get a line along the Z axis exactly the
same height as out solids. - minkowski() { point(); thing(); } would act exactly as translate thing.
- minkowski() { line(); face(); } would act like linear_extrude, except
the line could be any angle. If the line is coplanar to the original face,
then the result ends up being another face(). - minkowski() { line(); solid(); } would extrude a solid! Pretty much
like a hull(), but would work for concave shapes too. - minkowski() { face1(); face2(); } might end up building a larger
face(), or a solid if faces are not coplanar. - hull() would work on non-coplanar faces() and result in a solid().
However, I assume this would be a massive amount of work, and should not
be expected anytime soon...
--
Lucas Vinicius Hartmann
Dizem que se você rodar o CD do Windows ao contrário ele mostra uma
mensagem demoníaca... Mas isso nem é o pior, se você rodar ele normal ele
instala o Windows!
2016-06-16 13:16 GMT-03:00 Ronaldo rcmpersiano@gmail.com:
Rudolf,
You raised good points but I will keep mine about Minkowski. The example
you
have shown of a vanishing cube is idiosyncratic but for other reasons. I
would expect that
scale(0) sphere;
to be a point, the origin, and not a void set.
In Mathematics, you have a non-void set by doing a Minkowski sum of a
point
and a non-void set. I thought we have no way in OpenSCAD to do a
Minkowski
sum of a set with only a point or a line segment or a 2D shape due to the
simple fact that we can't express such sets or mix 2D shapes with 3D
shapes
in OpenSCAD operations. However, we can at least in Minkowski operations.
minkowski() {
cube(1);
intersection() {
cube(1);
translate([$t-1,$t-1,$t-1]) cube(1);
}
}
And that is not idiosyncratic. It does exactly what I would expect. The
intersection is not void, it is a square that shrinks to the origin when
$t=0. The scaled sphere should do the same.
BTW, the above "technique" may be very usefull for rounding only some
edges
of a solid.
There is much more complexities behind the scene... :)
--
View this message in context:
http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17717.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