Unusual hull() and minkowski modelling
Ronaldo
As a programmer, I wouldn't call all that a 'trick'. It's a full-grown
backdoor, and in its implication it is quite similar to the C-style loop,
which unwillingly imports imperative style programming into OpenSCAD. The
only difference: Those defective objects currently tend to destabilize the
system. See it as a bug or a feature, there has to be found a solution, how
to treat that door. One can close it with just a bunch of extra checks. Or
one can open it, and will change the language - to the positive I admit -
but at what price, and of what gain. It will be a lot, a lot, of work, to
implement that seamlessly. Will people start printing dots and lines then?
Or write their own slicers or even draw cartoons?
Let me remind you that this would mean for instance to release 2D shapes
into 3D, which I proposed some time ago in another thread. I remember the
restrained reaction.
The interface between 2D and 3D for now is linear_extrude(),
rotate_extrude(), and projection(). Did I forget something? Polygon and
Polyhedron are constructors interfacing between vectors of points and
solids. A polygon is always closed into 2D. A polyhedron may be ... anything
(see below). That's it.
Boolean operations as well as hull and minkowski() are defined for both
worlds, but currently not meant to process a mixture of both types of
operands.
Others will know better than me, how the extra dimensions will/can fit into
OpenSCAD2.
We are talking about backdoors. There seems a much more stable, built-in
constructor for all this things - which obviously refuses to work with
minkowski, but hull() seems to be its friend.
@Marius: While this crashes OpenSCAD
minkowski(){ cube(); polyhedron([[0, 0, 12]], [[0]]); cube(); }
hull() does all you want. Here is your drop:
hull(){ polyhedron(points = [[0, 0, 12]], faces = [[0]]); sphere(5); }
here a double drop
hull(){ polyhedron(points = [[0, 0, 12], [0, 0, -12]], faces = [[0, 1]]);
sphere(5); }
and here is your world:
hull(){ polygon3D(10*[[0, 0, 1], [1, 0, 0], [0, 1, 0], [0, 0, 0]]); }
module point(p) polyhedron(points = [p], faces = [[0]]);
module line(p1, p2) polyhedron(points = [p1, p2], faces = [[0], [1]]);
module face(p1, p2, p3) polyhedron(points = [p1, p2, p3], faces = [[0],
[1], [2]]);
module polygon3D(P) polyhedron(points = P, faces = [for(i=[0:len(P)-1])
[i]]);
can also do it with points,
hull() { point([0, 0, 10]); point([10, 0, 0]); point([0, 10, 0]);
point([0, 0, 0]); }
or with lines
hull() { line([0, 0, 10], [10, 0, 0]); line([0, 10, 0], [0, 0, 0]); }
and this is your triple drop, e.g. by use of face()
hull() { face([0, 0, 10], [10, 0, 0], [0, 10, 0]); sphere(4, $fn=100);
}
http://forum.openscad.org/file/n17760/tirple.png
To sum it up: To be able to hull a couple of points into a (convex) solid,
is very charming, and extremly useful for design.
Rudolf
--
View this message in context: http://forum.openscad.org/Unusual-hull-and-minkowski-modelling-tp17730p17760.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
doug.moen wrote
This stuff is really cool, Ronaldo.
I was familiar with the morph() operation from other CSG systems, but I
just assumed it was impossible in OpenSCAD. So I'm impressed. I notice it
only works correctly if scale(0) returns a 0D point (as opposed to
returning nothing).
Although mophing operator is appealing, singularities may be raised by it
independent on how it is defined. Imagine what happens when morphing a solid
with disjoint parts with another one with just one part. Or morphing a torus
and a sphere. For some value of t, the morphing will be a non-manifold.
--
View this message in context: http://forum.openscad.org/Unusual-hull-and-minkowski-modelling-tp17730p17761.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Jun 18, 2016, at 10:23 AM, Parkinbot rudolf@parkinbot.com wrote:
@Marius
aren't you always looking for some compact crasher code? I never encountered
a higher crash rate before writing this post ;-)
Thx - I’ve created an issue: https://github.com/openscad/openscad/issues/1671
FYI: The problem is that we perform minkowski calculations as pairwise hulls, and CGAL’s hull algorithm doesn’t allow for results without a volume.
CGAL’s built-in minkowski algorithm has a similar problem and won’t create the resulting object, but it’s unknown why. If someone wants to dig, it might make sense to submit an issue on the latter to CGAL.
-Marius
Ronaldo wrote: "Although mophing operator is appealing, singularities may
be raised by it
independent on how it is defined. Imagine what happens when morphing a solid
with disjoint parts with another one with just one part. Or morphing a torus
and a sphere. For some value of t, the morphing will be a non-manifold."
Sure morphing will produce singularities, but so will minkowski(),
difference() and union(). So morphing is nothing special.
A basic challenge with implementing CSG using a mesh representation is that
CSG operations are not closed over 2-manifold meshes. Even if the inputs
are 2-manifold, the outputs might not be, because singularities can be
introduced. The best way to handle with this is to make all of the CSG
operations tolerant of singularities. Our current implementation is
tolerant of singularities in a lot of common cases, and this has improved
over time.
On 19 June 2016 at 08:34, Ronaldo rcmpersiano@gmail.com wrote:
doug.moen wrote
This stuff is really cool, Ronaldo.
I was familiar with the morph() operation from other CSG systems, but I
just assumed it was impossible in OpenSCAD. So I'm impressed. I notice it
only works correctly if scale(0) returns a 0D point (as opposed to
returning nothing).
Although mophing operator is appealing, singularities may be raised by it
independent on how it is defined. Imagine what happens when morphing a
solid
with disjoint parts with another one with just one part. Or morphing a
torus
and a sphere. For some value of t, the morphing will be a non-manifold.
--
View this message in context:
http://forum.openscad.org/Unusual-hull-and-minkowski-modelling-tp17730p17761.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
Sure morphing will produce singularities, but so will minkowski(),
difference() and union(). So morphing is nothing special.
A basic challenge with implementing CSG using a mesh representation is
that
CSG operations are not closed over 2-manifold meshes. Even if the inputs
are 2-manifold, the outputs might not be, because singularities can be
introduced.
Correctly implemented minkowski should not have any problem with it as it is
the most general operation to all of this. But being the most general
operation it is a much too large piece of artillery to tackle this task. To
do things like that, there are several by far more efficient approaches
(e.g. mesh mapping), addressing vertex reduction, topological aspects, and
singularities more explictly.
--
View this message in context: http://forum.openscad.org/Unusual-hull-and-minkowski-modelling-tp17730p17768.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Parkinbot wrote
To do things like that, there are several by far more efficient approaches
(e.g. mesh mapping), addressing vertex reduction, topological aspects, and
singularities more explictly.
Would you mind to deepen this?
--
View this message in context: http://forum.openscad.org/Unusual-hull-and-minkowski-modelling-tp17730p17769.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
As some entry point to the state of the art in this discipline have a look
here: https://graphics.tudelft.nl/Publications-new/2016/BVH16/BVH16.pdf
Ronaldo wrote
Would you mind to deepen this?
--
View this message in context: http://forum.openscad.org/Unusual-hull-and-minkowski-modelling-tp17730p17773.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Just before anyone gets too excited about zero-thickness shapes:
if you preview the truncated pyramid
$fn=4;
scale([1,1,0]) cylinder(r1=10, r2=3);
with both Thrown Together and Show Axes activated, you'll see that the
pyramid still has all its 8 corners, 12 edges and 12 triagonal faces. And if
you built its STL, you'll see that its thickness is very small, but not
zero.
On the positive side, when the trick is used to render Parkinbot's Helicoil,
rendering time is only 40% of what it is without the trick.
wolf
--
View this message in context: http://forum.openscad.org/Unusual-hull-and-minkowski-modelling-tp17730p17780.html
Sent from the OpenSCAD mailing list archive at Nabble.com.