Unusual hull() and minkowski modelling

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Unusual hull() and minkowski modelling

Ronaldo
I have found from a discussion in another thread a whole new set of possibilities of modelling with hull() and minkowski(). I will present here some of them.

To start consider the following module definitions:
module square3(a,b) scale([a,b,0]) cube(1,center=true);
module circle3(r=1) scale([1,1,0]) cylinder(r=r);
module point3(p)    translate(p)   scale(0) cube();
Essentially, the first and second are a cube and a cylinder smashed onto the xy plane, and the third a  cube shrinked to the origin. They don't have volume and the last one does not have even an area. They are 2D and 0D "shapes" but they are 3D objects in some sense (the reason I added a 3 in their names).

If you try to preview any of them you will see nothing. But they are not empty sets. For instance, you can hull() the point3() with a sphere and get a drop like model:
hull() { sphere(5); point3([0,0,12]); }
or start the model of a T-joint:
hull() { translate([0,-10,0]) rotate([90,0,0]) circle3(5,10); cylinder(r=5,h=20,center=true); }
It is possible to do intersections of those shapes with real 3D forms before the hull:
hull() {
    intersection(){ cube(20); circle3(7); }
    translate([0,0,20]) sphere(10);}
Or even make the hull() of just those strange forms to make a cone:
 
translate([0,-20,0]) hull() { circle3(5); point3([0,0,10]); }
Let us add one 1D object to the arsenal:
module segment3(p,p0=[0,0,0]) {
    q = p-p0;
    l = norm(q);
    b = acos(q[2]/l);
    c = atan2(q[1],q[0]);
    translate(p0)
        rotate([0, b, c])
            scale([0,0,l])
                cube(1);
}
Now the cube is smashed to an edge then rotate and scaled in such a way to bring the edge (a line segment) to lay between the points p and p0. Again you can't see any preview of segment3(). But it appears when you do the hull of a set of them:
module tetrahedron(h){
    hull() {
        segment3([0,0,h]); // a segment from [0,0,h] to [0,0,0]
        segment3([h,0,0]);
        segment3([0,h,0]);  
    }
}
Now minkowski. This operator is more restricted. To do a minkowski you need at least one real 3D object. So when I tried change the hull() in the tetrahedron() to a minkowski I got a system crash. In other trials, I got one CGAL error message or nothing at all.

But there is a lot of interesting thing to do with the operator. For instance, a solid linear extrusion:
module solid_linear_extrude(h=1){
    minkowski(){
        children();
        segment3([0,0,h]);
    }
}
solid_linear_extrude(20) difference(){ sphere(10); cylinder(r=5, h=30,center=true); }
This code took a longer time to preview but it worked. It is easy and faster do it with hull().

But hull() does not solve the sweep operation. Minkowski does with the module:
module sweep_solid(line) {
    for(i=[0:len(line)-2])
        minkowski(){
            children();
            segment3(line[i],line[i+1]);
        }
}
We cannot sweep a 2D shape with sweep_solid() but it is possible to sweep a sphere(), a cube or, if you have plenty of time, any 3D model. Note that this is a translational sweep.

Finally, an interesting approach to morphing using minkowski:
module morphing(t) {
    minkowski() {
        scale((1-t)) children(0);
        scale(t) children(1);
    }
}
that is applied here to a sphere and a cylinder in an animation:
morphing(1/2-cos(360*$t)/2) { A(); B(); }
module A() rotate([90,0,0]) cylinder(r=3,h=15,center=true);
module B() translate([20,0,0]) sphere(5);
For any given 0<t<1,  morphing(t) is a blend of the two children.
Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

Parkinbot
Ronaldo,

there are people shuffling eggs with wheel loaders ... ;-)
Others find themselves using Mathematica sooner or later.

For a Mathematician it can be fun to study this degenerate stuff, and it can indeed discover some crash scenarios in OpenSCAD.
But to be honest, I don't see any practical use in working with pathological constructs, beyond curiosity. Implementation will change over time, and any of this code might be broken sooner or later.

Again, F5 uses your graphics system for rendering. OpenSCAD 'calculates' its stuff by feeding proper representations into subsystems, which are supposed to do the dirty work. It might be enough to install a new OpenGL driver to change CSG view results. And finally CGAL's Nef polyhedra implementation might have its own 'opinion' about these things and also change it some day.

As I understand it, OpenSCAD currently bypasses CGAL for 2D shapes and does some own (fast) calculations on them. So, there are at least three worlds - and representations - involved ...

I would always decide (and advise) to use a more common or 'straight' solution instead of 'peek and poke' for *robustness* and execution time. Instead of
hull() { sphere(5); point3([0,0,12]);
I'd always apply 'Occam's razor' and simply write:
hull() { sphere(5); cylinder(12, 0.1, 0); }
And everybody (including myself even after a year) will be able to read it.

What do you think, will be gained? More language expressiblity?
Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

Ronaldo
Rudolf,

I usually like your approach, your way of thinking, and certainly the experience you bring to the discussions. For me, it is like a counterpoint to mine ways. And I like diversity.

I agree that the ideas I expressed will have a short live. May be in the next version. My intention however was to show the gain in expressiveness when you mix 3D objects with lower dimension ones. I can't see anything clearer then express a sweep as a minkowski of a solid with a curve or polyline. And it would be a gain to express the sweep as such. I am not saying that it should be done that way now because minkowski is lot expensive yet. May be in the future.

I disagree however that your 'Occam's razor' solution to the drop code is clearer then mine. I agree that the definition point3() is polemics due to its use of degenerescence but the drop code is clearer then using a almost degenerated cylinder. The ideal would be to have primitives point(), edge(), polygon(), etc that were mixable with 3D solids in a proper way. In that case, who would code a drop like yours?

Observe that minkowski is processed by CGAL and the library accepts and process correctly the mix of 3D with lower dimension figures. There is no real complexities or break in robustness in those mixing. Neither theoretically nor in the algorithms. What is missing is a way to express this without to resort to degenerated codes.

Ronaldo
Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

nophead
Is 3D Minkowski still processed with CGAL? I think there was some work to bypass CGAL for hull and minkowski to speed them up in the convex case, which is simple and in the concave case I think it now does a convex decomposition and unions the results. The union will be done in CGAL and hence slow. Not sure as my memory is failing.

On 17 June 2016 at 18:18, Ronaldo <[hidden email]> wrote:
Rudolf,

I usually like your approach, your way of thinking, and certainly the
experience you bring to the discussions. For me, it is like a counterpoint
to mine ways. And I like diversity.

I agree that the ideas I expressed will have a short live. May be in the
next version. My intention however was to show the gain in expressiveness
when you mix 3D objects with lower dimension ones. I can't see anything
clearer then express a sweep as a minkowski of a solid with a curve or
polyline. And it would be a gain to express the sweep as such. I am not
saying that it should be done that way now because minkowski is lot
expensive yet. May be in the future.

I disagree however that your 'Occam's razor' solution to the drop code is
clearer then mine. I agree that the definition point3() is polemics due to
its use of degenerescence but the drop code is clearer then using a almost
degenerated cylinder. The ideal would be to have primitives point(), edge(),
polygon(), etc that were mixable with 3D solids in a proper way. In that
case, who would code a drop like yours?

Observe that minkowski is processed by CGAL and the library accepts and
process correctly the mix of 3D with lower dimension figures. There is no
real complexities or break in robustness in those mixing. Neither
theoretically nor in the algorithms. What is missing is a way to express
this without to resort to degenerated codes.

Ronaldo



--
View this message in context: http://forum.openscad.org/Unusual-hull-and-minkowski-modelling-tp17730p17747.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

kintel
Administrator
> On Jun 17, 2016, at 13:29 PM, nop head <[hidden email]> wrote:
>
> Is 3D Minkowski still processed with CGAL? I think there was some work to bypass CGAL for hull and minkowski to speed them up in the convex case, which is simple and in the concave case I think it now does a convex decomposition and unions the results. The union will be done in CGAL and hence slow. Not sure as my memory is failing.
>
We try to process 3D minkowski using convex hulls and convex decomposition. The hulls themselves are processed using CGAL (although not using Nef polyhedrons, it’s pretty performant). This is an optimization that ideally should already be done within CGAL.
Yes, unions are still slow.

 -Marius



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

Parkinbot
In reply to this post by Ronaldo
It's also allowed to code the drop without the typo! Sorry, about that.
hull() { sphere(5); cylinder(12, 5, 0); }
I agree, that it would be nice to have a mixed 0D, 1D, 2D, 3D world instead of only 2D and 3D - which already comes along with a lot of crudities. But this needs a well thought out approach and would be a step of very high impact, also with respect to backward compatibility and general language design. It needs all constructors, all operators, actually the whole language revised. Possible, but who will work it out, who will implement it. Maybe there are reasons, why it wasn't been done. One of it definitely might have been simplicty.

But I perfectly well understand your point. No doubt, it has charming side:

You feed a hull with a couple of points, lines, 2D shapes and get a convex 3D shape hulling all of them.
You feed a minkowski with two polygons - a nonclosed one and closed one - or a polygon and a 2D shape and get a sweep.
You feed an intersection with a 2D shape living in 3D and get a projection
and so on.

This might gain something, especially the sweep, but I doubt, we will ever see it this way. Personally I would be happy with much less (get hands on the f***g points and faces of an OpenSCAD shape, be it only 2D, or minimum of imported STL and DXF), because I doubt, Minkowski will ever be fast enough for somebody, who knows what he is doing.

Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

doug.moen
In reply to this post by Ronaldo
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).

On 16 June 2016 at 23:54, Ronaldo <[hidden email]> wrote:
I have found from a discussion in another thread a whole new set of
possibilities of modelling with hull() and minkowski(). I will present here
some of them.

To start consider the following module definitions:

> module square3(a,b) scale([a,b,0]) cube(1,center=true);
> module circle3(r=1) scale([1,1,0]) cylinder(r=r);
> module point3(p)    translate(p)   scale(0) cube();

Essentially, the first and second are a cube and a cylinder smashed onto the
xy plane, and the third a  cube shrinked to the origin. They don't have
volume and the last one does not have even an area. They are 2D and 0D
"shapes" but they are 3D objects in some sense (the reason I added a 3 in
their names).

If you try to preview any of them you will see nothing. But they are not
empty sets. For instance, you can hull() the point3() with a sphere and get
a drop like model:

> hull() { sphere(5); point3([0,0,12]); }

or start the model of a T-joint:

> hull() { translate([0,-10,0]) rotate([90,0,0]) circle3(5,10);
> cylinder(r=5,h=20,center=true); }

It is possible to do intersections of those shapes with real 3D forms before
the hull:

> hull() {
>     intersection(){ cube(20); circle3(7); }
>     translate([0,0,20]) sphere(10);}

Or even make the hull() of just those strange forms to make a cone:

> translate([0,-20,0]) hull() { circle3(5); point3([0,0,10]); }

Let us add one 1D object to the arsenal:

> module segment3(p,p0=[0,0,0]) {
>     q = p-p0;
>     l = norm(q);
>     b = acos(q[2]/l);
>     c = atan2(q[1],q[0]);
>     translate(p0)
>         rotate([0, b, c])
>             scale([0,0,l])
>                 cube(1);
> }

Now the cube is smashed to an edge then rotate and scaled in such a way to
bring the edge (a line segment) to lay between the points p and p0. Again
you can't see any preview of segment3(). But it appears when you do the hull
of a set of them:

> module tetrahedron(h){
>     hull() {
>         segment3([0,0,h]); // a segment from [0,0,h] to [0,0,0]
>         segment3([h,0,0]);
>         segment3([0,h,0]);
>     }
> }

Now minkowski. This operator is more restricted. To do a minkowski you need
at least one real 3D object. So when I tried change the hull() in the
tetrahedron() to a minkowski I got a system crash. In other trials, I got
one CGAL error message or nothing at all.

But there is a lot of interesting thing to do with the operator. For
instance, a solid linear extrusion:

> module solid_linear_extrude(h=1){
>     minkowski(){
>         children();
>         segment3([0,0,h]);
>     }
> }
> solid_linear_extrude(20) difference(){ sphere(10); cylinder(r=5,
> h=30,center=true); }

This code took a longer time to preview but it worked. It is easy and faster
do it with hull().

But hull() does not solve the sweep operation. Minkowski does with the
module:

> module sweep_solid(line) {
>     for(i=[0:len(line)-2])
>         minkowski(){
>             children();
>             segment3(line[i],line[i+1]);
>         }
> }

We cannot sweep a 2D shape with sweep_solid() but it is possible to sweep a
sphere(), a cube or, if you have plenty of time, any 3D model. Note that
this is a translational sweep.

Finally, an interesting approach to morphing using minkowski:

> module morphing(t) {
>     minkowski() {
>         scale((1-t)) children(0);
>         scale(t) children(1);
>     }
> }

that is applied here to a sphere and a cylinder in an animation:

> morphing(1/2-cos(360*$t)/2) { A(); B(); }
> module A() rotate([90,0,0]) cylinder(r=3,h=15,center=true);
> module B() translate([20,0,0]) sphere(5);

For any given 0<t<1,  morphing(t) is a blend of the two children.



--
View this message in context: http://forum.openscad.org/Unusual-hull-and-minkowski-modelling-tp17730.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

doug.moen
In reply to this post by Ronaldo
There are some open issues requesting point, line segment and path objects in the 2D plane, for the purpose of DXF export for laser cutting. Eg, https://github.com/openscad/openscad/issues/508

I don't consider laser cutting a good enough reason by itself to add these features. However, if these features are important for supporting solid sweep, morph, and other modelling operations, then it looks more worthwhile, and laser cutter support is just an added bonus.

Proper support for these kinds of objects would obviously include being able to see them in preview, and having well defined semantics when used with all geometric operations (eg, CGAL doesn't crash).

In the 2D subsystem, a reasonable set of degenerate shape constructors might be
* point([x,y])
* path([[x1,y1], [x2,y2], ...], open=true)
* boundary() 2dShape

A path is a connected series of line segments. An open path has a start and end point, while a closed path is a loop where the start and end are connected. So, you can sweep along a path. The boundary() operation converts a proper 2D shape into the closed path representing its perimeter.

In 3D, we'd have the same primitives, plus a mesh primitive for constructing a surface, with the same arguments as polyhedron, but the mesh wouldn't have to be manifold. The boundary() operation on a 3D object would also return a surface. 

Plus, of course, we add some special rules, eg so that scale(0) shape returns a point.


On 16 June 2016 at 23:54, Ronaldo <[hidden email]> wrote:
I have found from a discussion in another thread a whole new set of
possibilities of modelling with hull() and minkowski(). I will present here
some of them.

To start consider the following module definitions:

> module square3(a,b) scale([a,b,0]) cube(1,center=true);
> module circle3(r=1) scale([1,1,0]) cylinder(r=r);
> module point3(p)    translate(p)   scale(0) cube();

Essentially, the first and second are a cube and a cylinder smashed onto the
xy plane, and the third a  cube shrinked to the origin. They don't have
volume and the last one does not have even an area. They are 2D and 0D
"shapes" but they are 3D objects in some sense (the reason I added a 3 in
their names).

If you try to preview any of them you will see nothing. But they are not
empty sets. For instance, you can hull() the point3() with a sphere and get
a drop like model:

> hull() { sphere(5); point3([0,0,12]); }

or start the model of a T-joint:

> hull() { translate([0,-10,0]) rotate([90,0,0]) circle3(5,10);
> cylinder(r=5,h=20,center=true); }

It is possible to do intersections of those shapes with real 3D forms before
the hull:

> hull() {
>     intersection(){ cube(20); circle3(7); }
>     translate([0,0,20]) sphere(10);}

Or even make the hull() of just those strange forms to make a cone:

> translate([0,-20,0]) hull() { circle3(5); point3([0,0,10]); }

Let us add one 1D object to the arsenal:

> module segment3(p,p0=[0,0,0]) {
>     q = p-p0;
>     l = norm(q);
>     b = acos(q[2]/l);
>     c = atan2(q[1],q[0]);
>     translate(p0)
>         rotate([0, b, c])
>             scale([0,0,l])
>                 cube(1);
> }

Now the cube is smashed to an edge then rotate and scaled in such a way to
bring the edge (a line segment) to lay between the points p and p0. Again
you can't see any preview of segment3(). But it appears when you do the hull
of a set of them:

> module tetrahedron(h){
>     hull() {
>         segment3([0,0,h]); // a segment from [0,0,h] to [0,0,0]
>         segment3([h,0,0]);
>         segment3([0,h,0]);
>     }
> }

Now minkowski. This operator is more restricted. To do a minkowski you need
at least one real 3D object. So when I tried change the hull() in the
tetrahedron() to a minkowski I got a system crash. In other trials, I got
one CGAL error message or nothing at all.

But there is a lot of interesting thing to do with the operator. For
instance, a solid linear extrusion:

> module solid_linear_extrude(h=1){
>     minkowski(){
>         children();
>         segment3([0,0,h]);
>     }
> }
> solid_linear_extrude(20) difference(){ sphere(10); cylinder(r=5,
> h=30,center=true); }

This code took a longer time to preview but it worked. It is easy and faster
do it with hull().

But hull() does not solve the sweep operation. Minkowski does with the
module:

> module sweep_solid(line) {
>     for(i=[0:len(line)-2])
>         minkowski(){
>             children();
>             segment3(line[i],line[i+1]);
>         }
> }

We cannot sweep a 2D shape with sweep_solid() but it is possible to sweep a
sphere(), a cube or, if you have plenty of time, any 3D model. Note that
this is a translational sweep.

Finally, an interesting approach to morphing using minkowski:

> module morphing(t) {
>     minkowski() {
>         scale((1-t)) children(0);
>         scale(t) children(1);
>     }
> }

that is applied here to a sphere and a cylinder in an animation:

> morphing(1/2-cos(360*$t)/2) { A(); B(); }
> module A() rotate([90,0,0]) cylinder(r=3,h=15,center=true);
> module B() translate([20,0,0]) sphere(5);

For any given 0<t<1,  morphing(t) is a blend of the two children.



--
View this message in context: http://forum.openscad.org/Unusual-hull-and-minkowski-modelling-tp17730.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

Parkinbot
In reply to this post by Parkinbot
Ronaldo,

Parkinbot wrote
You feed a minkowski with two polygons - a nonclosed one and closed one - or a polygon and a 2D shape and get a sweep.
...
because I doubt, Minkowski will ever be fast enough for somebody, who knows what he is doing.
here is your Minkowski-tweaked sweep() using a path and a 3D shape, which I called extrude() - also allowing for self-intersection. It is a 'weak' peek&poke solution, because hull() insists on some 'flesh' in the Z direction (crashes OpenSCAD otherwise). Also not all Z-trajectories seem to be 'allowed'.



p =   [for (x=[0:10:360]) 30*[cos(x), sin(2*x), x/100]];
p1 =   [for (x=[0:4:360]) 30*[cos(x), sin(4*x), -cos(x)]];

extrude(p) cylinder(3);
extrude(p1) sphere(3);

module extrude(p)  minkowski() {polygon2path(p); children();}

module polygon2path(p) for(i=[0:len(p)-2]) line(p[i], p[i+1]);
module line(a, b) hull(){ point(a); point(b);}  
module point(t) translate(t) scale([0, 0, 0.0001]) cube([]);
Of course, either polygon2path() could get a built-in operator (avoiding hull()), or minkowski() could be overloaded to directly accept and process a vec3D set.

BTW, this is an old solution of mine, the only difference, I used non-degenerate 'sufficiently small' shapes to hull the path into a solid then.

Anyway you put it, degenrate or not, I don't see much progress because the approach is expectedly very slow. Therefore I'd always opt for a dedicated extrude() operator that could internally use minkowski PLUS some shortcuts if boundingbox checks allow for them, to speed up things dramatically.

Concerning runtime, don't try the following one. Looks harmless, but I guess it takes hours to process, due to its convexity.

extrude(p) {sphere(3);translate([2,0,0]) sphere(3);}
I also guess a render() will speed it up a bit to several minutes, but to get the 'hires' shot (step=2) I preferred to use a convex decomposition, which tweaked it down to a minute.  
  extrude(p) sphere(3);
  translate([2,0,0])
  extrude(p) sphere(3);

   Top level object is a 3D object:
   Simple:        yes
   Vertices:     3027
   Halfedges:   14294
   Edges:        7147
   Halffacets:   8244
   Facets:       4122
   Volumes:         2
Therefore, I really don't see much chance for the minkowski approach when implementing extrude().

@Marius
aren't you always looking for some compact crasher code? I never encountered a higher crash rate before writing this post ;-)




Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

Ronaldo
Rudolf,

We have two different tricks to do the same thing. In mine, I hack the system to generate a path that is not provided by the language. In yours, a very thin polyhedron takes the place of my hack. I agree that my hack has a short live and your trick should be valid in the future, but that is the only advantage of it.

I have compared the running time of my sweep with yours. The preview of your paths with my sweep took less than a second and the render spent 4min. I gave up to preview that paths with your sweep in my old machine so I shortened the paths. With a 16 segment path, the preview of your sweep took more than 6min. On the other hand, the double sphere sweep with my hack took 13min to preview. I didn't try render any of them.

So, your robust trick is a lot slower than doing the right thing: minkowski the solid with a real line. The reasons are clear to me. The path simulated by thin polyhedron is a non-convex polyhedron with a lot of vertices. Even if you do a convex decomposition of the solid to be swept, the path remains non convex and it will require a lot of effort to be decomposed and processed. If you have a real polyline, its convex decomposition is trivial. So, the main effort will be the convex decomposition of the solid and the union of the extrusions.

I insist that the main point is not the particular hack I devised but the simplicity and efficiency of mixing 3D objects with lower dimension ones in some cases. I see no additional complexity in mixing different dimensions in OpenSCAD. It is enough not to send lower dimension shapes to CGAL and ignore them in STL generation. The lower dimension objects would be used only for display purposes and as input of some operations. Observe that the object circle3() I defined above is able to be boolean operated with real 3D solids. They seems to be witchcraft but they are real!

I miss lower dimension primitives like segment() in OpenSCAD from my first experience with the system. So I created my own library to draw them in a similar way you did. I use them a lot to display lines and facets during model building debugging. But I cannot render them because the time CGAL requires to union them is
unaffordable.
Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

Parkinbot
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); }


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
Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

Ronaldo
In reply to this post by doug.moen
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.
Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

kintel
Administrator
In reply to this post by Parkinbot
On Jun 18, 2016, at 10:23 AM, Parkinbot <[hidden email]> 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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

doug.moen
In reply to this post by Ronaldo
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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

Parkinbot
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.

Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

Ronaldo
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?
Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

Parkinbot
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?
Reply | Threaded
Open this post in threaded view
|

Re: Unusual hull() and minkowski modelling

wolf
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