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: 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: or start the model of a Tjoint: It is possible to do intersections of those shapes with real 3D forms before the hull: Or even make the hull() of just those strange forms to make a cone: Let us add one 1D object to the arsenal: 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: 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: 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: 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: that is applied here to a sphere and a cylinder in an animation: For any given 0<t<1, morphing(t) is a blend of the two children. 
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 I'd always apply 'Occam's razor' and simply write: And everybody (including myself even after a year) will be able to read it. What do you think, will be gained? More language expressiblity? 
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 
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, _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
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 
In reply to this post by Ronaldo
It's also allowed to code the drop without the typo! Sorry, about that.
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. 
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 _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
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 _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by Parkinbot
Ronaldo,
here is your Minkowskitweaked sweep() using a path and a 3D shape, which I called extrude()  also allowing for selfintersection. It is a 'weak' peek&poke solution, because hull() insists on some 'flesh' in the Z direction (crashes OpenSCAD otherwise). Also not all Ztrajectories seem to be 'allowed'. Of course, either polygon2path() could get a builtin 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 nondegenerate '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. 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. 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 ;) 
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 nonconvex 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. 
Ronaldo
As a programmer, I wouldn't call all that a 'trick'. It's a fullgrown backdoor, and in its implication it is quite similar to the Cstyle 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, builtin constructor for all this things  which obviously refuses to work with minkowski, but hull() seems to be its friend. @Marius: While this crashes OpenSCAD hull() does all you want. Here is your drop: here a double drop and here is your world: can also do it with points, or with lines and this is your triple drop, e.g. by use of face()
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 
In reply to this post by doug.moen
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 nonmanifold. 
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 builtin 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 
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 nonmanifold." 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 2manifold meshes. Even if the inputs are 2manifold, 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 _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
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. 
Would you mind to deepen this? 
As some entry point to the state of the art in this discipline have a look here: https://graphics.tudelft.nl/Publicationsnew/2016/BVH16/BVH16.pdf

Just before anyone gets too excited about zerothickness 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 
Free forum by Nabble  Edit this page 