flattening curved surfaces
Parkinbot wrote
I like your approach and I don't think it is too difficult to implement,
if you restrict the design to a set of constraints, which your parser can
assume to hold without further testing. (Also I don't see any advantage in
using AMF instead of STL.)
I have suggested AMF file export because this is the input file format
Neon22's python code requires to generate the polyhedron data.
Do you call that a not difficult to implement solution?
Rely on thresholds is not a good strategy. For instance, subdivide a square
in 4 triangles meeting at its center and move up slightly two opposed
vertices and move down the other two. It will not be a developable surface
but may pass a reasonable threshold. The main property of triangulated
developable surfaces that may be handy is that the sum of the internal
angles of the triangles incident at each vertex of such surfaces should be
360 degrees.
One strategy to find the pieces of developable surfaces could be to
calculate that sum at each vertex of the triangulation and collect those
vertices that have the required sum of 360 degrees and are in the same
connected component of the triangulation. To do that you possibly will need
a triangulation data structure that is not trivial to implement in OpenSCAD.
--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19738.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 25. des. 2016 13:16, Ronaldo wrote:
Carsten is right but there is a workaround. A python code by Neon22 converts
AMF files (possibly exported by OpenSCAD) to a text file in the OpenSCAD
polyhedron format. See this discussion
http://forum.openscad.org/Wrapping-text-around-a-complex-geometry-td18145.html#a18156
That is a good idea, but he appears to manually modify the converted
code to get the modified coordinates, a bit cumbersome. Another idea
along the same lines would be to do the coordinate modification in the
conversion code, which would essentially become a 'morphing conversion',
see below.
On the issue of unfolding the surfaces to be traced on paper, it is not
possible in the general case, I agree. A spherical surface cannot be
unfolded on a flat surface for example.
On morphing, I tried it using jons model (scaled up 10x and using
$fn=300 in OpenSCAD). Since all sides are curved in the first place, it
lends itself to easy morphing (to some degree). An image of the original
shape is attached. Example morphing code (angelscript), using the AMF
generated by OpenSCAD:
polyhedron@ cs = polyhedron("curved_surfaces.amf");
double px=8;
double pz=4;
const double pi = 4.0*atan(1.0);
// compute transformed vertices
pos3d@[] vert(nv);
for(uint iv=0; iv<nv; iv++) {
pos3d@ p = cs.vertex(iv);
double par = (p.y() - ymin)/(ymax - ymin);
double sx = 1+0.1*cos(px*pi*par);
double sz = 1.2+0.1*cos(pz*pi*par);
@vert[iv] = scale(sx,1,sz)*p;
}
// transfer the faces
pface@[] faces(nf);
for(uint iface=0; iface<nf; iface++) {
@faces[iface] = cs.face(iface);
}
polyhedron@ cs_morphed = polyhedron(vert,faces);
The second image shows the result. Lots of opportunities with such an
approach...
However, for a model containing flat surfaces, it actually gets a bit
more complicated, since you normally don't have vertices to modify
within those flat surfaces. One way to solve that problem is to "remesh"
the surfaces to obtain much smaller triangles, and many more vertices.
Then you can apply the same technique as above.
Carsten Arnholm
Ronaldo,
I understood that Jon wanted to use a traditional programming language
providing support for file read operations and structs, but reading his post
again, I am not so sure about this any more.
I have a conceptual idea of how this would be done in a traditional
programming language if I had a list of the coordinates along each of the
4 boundary lines.
Of course there can be other (more sophisticated) strategies for surface
separation applied. But I don't think that will be needed.
Do you call that a not difficult to implement solution?
Well, parsing some STL (which is already partly sorted), building a topology
from it and applying a predicate to adjacent triags indeed doesn't seem too
be difficult in my eyes.
Indeed it is something like a twenty-liner to convert a wellformed STL into
some scad file for reimport. Undoubtedly it IS somehow clumsy to continue in
OpenSCAD than, mainly because of its "peculiar" language design and poor
data structures, but even there ...
My opinion: If you are already using a traditional programming language, why
not stay there to also keep control over your output - unless you are fine
with some DXF output.
--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19740.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Ronaldo wrote
Rely on thresholds is not a good strategy. For instance, subdivide a
square in 4 triangles meeting at its center and move up slightly two
opposed vertices and move down the other two. It will not be a developable
surface but may pass a reasonable threshold.
You can always construct those counter examples. My opinion is: Know what
you do, already when you do your design. This is what I meant by rule 1.
The main property of triangulated developable surfaces that may be handy
is that the sum of the internal angles of the triangles incident at each
vertex of such surfaces should be 360 degrees.
Isn't that too strict? Doesn't it hold only for planar surfaces?
--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19741.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
2016-12-25 14:32 GMT-02:00 Parkinbot rudolf@parkinbot.com:
Ronaldo wrote
The main property of triangulated developable surfaces that may be handy
is that the sum of the internal angles of the triangles incident at each
vertex of such surfaces should be 360 degrees.
Isn't that too strict? Doesn't it hold only for planar surfaces?
Certainly is not too strict. If a set of triangle around a vertex are part
of a developable surface this condition must be met. Otherwise, when they
are laid down on a plane, either they will not close (for angle sum lesser
then 360) or they will overlap. Note that this condition should be met at
the internal vertices. For the border vertices the sum should be lesser
than 360.
Ronaldo wrote
Certainly is not too strict.
I doubt that. Have a look at a cylinder. It contains 3 surfaces that
doubtless can be unrolled into 2D. Two of them meet your condition, the
third one doesn't. A threshold can be easily selected to separate the
triags.
--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19743.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Parkinbot wrote
Have a look at a cylinder. It contains 3 surfaces that doubtless can be
unrolled into 2D. Two of them meet your condition, the third one doesn't.
A threshold can be easily selected to separate the triags.
If the only vertices of your cylinder (a prism to be precise) is at the
borders of the two planar faces, then none of them satisfies the condition.
So they cannot be in the interior of the developed surfaces. Any other
vertex not in those borders will satisfy the condition and will be eligible
to be inside.
Observe that the problem of finding a partition of developable surfaces for
a given polyhedron has many solutions. A trivial one is to define a
partition of isolated triangles. Another is a partition of triangle pairs.
In the case of a prism, it is possible to find a unique partition for the
whole surface. There is no better solution, only wrong ones.
--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19745.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
It is very tiring to discuss such obvious things and subtleties. Again: I am
perfectly sure that the sketched algorithm will work. If you know a better
solution, then please present it in a constructive way, so that we follow
it.
--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19746.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
I have seen several implementations of this. There are a couple of guidelines
which you might wish to follow just to simplify the code.
- triangulate before unrolling. less cases to deal with.
- to avoid overlaps, unroll, test and move around to a different face if it
overlaps. Else split the shape to a new boundary so overlaps can be avoided. - check your progress against pepakura - a free version of which can be
downloaded to view opened files.
Pepakura is designed for paper folding and low polygon polyhedra which
approximate the more detailed surface. It is quite robust.
After you have it all unrolled you're into packing algorithms but that's a
different tail...
(https://github.com/Jack000/SVGnest)
--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19747.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Parkinbot wrote
So what does your algorithm? It reads the triags into a set T and
a) finds and hooks the three (common edge) neighbours to each triag in T.
I supposed that at this stage, the coordinates of each points are already
known ?
$ Runsun Pan, PhD $ libs: doctest , faces ( git ), offline doc ( git ), runscad.py ( 2 , git ), synwrite ( 2 ); $ tips: Bezier , hash ( 2 ), matrix ( 2 , 3 ), sweep ( 2 , 3 ), var ( 2 ), lerp , animation ( gif , prodVid , animlib ), precision ( 2 ), xl-control , type , rounded polygon , chfont , tailRecur ( 2 , 3 , 4 ), isosphere ( 2 ), area , vol/center , RGB , CurvedImg , tests ( 2 ), text , triang , unit ; $ Apps: rollApp , blockscad , openjscad , on AWS ( pdf ), support_tools
--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19748.html
Sent from the OpenSCAD mailing list archive at Nabble.com.