discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Can you sweep a object with fingers

JJ
Johan Jonker
Sat, Nov 12, 2016 5:03 PM

Johan_s_examples.scad
http://forum.openscad.org/file/n19057/Johan_s_examples.scad

I have an object with seperate fingers. What I do is to sweep the fingers
separately and then join them with the base of the object. I wonder if it is
possible to sweep them in one.
In the example below it works a little but there is a connection between the
two fingers

<row> use <naca4.scad> use <naca_sweep.scad>

sweep (gen_double_cylinder());

function gen_double_cylinder() =
[ for (h=[1,2,3])
for (height = (h==1)? [0:1:10]:
(h==2)? [15:5:200]:
[201:1:210])
let (R = 10*(210-height/2)/210)
let (BB = (height<10)?  sqrt(R*R-abs(R-height)abs(R-height)):
(height>200)? sqrt(R
R-abs(200-height)abs(200-height)):
R)
let (N  = round(60-R+BB))
let (LM  = (height<100)? R: (height<150)? R
(50-(height-100))/50:0)
let (cyl =  vec3D(doublecircle(BB,LM,60)))
T_(0,0,height,cyl)];

function doublecircle(R,LM,N) =
[ for (w = [0:round(360/N):719])
let (RR=10)
let (wlm = asin(LM/10))
(w<wlm)? [Rcos(wlm),Rsin(wlm)]:
(w<90)? [Rcos(w),Rsin(w)]:
(w<180)? [Rcos(w),Rsin(w)]:
(w<270)? [Rcos(w),Rsin(w)]:
(w<360-wlm)? [Rcos(w),Rsin(w)]:
(w<360+wlm)? [Rcos(wlm),-Rsin(wlm)]:
(w<450)?  [2RR-Rcos(w),-Rsin(w)]:
(w<540)? [2
RR-Rcos(w),-Rsin(w)]:
(w<630)? [2RR-Rcos(w),-Rsin(w)]:
(w<720-wlm)?    [2
RR-Rcos(w),-Rsin(w)]:
[2RR-cos(wlm),+Rsin(wlm)]

];
</row>

--
View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Johan_s_examples.scad <http://forum.openscad.org/file/n19057/Johan_s_examples.scad> I have an object with seperate fingers. What I do is to sweep the fingers separately and then join them with the base of the object. I wonder if it is possible to sweep them in one. In the example below it works a little but there is a connection between the two fingers <row> use <naca4.scad> use <naca_sweep.scad> sweep (gen_double_cylinder()); function gen_double_cylinder() = [ for (h=[1,2,3]) for (height = (h==1)? [0:1:10]: (h==2)? [15:5:200]: [201:1:210]) let (R = 10*(210-height/2)/210) let (BB = (height<10)? sqrt(R*R-abs(R-height)*abs(R-height)): (height>200)? sqrt(R*R-abs(200-height)*abs(200-height)): R) let (N = round(60-R+BB)) let (LM = (height<100)? R: (height<150)? R*(50-(height-100))/50:0) let (cyl = vec3D(doublecircle(BB,LM,60))) T_(0,0,height,cyl)]; function doublecircle(R,LM,N) = [ for (w = [0:round(360/N):719]) let (RR=10) let (wlm = asin(LM/10)) (w<wlm)? [R*cos(wlm),R*sin(wlm)]: (w&lt;90)? [R*cos(w),R*sin(w)]: (w&lt;180)? [R*cos(w),R*sin(w)]: (w&lt;270)? [R*cos(w),R*sin(w)]: (w&lt;360-wlm)? [R*cos(w),R*sin(w)]: (w&lt;360+wlm)? [R*cos(wlm),-R*sin(wlm)]: (w&lt;450)? [2*RR-R*cos(w),-R*sin(w)]: (w&lt;540)? [2*RR-R*cos(w),-R*sin(w)]: (w&lt;630)? [2*RR-R*cos(w),-R*sin(w)]: (w&lt;720-wlm)? [2*RR-R*cos(w),-R*sin(w)]: [2*RR-cos(wlm),+R*sin(wlm)] ]; &lt;/row> -- View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057.html Sent from the OpenSCAD mailing list archive at Nabble.com.
P
Parkinbot
Sat, Nov 12, 2016 11:26 PM

This isn't specified. Sweep operates over a series of simple polygons. It
could be specified to also work with vector of a series of polygons (each
being a vector of vectors itself) or a series of a vector of polygons, but I
don't see much use for this.
But it is easy to achieve by writing your own wrapper function that will
decompose such a combined data structure, call sweep() for each component,
and union the result.
If OpenSCAD had data structures such a packing would be more explicit, but
operating with vectors of vectors of vectors of vectors data is prone to
misinterpretation, besides all the multiple self-intersection perils.
To keep track of such monster structures, it might be a good idea to
introduce some explicit typing scheme with OpenScad, otherwise you easily
get lost, when tracking errors. At least in the case you mention, it might
make a lot of sense. Here an example, how the constructors could look:

function point_xyz(x, y, z) = ["point3", [x, y, z]];
function point_v3(v3) = ["point3", [v[0], v[1], v[2]]];  // better
explicit instead of just v3
function polygon(P) = ["polygon3", P];                        // might
also do an isSimple()-test

With this, the next step is to define type aware affine operations for this
objects. Not a big deal, but an approach that is somehow idiosyncratic.

--
View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057p19062.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

This isn't specified. Sweep operates over a series of simple polygons. It could be specified to also work with vector of a series of polygons (each being a vector of vectors itself) or a series of a vector of polygons, but I don't see much use for this. But it is easy to achieve by writing your own wrapper function that will decompose such a combined data structure, call sweep() for each component, and union the result. If OpenSCAD had data structures such a packing would be more explicit, but operating with vectors of vectors of vectors of vectors data is prone to misinterpretation, besides all the multiple self-intersection perils. To keep track of such monster structures, it might be a good idea to introduce some explicit typing scheme with OpenScad, otherwise you easily get lost, when tracking errors. At least in the case you mention, it might make a lot of sense. Here an example, how the constructors could look: > function point_xyz(x, y, z) = ["point3", [x, y, z]]; > function point_v3(v3) = ["point3", [v[0], v[1], v[2]]]; // better > explicit instead of just v3 > function polygon(P) = ["polygon3", P]; // might > also do an isSimple()-test With this, the next step is to define type aware affine operations for this objects. Not a big deal, but an approach that is somehow idiosyncratic. -- View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057p19062.html Sent from the OpenSCAD mailing list archive at Nabble.com.
RP
Ronaldo Persiano
Sun, Nov 13, 2016 7:51 PM

I1ve been trying a different approach, namely to generate polyhedron data
by functions. This means to separate the data generation from the
polyhedron call. In sweeping, for example, all computations of vertices and
faces are done by a function that generates a pair of vertices,faces. A
very simple module show_data()  receives this pair and pass the parameters
to the polyhedron primitive.

This approach has shown to be versatile. I recently wrote a code to build
triangular Bezier patches. To preview the patch surface I just wrote a
function to generate the polyhedron data for a triangular patch, a specific
and simple code, and send the data to the same module show_data. Another
function converts simple polygons to polyhedron data. And another converts
meshes (bi-dimensional matrix of points) to polyhedron data. Finally I have
extended the show_data module to receive a list of polyhedron data,
consolidate all of them in one polyhedron data to feed the polyhedron call
once.

This approach might be used to deal with fingers. Generate the polyhedron
data of each finger individually and send everything to show_data() or any
specific and simple substitute.

I1ve been trying a different approach, namely to generate polyhedron data by functions. This means to separate the data generation from the polyhedron call. In sweeping, for example, all computations of vertices and faces are done by a function that generates a pair of vertices,faces. A very simple module show_data() receives this pair and pass the parameters to the polyhedron primitive. This approach has shown to be versatile. I recently wrote a code to build triangular Bezier patches. To preview the patch surface I just wrote a function to generate the polyhedron data for a triangular patch, a specific and simple code, and send the data to the same module show_data. Another function converts simple polygons to polyhedron data. And another converts meshes (bi-dimensional matrix of points) to polyhedron data. Finally I have extended the show_data module to receive a list of polyhedron data, consolidate all of them in one polyhedron data to feed the polyhedron call once. This approach might be used to deal with fingers. Generate the polyhedron data of each finger individually and send everything to show_data() or any specific and simple substitute.
JJ
Johan Jonker
Sun, Nov 13, 2016 10:20 PM

http://forum.openscad.org/file/n19083/Naamloos.jpg
The picture above shows the object that I want to make.
It is the right part of a saxophone key guard called the "engelsflugel"; a
part of a famous Keilwerth saxophone.

What I do is to make 5 objects the base of the wing and the four points of
the wing.
Each part has its owe data structure and sweep operation.

By the way. Is it possible to decrease the number of points in a the serie
of polygons in one sweep operation. For instance when near the point of the
object there are no so many points needed.

--
View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057p19083.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

<http://forum.openscad.org/file/n19083/Naamloos.jpg> The picture above shows the object that I want to make. It is the right part of a saxophone key guard called the "engelsflugel"; a part of a famous Keilwerth saxophone. What I do is to make 5 objects the base of the wing and the four points of the wing. Each part has its owe data structure and sweep operation. By the way. Is it possible to decrease the number of points in a the serie of polygons in one sweep operation. For instance when near the point of the object there are no so many points needed. -- View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057p19083.html Sent from the OpenSCAD mailing list archive at Nabble.com.
P
Parkinbot
Sun, Nov 13, 2016 10:22 PM

Ronaldo wrote

I1ve been trying a different approach, namely to generate polyhedron data
by functions. This means to separate the data generation from the
polyhedron call. In sweeping, for example, all computations of vertices
and
faces are done by a function that generates a pair of vertices,faces. A
very simple module show_data()  receives this pair and pass the parameters
to the polyhedron primitive.

This is exactly what the sweep() from Naca_sweep.scad Johan is referring
at does.
It is also the skin() approach.

--
View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057p19084.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Ronaldo wrote > I1ve been trying a different approach, namely to generate polyhedron data > by functions. This means to separate the data generation from the > polyhedron call. In sweeping, for example, all computations of vertices > and > faces are done by a function that generates a pair of vertices,faces. A > very simple module show_data() receives this pair and pass the parameters > to the polyhedron primitive. This is exactly what the *sweep()* from Naca_sweep.scad Johan is referring at does. It is also the *skin()* approach. -- View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057p19084.html Sent from the OpenSCAD mailing list archive at Nabble.com.
R
Ronaldo
Mon, Nov 14, 2016 7:34 PM

Rudolf,

I reread your code of sweep and I think I am going a step further. Your
module sweep receives polygonal sections, all of the same length, and builds
the polyhedron wrapping them including caps. It is a very specialized
module. In my approach, the preparation of the polyhedron data is done
externally to the module. To make it clear here is a possible code of the
module:

// Builds a polyhedron based on a list of polyhedron data
//    polys - a list of polyhedron data, that is polys[i] = [ vert_list,
face_lists ]

module make_polyhedron(polys, convexity = 10) {
vertlist = [for(p=polys, pt=p[0]) pt]; // collect all verts from
polyhedra
vertlen  = [for(p=polys) p[0] ];
acclen  = acc_len(vertlen);
facets  = [ for(i=[0:len(polys)-1], f=polys[i][1] ) [ for(v=f)
acclen[i]+v ] ];

 polyhedron(
     points = vertlist,
     faces  = facets,
     convexity = convexity
 );
 function _accum_sum(l, offs=0, res=[]) =
     len(res) == len(l) ?
         res :
         _accum_sum(l, offs+l[len(res)], concat(res, [ offs+l[len(res)]

] ));

 function acc_len( f ) = 
     concat([0], _accum_sum([ for(fi=f) len(fi) ]));

}

As you see, make_polyhedron is simpler than sweep and basically unifies
polyhedron data and send it to polyhedron primitive.

As part of this approach, each kind of object requires a specialized
function to generate polyhedron data for it. For instance,

// generates polyhedron data for a mesh
// a mesh is a rectangular matrix of 3D points
function mesh2polyhedron(mesh, inv=false) =
let( n = len(mesh) != 0 ? len(mesh) : 0,
m = n==0 ? 0 : len(mesh[0]) != 0 ? len(mesh[0]) : 0 ,
l = nm)
l > 0 ?
let( range    = inv ? [len(mesh)-1: -1: 0] : [0:len(mesh)-1],
vertices = l == 0 ? [] : [ for(i=range) for(pt=mesh[i]) pt ],
tris = concat(  [ for(i=[0:n-2],j=[0:m-2]) [ i
m+j, i*m+j+1,
(i+1)m+j ] ] ,
[ for(i=[0:n-2],j=[0:m-2]) [ i
m+j+1,
(i+1)*m+j+1, (i+1)*m+j ] ] ) )
[ vertices, tris ]:
[] ;

// generates polyhedron data for a closed polygonal face
function polygon2polyhedron(polygon, inv=false) =
let( vertices  = polygon,
range    = inv ? [len(polygon)-1: -1: 0] : [0:len(polygon)-1],
facets    = [[for(i=range) i ]] )
[ vertices, facets ];

Now, the application code just call the appropriate functions with pieces of
the polyhedron surface, concatenate all of them and send to make_polyhedron.

The flexibility of the approach is evident when a new kind of object (like a
Bezier triangular patch, or a sweep or loft) is created and just one
function is needed to be coded to include it in the system. If the cap of
sweep is optional, the main code may build a special cap made of Bezier
patches before sending all to make_polyhedron. And so, fingers are also
possible.

--
View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057p19097.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Rudolf, I reread your code of sweep and I think I am going a step further. Your module sweep receives polygonal sections, all of the same length, and builds the polyhedron wrapping them including caps. It is a very specialized module. In my approach, the preparation of the polyhedron data is done externally to the module. To make it clear here is a possible code of the module: > // Builds a polyhedron based on a list of polyhedron data > // polys - a list of polyhedron data, that is polys[i] = [ vert_list, > face_lists ] > > module make_polyhedron(polys, convexity = 10) { > vertlist = [for(p=polys, pt=p[0]) pt]; // collect all verts from > polyhedra > vertlen = [for(p=polys) p[0] ]; > acclen = acc_len(vertlen); > facets = [ for(i=[0:len(polys)-1], f=polys[i][1] ) [ for(v=f) > acclen[i]+v ] ]; > > polyhedron( > points = vertlist, > faces = facets, > convexity = convexity > ); > function _accum_sum(l, offs=0, res=[]) = > len(res) == len(l) ? > res : > _accum_sum(l, offs+l[len(res)], concat(res, [ offs+l[len(res)] > ] )); > > function acc_len( f ) = > concat([0], _accum_sum([ for(fi=f) len(fi) ])); > } As you see, make_polyhedron is simpler than sweep and basically unifies polyhedron data and send it to polyhedron primitive. As part of this approach, each kind of object requires a specialized function to generate polyhedron data for it. For instance, > // generates polyhedron data for a mesh > // a mesh is a rectangular matrix of 3D points > function mesh2polyhedron(mesh, inv=false) = > let( n = len(mesh) != 0 ? len(mesh) : 0, > m = n==0 ? 0 : len(mesh[0]) != 0 ? len(mesh[0]) : 0 , > l = n*m) > l > 0 ? > let( range = inv ? [len(mesh)-1: -1: 0] : [0:len(mesh)-1], > vertices = l == 0 ? [] : [ for(i=range) for(pt=mesh[i]) pt ], > tris = concat( [ for(i=[0:n-2],j=[0:m-2]) [ i*m+j, i*m+j+1, > (i+1)*m+j ] ] , > [ for(i=[0:n-2],j=[0:m-2]) [ i*m+j+1, > (i+1)*m+j+1, (i+1)*m+j ] ] ) ) > [ vertices, tris ]: > [] ; > > // generates polyhedron data for a closed polygonal face > function polygon2polyhedron(polygon, inv=false) = > let( vertices = polygon, > range = inv ? [len(polygon)-1: -1: 0] : [0:len(polygon)-1], > facets = [[for(i=range) i ]] ) > [ vertices, facets ]; Now, the application code just call the appropriate functions with pieces of the polyhedron surface, concatenate all of them and send to make_polyhedron. The flexibility of the approach is evident when a new kind of object (like a Bezier triangular patch, or a sweep or loft) is created and just one function is needed to be coded to include it in the system. If the cap of sweep is optional, the main code may build a special cap made of Bezier patches before sending all to make_polyhedron. And so, fingers are also possible. -- View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057p19097.html Sent from the OpenSCAD mailing list archive at Nabble.com.
P
Parkinbot
Mon, Nov 14, 2016 10:38 PM

You are right, it is obvious that you can have a more general interface.
skin() for instance accepts polygons with different vertex numbers - and
uses some automatism to deal with that. Of course you also can prepare a
polyhedron call by just wrapping all the needed information about faces and
vertices into a common structure and unwrap again before doing the call.
But isn't that more an interface rather than an abstraction that uses some
regularization to reduce the amount of information (and preparation) to be
passed? The former is how I understand your approach - at least from the
code you show. Knowing your stuff a bit, I suppose there is some more magic
behind, e.g. where your beziers come into play.

What do I mean by magic? When I designed sweep() my primary aim was to get a
tool for generalized extrusions that allows for refinement by using
interpolation schemes (applicable by the polygon generator AND the path
generator). The secondary aim was to have all "knitting" be done by the
function. The price for this "magic" was some structural constraints, like

  1. all polygons must be simple and have an equal number of points - which
    skin() doesn't require
  2. each two subsequent polygons get connected with a fixed scheme: n-th
    vertex to n-th vertex
  3. polygons must describe a non-selfintersecting extrusion path

From a topological point of view this is of course not even the tip of the

iceberg but it is a milestone away from what linear_extrude() can do. You
are welcome to define new schemes that allow e.g. to define extrusions with
furcations and anastomoses. But: as long as I have to compose the full
points list AND full faces list on my own, I don't see much progress. It is
the (hidden) magic that turns an interface into a new concept.

--
View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057p19102.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

You are right, it is obvious that you can have a more general interface. *skin()* for instance accepts polygons with different vertex numbers - and uses some automatism to deal with that. Of course you also can prepare a polyhedron call by just wrapping all the needed information about faces and vertices into a common structure and unwrap again before doing the call. But isn't that more an interface rather than an abstraction that uses some regularization to reduce the amount of information (and preparation) to be passed? The former is how I understand your approach - at least from the code you show. Knowing your stuff a bit, I suppose there is some more magic behind, e.g. where your beziers come into play. What do I mean by magic? When I designed sweep() my primary aim was to get a tool for generalized extrusions that allows for refinement by using interpolation schemes (applicable by the polygon generator AND the path generator). The secondary aim was to have all "knitting" be done by the function. The price for this "magic" was some structural constraints, like 1. all polygons must be simple and have an equal number of points - which *skin()* doesn't require 2. each two subsequent polygons get connected with a fixed scheme: n-th vertex to n-th vertex 3. polygons must describe a non-selfintersecting extrusion path >From a topological point of view this is of course not even the tip of the iceberg but it is a milestone away from what linear_extrude() can do. You are welcome to define new schemes that allow e.g. to define extrusions with furcations and anastomoses. But: as long as I have to compose the full points list AND full faces list on my own, I don't see much progress. It is the (hidden) magic that turns an interface into a new concept. -- View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057p19102.html Sent from the OpenSCAD mailing list archive at Nabble.com.
R
Ronaldo
Fri, Nov 18, 2016 12:28 AM

Rudolf,

I agree with you. My observations about how to connect parts in one module
to render a polyhedron is a low level technique. My point is that it is a
very flexible one and it allows many different uses, and that is an
important property in low level stages. I expect that this will become
apparent in the following.

Yes, I have a dream! I want to render organic models in OpenSCAD.

When I started to write my Bezier library in OpenSCAD I had no idea how to
integrated it. Soon I realized that in a non-interactive environment like
OpenSCAD, the Bezier control points are as hard to work with as the
definition of faces of a complex polyhedron. So I needed to address those
two issues.

At first, I worked in modules to help me to visualize and debug Bezier
curves and tensor product surfaces. Those are non-manifold geometries. To
build a model to be rendered I needed a module to integrate a list of
surface patch meshes with a list of faces in one polyhedron complying the
manifold topology: an output module. This task was simplified by one key
observation: the list of vertices of a polyhedron may have many incarnations
of the same vertex coordinates and two different faces will be connected
even when they refer to different incarnations of the same vertex. CGAL
seems to collapse all vertices with same coordinates and connect faces based
on vertex coordinates, similar to STL processing. This observation
simplified a lot the task of integrating many surfaces in one polyhedron:
each face may be processed individually.

The first issue, how to deal with the definition of lots of control points
of a model, is bit harder to solve. After the implementation of spline
interpolation methods I started to explore loft techniques to  connect
"automatically" individual surface patches. The following image depict one
of those experiment.

http://forum.openscad.org/file/n19203/loft_experiment.png

The model in the back plane shows an exploded view of the middle one. It is
composed by 5 parts: two rounded caps, two splines surfaces interpolating
the blue-marked points and a cubic loft surface connecting them. All
surfaces are C2 and all surface-surface meetings are G1, geometrically
differentiable. When all the meshes of those 5 patches are integrated in one
polyhedron we have one acceptable CGAL manifold. It can boolean operated.
No, not yet! As you see in this thrown together image, some faces are
wrongly oriented. To repair this you can either change the surface
definitions accordingly or, easier, just mark them to be reverted by the
output module.

This is the current state of my "magic", as you call it. The only data to
build this model were the 24 blue-marked points and some few floats that
control the shape of the lofts. The first plane model, for instance, used
the same definitions of the middle one except for the higher "scales" of the
tangents at the caps border. To build this kind of model you don't need to
understand fully Bezier curves and surface theory.

But my goal is a bit further. I want to integrate triangular Bezier patches
and create shapes with genus. After all, the model above is nothing more
than a generalized sweep, skin or loft with rounded caps. I have no tools
yet to create a model with genus. If to be able to build models with genus I
need to model furcations and anastomoses and, therewith, fingers and hands!

And this is the "magic" I am pursuing now.

--
View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057p19203.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Rudolf, I agree with you. My observations about how to connect parts in one module to render a polyhedron is a low level technique. My point is that it is a very flexible one and it allows many different uses, and that is an important property in low level stages. I expect that this will become apparent in the following. Yes, I have a dream! I want to render organic models in OpenSCAD. When I started to write my Bezier library in OpenSCAD I had no idea how to integrated it. Soon I realized that in a non-interactive environment like OpenSCAD, the Bezier control points are as hard to work with as the definition of faces of a complex polyhedron. So I needed to address those two issues. At first, I worked in modules to help me to visualize and debug Bezier curves and tensor product surfaces. Those are non-manifold geometries. To build a model to be rendered I needed a module to integrate a list of surface patch meshes with a list of faces in one polyhedron complying the manifold topology: an output module. This task was simplified by one key observation: the list of vertices of a polyhedron may have many incarnations of the same vertex coordinates and two different faces will be connected even when they refer to different incarnations of the same vertex. CGAL seems to collapse all vertices with same coordinates and connect faces based on vertex coordinates, similar to STL processing. This observation simplified a lot the task of integrating many surfaces in one polyhedron: each face may be processed individually. The first issue, how to deal with the definition of lots of control points of a model, is bit harder to solve. After the implementation of spline interpolation methods I started to explore loft techniques to connect "automatically" individual surface patches. The following image depict one of those experiment. <http://forum.openscad.org/file/n19203/loft_experiment.png> The model in the back plane shows an exploded view of the middle one. It is composed by 5 parts: two rounded caps, two splines surfaces interpolating the blue-marked points and a cubic loft surface connecting them. All surfaces are C2 and all surface-surface meetings are G1, geometrically differentiable. When all the meshes of those 5 patches are integrated in one polyhedron we have one acceptable CGAL manifold. It can boolean operated. No, not yet! As you see in this thrown together image, some faces are wrongly oriented. To repair this you can either change the surface definitions accordingly or, easier, just mark them to be reverted by the output module. This is the current state of my "magic", as you call it. The only data to build this model were the 24 blue-marked points and some few floats that control the shape of the lofts. The first plane model, for instance, used the same definitions of the middle one except for the higher "scales" of the tangents at the caps border. To build this kind of model you don't need to understand fully Bezier curves and surface theory. But my goal is a bit further. I want to integrate triangular Bezier patches and create shapes with genus. After all, the model above is nothing more than a generalized sweep, skin or loft with rounded caps. I have no tools yet to create a model with genus. If to be able to build models with genus I need to model furcations and anastomoses and, therewith, fingers and hands! And this is the "magic" I am pursuing now. -- View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057p19203.html Sent from the OpenSCAD mailing list archive at Nabble.com.
P
Parkinbot
Fri, Nov 18, 2016 3:50 PM

Ronaldo, I expected something like this and I am looking forward to see your
patchwork approach implemented as fullgrown concept, which will be a long
way to go, especially when you want address different genera. It was also my
first impression about the use of Beziers in OpenSCAD that you will easily
get lost without having at least a minimum of (preferable GUI)
interactivity.
I like your idea,

CGAL seems to collapse all vertices with same coordinates and connect
faces based on vertex coordinates, similar to STL processing. This
observation simplified a lot the task of integrating many surfaces in one
polyhedron: each face may be processed individually.

but as far as I know, this is not documented and might change in future.
Usually it is not a good idea, to build new cities on such grounding. Maybe
one from the dev team can say more about this.

But back to your approach. I have the impression that it might be a good
idea to connect the simpler sweep() approach with your stuff: Using sweep()
with all its restrictions and advantages (planar polgons, easy
transformations, description, and meshing) for the G0/G1 parts of a design,
and to model just the transition zones, where furcations actually happen,
with your pathwork design. In this case, your generator's input could be one
or more (consecutive) planar polygons, already transformed into 3D, for each
branch. The first polygon defines the border (meeting zone) with all its
vertices, the others slopes (also of higher order) - all polygons together
form your boundary condition, that can be transferred into Bezier
parameters. The desired output would be the e.g. C2 continued mesh. You can
view this as an isolated problem, since it is perfectly allowed to union
polyhedra (even it is slow right now).
I have sketched this approach once in  an other thread
http://forum.openscad.org/Rendering-fails-difference-between-F5-and-F6-tp15041p15182.html
, but never found time (and enough reason) to go deeper into the sloppy
modelling of the transition zone.

--
View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057p19218.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Ronaldo, I expected something like this and I am looking forward to see your patchwork approach implemented as fullgrown concept, which will be a long way to go, especially when you want address different genera. It was also my first impression about the use of Beziers in OpenSCAD that you will easily get lost without having at least a minimum of (preferable GUI) interactivity. I like your idea, > CGAL seems to collapse all vertices with same coordinates and connect > faces based on vertex coordinates, similar to STL processing. This > observation simplified a lot the task of integrating many surfaces in one > polyhedron: each face may be processed individually. but as far as I know, this is not documented and might change in future. Usually it is not a good idea, to build new cities on such grounding. Maybe one from the dev team can say more about this. But back to your approach. I have the impression that it might be a good idea to connect the simpler sweep() approach with your stuff: Using sweep() with all its restrictions and advantages (planar polgons, easy transformations, description, and meshing) for the G0/G1 parts of a design, and to model just the transition zones, where furcations actually happen, with your pathwork design. In this case, your generator's input could be one or more (consecutive) planar polygons, already transformed into 3D, for each branch. The first polygon defines the border (meeting zone) with all its vertices, the others slopes (also of higher order) - all polygons together form your boundary condition, that can be transferred into Bezier parameters. The desired output would be the e.g. C2 continued mesh. You can view this as an isolated problem, since it is perfectly allowed to union polyhedra (even it is slow right now). I have sketched this approach once in an other thread <http://forum.openscad.org/Rendering-fails-difference-between-F5-and-F6-tp15041p15182.html> , but never found time (and enough reason) to go deeper into the sloppy modelling of the transition zone. -- View this message in context: http://forum.openscad.org/Can-you-sweep-a-object-with-fingers-tp19057p19218.html Sent from the OpenSCAD mailing list archive at Nabble.com.
DM
doug moen
Fri, Nov 18, 2016 5:25 PM

Ronaldo said "Yes, I have a dream! I want to render organic models in
OpenSCAD."

+1. I want to do this too.

On 17 November 2016 at 19:28, Ronaldo rcmpersiano@gmail.com wrote:

Rudolf,

I agree with you. My observations about how to connect parts in one module
to render a polyhedron is a low level technique. My point is that it is a
very flexible one and it allows many different uses, and that is an
important property in low level stages. I expect that this will become
apparent in the following.

Yes, I have a dream! I want to render organic models in OpenSCAD.

When I started to write my Bezier library in OpenSCAD I had no idea how to
integrated it. Soon I realized that in a non-interactive environment like
OpenSCAD, the Bezier control points are as hard to work with as the
definition of faces of a complex polyhedron. So I needed to address those
two issues.

At first, I worked in modules to help me to visualize and debug Bezier
curves and tensor product surfaces. Those are non-manifold geometries. To
build a model to be rendered I needed a module to integrate a list of
surface patch meshes with a list of faces in one polyhedron complying the
manifold topology: an output module. This task was simplified by one key
observation: the list of vertices of a polyhedron may have many
incarnations
of the same vertex coordinates and two different faces will be connected
even when they refer to different incarnations of the same vertex. CGAL
seems to collapse all vertices with same coordinates and connect faces
based
on vertex coordinates, similar to STL processing. This observation
simplified a lot the task of integrating many surfaces in one polyhedron:
each face may be processed individually.

The first issue, how to deal with the definition of lots of control points
of a model, is bit harder to solve. After the implementation of spline
interpolation methods I started to explore loft techniques to  connect
"automatically" individual surface patches. The following image depict one
of those experiment.

http://forum.openscad.org/file/n19203/loft_experiment.png

The model in the back plane shows an exploded view of the middle one. It is
composed by 5 parts: two rounded caps, two splines surfaces interpolating
the blue-marked points and a cubic loft surface connecting them. All
surfaces are C2 and all surface-surface meetings are G1, geometrically
differentiable. When all the meshes of those 5 patches are integrated in
one
polyhedron we have one acceptable CGAL manifold. It can boolean operated.
No, not yet! As you see in this thrown together image, some faces are
wrongly oriented. To repair this you can either change the surface
definitions accordingly or, easier, just mark them to be reverted by the
output module.

This is the current state of my "magic", as you call it. The only data to
build this model were the 24 blue-marked points and some few floats that
control the shape of the lofts. The first plane model, for instance, used
the same definitions of the middle one except for the higher "scales" of
the
tangents at the caps border. To build this kind of model you don't need to
understand fully Bezier curves and surface theory.

But my goal is a bit further. I want to integrate triangular Bezier patches
and create shapes with genus. After all, the model above is nothing more
than a generalized sweep, skin or loft with rounded caps. I have no tools
yet to create a model with genus. If to be able to build models with genus
I
need to model furcations and anastomoses and, therewith, fingers and hands!

And this is the "magic" I am pursuing now.

--
View this message in context: http://forum.openscad.org/Can-
you-sweep-a-object-with-fingers-tp19057p19203.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

Ronaldo said "Yes, I have a dream! I want to render organic models in OpenSCAD." +1. I want to do this too. On 17 November 2016 at 19:28, Ronaldo <rcmpersiano@gmail.com> wrote: > Rudolf, > > I agree with you. My observations about how to connect parts in one module > to render a polyhedron is a low level technique. My point is that it is a > very flexible one and it allows many different uses, and that is an > important property in low level stages. I expect that this will become > apparent in the following. > > Yes, I have a dream! I want to render organic models in OpenSCAD. > > When I started to write my Bezier library in OpenSCAD I had no idea how to > integrated it. Soon I realized that in a non-interactive environment like > OpenSCAD, the Bezier control points are as hard to work with as the > definition of faces of a complex polyhedron. So I needed to address those > two issues. > > At first, I worked in modules to help me to visualize and debug Bezier > curves and tensor product surfaces. Those are non-manifold geometries. To > build a model to be rendered I needed a module to integrate a list of > surface patch meshes with a list of faces in one polyhedron complying the > manifold topology: an output module. This task was simplified by one key > observation: the list of vertices of a polyhedron may have many > incarnations > of the same vertex coordinates and two different faces will be connected > even when they refer to different incarnations of the same vertex. CGAL > seems to collapse all vertices with same coordinates and connect faces > based > on vertex coordinates, similar to STL processing. This observation > simplified a lot the task of integrating many surfaces in one polyhedron: > each face may be processed individually. > > The first issue, how to deal with the definition of lots of control points > of a model, is bit harder to solve. After the implementation of spline > interpolation methods I started to explore loft techniques to connect > "automatically" individual surface patches. The following image depict one > of those experiment. > > <http://forum.openscad.org/file/n19203/loft_experiment.png> > > The model in the back plane shows an exploded view of the middle one. It is > composed by 5 parts: two rounded caps, two splines surfaces interpolating > the blue-marked points and a cubic loft surface connecting them. All > surfaces are C2 and all surface-surface meetings are G1, geometrically > differentiable. When all the meshes of those 5 patches are integrated in > one > polyhedron we have one acceptable CGAL manifold. It can boolean operated. > No, not yet! As you see in this thrown together image, some faces are > wrongly oriented. To repair this you can either change the surface > definitions accordingly or, easier, just mark them to be reverted by the > output module. > > This is the current state of my "magic", as you call it. The only data to > build this model were the 24 blue-marked points and some few floats that > control the shape of the lofts. The first plane model, for instance, used > the same definitions of the middle one except for the higher "scales" of > the > tangents at the caps border. To build this kind of model you don't need to > understand fully Bezier curves and surface theory. > > But my goal is a bit further. I want to integrate triangular Bezier patches > and create shapes with genus. After all, the model above is nothing more > than a generalized sweep, skin or loft with rounded caps. I have no tools > yet to create a model with genus. If to be able to build models with genus > I > need to model furcations and anastomoses and, therewith, fingers and hands! > > And this is the "magic" I am pursuing now. > > > > > > -- > View this message in context: http://forum.openscad.org/Can- > you-sweep-a-object-with-fingers-tp19057p19203.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 > > >