Empathy List Archives

J

jon

Sun, Dec 25, 2016 12:39 AM

I have a bit of code at the end of this question. It produces a shape
with 4 curved sides, each of which lies on the surface of a cylinder.
Note that this is an example shape: I want to work with families of
similar shapes, not just with this one example.

I would like a way to take each of the 4 surfaces and produce a 2D shape
that, when cut out and bent, would conform to the original surface. The
idea is to be able to create the original shape out of, say, cardboard
by cutting out the 4 2D shapes and then taping them together.

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. I considered re-writing the code, below, as a
sweep, and generating the coordinates explicitly, but a) that is not
trivial (to me), and ii) I want to solve the more general case where the
equations that determine the shape are not known. I looked at the
generated STL file, and the coordinates are there, but not organized in
the way that I would want them to be.

This may be more effort than I want to expend, but I wondered if anyone
had a brilliant insight.

Thanks!

Jon

le = 10; // length
d1 = 25; // diameter of top
d2 = 35; // diameter of bottom
d = -8; // delta to drop center of bottom

$fn = 100;

module shape() {
translate([0, 0, -6])
intersection() {
translate([-le/2, 0, 0])
difference() {
rotate([0, 90, 0])
cylinder(h = le, d = d1);
translate([-1, 0, d])
rotate([0, 90, 0])
cylinder(h = le + 2, d = d2);
}

         intersection() {
             translate([10, 0, 0])
                 cylinder(h = 100, d = 30);
             translate([-10, 0, 0])
                 cylinder(h = 100, d = 30);
             }
         }
     }

shape();

*difference() {
shape();
translate([0, 0, -4])
scale([0.8, 0.8, 2])
shape();
}

I have a bit of code at the end of this question. It produces a shape with 4 curved sides, each of which lies on the surface of a cylinder. Note that this is an example shape: I want to work with families of similar shapes, not just with this one example. I would like a way to take each of the 4 surfaces and produce a 2D shape that, when cut out and bent, would conform to the original surface. The idea is to be able to create the original shape out of, say, cardboard by cutting out the 4 2D shapes and then taping them together. 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. I considered re-writing the code, below, as a sweep, and generating the coordinates explicitly, but a) that is not trivial (to me), and ii) I want to solve the more general case where the equations that determine the shape are not known. I looked at the generated STL file, and the coordinates are there, but not organized in the way that I would want them to be. This may be more effort than I want to expend, but I wondered if anyone had a brilliant insight. Thanks! Jon le = 10; // length d1 = 25; // diameter of top d2 = 35; // diameter of bottom d = -8; // delta to drop center of bottom $fn = 100; module shape() { translate([0, 0, -6]) intersection() { translate([-le/2, 0, 0]) difference() { rotate([0, 90, 0]) cylinder(h = le, d = d1); translate([-1, 0, d]) rotate([0, 90, 0]) cylinder(h = le + 2, d = d2); } intersection() { translate([10, 0, 0]) cylinder(h = 100, d = 30); translate([-10, 0, 0]) cylinder(h = 100, d = 30); } } } shape(); *difference() { shape(); translate([0, 0, -4]) scale([0.8, 0.8, 2]) shape(); }

FV

Frank van der Hulst

Sun, Dec 25, 2016 1:30 AM

You might want to look at map projections... cartographers have been
working on this for centuries (for the oblate spheroid class of surfaces).

On 25/12/2016 13:40, "jon" jon@jonbondy.com wrote:

I have a bit of code at the end of this question. It produces a shape
with 4 curved sides, each of which lies on the surface of a cylinder. Note
that this is an example shape: I want to work with families of similar
shapes, not just with this one example.

I would like a way to take each of the 4 surfaces and produce a 2D shape
that, when cut out and bent, would conform to the original surface. The
idea is to be able to create the original shape out of, say, cardboard by
cutting out the 4 2D shapes and then taping them together.

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. I considered re-writing the code, below, as a sweep, and
generating the coordinates explicitly, but a) that is not trivial (to me),
and ii) I want to solve the more general case where the equations that
determine the shape are not known. I looked at the generated STL file, and
the coordinates are there, but not organized in the way that I would want
them to be.

This may be more effort than I want to expend, but I wondered if anyone
had a brilliant insight.

Thanks!

Jon

le = 10; // length
d1 = 25; // diameter of top
d2 = 35; // diameter of bottom
d = -8; // delta to drop center of bottom

$fn = 100;

module shape() {
translate([0, 0, -6])
intersection() {
translate([-le/2, 0, 0])
difference() {
rotate([0, 90, 0])
cylinder(h = le, d = d1);
translate([-1, 0, d])
rotate([0, 90, 0])
cylinder(h = le + 2, d = d2);
}

         intersection() {
             translate([10, 0, 0])
                 cylinder(h = 100, d = 30);
             translate([-10, 0, 0])
                 cylinder(h = 100, d = 30);
             }
         }
     }

shape();

*difference() {
shape();
translate([0, 0, -4])
scale([0.8, 0.8, 2])
shape();
}

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

You might want to look at map projections... cartographers have been working on this for centuries (for the oblate spheroid class of surfaces). On 25/12/2016 13:40, "jon" <jon@jonbondy.com> wrote: > I have a bit of code at the end of this question. It produces a shape > with 4 curved sides, each of which lies on the surface of a cylinder. Note > that this is an example shape: I want to work with families of similar > shapes, not just with this one example. > > I would like a way to take each of the 4 surfaces and produce a 2D shape > that, when cut out and bent, would conform to the original surface. The > idea is to be able to create the original shape out of, say, cardboard by > cutting out the 4 2D shapes and then taping them together. > > 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. I considered re-writing the code, below, as a sweep, and > generating the coordinates explicitly, but a) that is not trivial (to me), > and ii) I want to solve the more general case where the equations that > determine the shape are not known. I looked at the generated STL file, and > the coordinates are there, but not organized in the way that I would want > them to be. > > This may be more effort than I want to expend, but I wondered if anyone > had a brilliant insight. > > Thanks! > > Jon > > > le = 10; // length > d1 = 25; // diameter of top > d2 = 35; // diameter of bottom > d = -8; // delta to drop center of bottom > > $fn = 100; > > module shape() { > translate([0, 0, -6]) > intersection() { > translate([-le/2, 0, 0]) > difference() { > rotate([0, 90, 0]) > cylinder(h = le, d = d1); > translate([-1, 0, d]) > rotate([0, 90, 0]) > cylinder(h = le + 2, d = d2); > } > > intersection() { > translate([10, 0, 0]) > cylinder(h = 100, d = 30); > translate([-10, 0, 0]) > cylinder(h = 100, d = 30); > } > } > } > > shape(); > > *difference() { > shape(); > translate([0, 0, -4]) > scale([0.8, 0.8, 2]) > shape(); > } > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

CA

Carsten Arnholm

Sun, Dec 25, 2016 1:46 AM

On 25. des. 2016 01:39, jon wrote:

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. I considered re-writing the code, below, as a
sweep, and generating the coordinates explicitly, but a) that is not
trivial (to me), and ii) I want to solve the more general case where the
equations that determine the shape are not known. I looked at the
generated STL file, and the coordinates are there, but not organized in
the way that I would want them to be.

Whether your idea is really worth pursuing is a issue in itself, but if
you want to try it is probably easier to export to AMF, OpenSCAD can do
it. https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format

AMF is an XML file format containing the result of booleans in a form
very similar to an OpenSCAD polyhedron, with unique vertices separate
from the (triangular) faces and each face defined as 3 vertex indices.
This means you have topology to work with, not just a "polygon soup" as
in STL. With STL you would have to rediscover a topology first, a
non-trivial task in the general case.

So in principle, using a traditional programming language, you could
read the AMF and detect the "boundary lines" by evaluating the angles
between neighbouring faces (finding neighbouring faces requires topology
evaluation). That would be just the start of another non-trivial task to
detect the faces bound by those boundaries. It could certainly succeed,
but a general solution would take quite some effort.

Using only OpenSCAD, something like that is not possible at all, since
there is no way in the language to access the vertices and faces of the
result of a boolean operation.

Carsten Arnholm

On 25. des. 2016 01:39, jon wrote: > 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. I considered re-writing the code, below, as a > sweep, and generating the coordinates explicitly, but a) that is not > trivial (to me), and ii) I want to solve the more general case where the > equations that determine the shape are not known. I looked at the > generated STL file, and the coordinates are there, but not organized in > the way that I would want them to be. Whether your idea is really worth pursuing is a issue in itself, but if you want to try it is probably easier to export to AMF, OpenSCAD can do it. https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format AMF is an XML file format containing the result of booleans in a form very similar to an OpenSCAD polyhedron, with unique vertices separate from the (triangular) faces and each face defined as 3 vertex indices. This means you have topology to work with, not just a "polygon soup" as in STL. With STL you would have to rediscover a topology first, a non-trivial task in the general case. So in principle, using a traditional programming language, you could read the AMF and detect the "boundary lines" by evaluating the angles between neighbouring faces (finding neighbouring faces requires topology evaluation). That would be just the start of another non-trivial task to detect the faces bound by those boundaries. It could certainly succeed, but a general solution would take quite some effort. Using only OpenSCAD, something like that is not possible at all, since there is no way in the language to access the vertices and faces of the result of a boolean operation. Carsten Arnholm

J

jon

Sun, Dec 25, 2016 1:52 AM

That was not the answer I was hoping for, but it certainly is the answer
I was looking for!

Thank you!

On 12/24/2016 8:46 PM, Carsten Arnholm wrote:

On 25. des. 2016 01:39, jon wrote:

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. I considered re-writing the code, below, as a
sweep, and generating the coordinates explicitly, but a) that is not
trivial (to me), and ii) I want to solve the more general case where the
equations that determine the shape are not known. I looked at the
generated STL file, and the coordinates are there, but not organized in
the way that I would want them to be.

Whether your idea is really worth pursuing is a issue in itself, but
if you want to try it is probably easier to export to AMF, OpenSCAD
can do it.
https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format

AMF is an XML file format containing the result of booleans in a form
very similar to an OpenSCAD polyhedron, with unique vertices separate
from the (triangular) faces and each face defined as 3 vertex indices.
This means you have topology to work with, not just a "polygon soup"
as in STL. With STL you would have to rediscover a topology first, a
non-trivial task in the general case.

So in principle, using a traditional programming language, you could
read the AMF and detect the "boundary lines" by evaluating the angles
between neighbouring faces (finding neighbouring faces requires
topology evaluation). That would be just the start of another
non-trivial task to detect the faces bound by those boundaries. It
could certainly succeed, but a general solution would take quite some
effort.

Using only OpenSCAD, something like that is not possible at all, since
there is no way in the language to access the vertices and faces of
the result of a boolean operation.

Carsten Arnholm

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7924 / Virus Database: 4739/13648 - Release Date:
12/24/16

That was not the answer I was hoping for, but it certainly is the answer I was looking for! Thank you! On 12/24/2016 8:46 PM, Carsten Arnholm wrote: > On 25. des. 2016 01:39, jon wrote: >> 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. I considered re-writing the code, below, as a >> sweep, and generating the coordinates explicitly, but a) that is not >> trivial (to me), and ii) I want to solve the more general case where the >> equations that determine the shape are not known. I looked at the >> generated STL file, and the coordinates are there, but not organized in >> the way that I would want them to be. > > Whether your idea is really worth pursuing is a issue in itself, but > if you want to try it is probably easier to export to AMF, OpenSCAD > can do it. > https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format > > AMF is an XML file format containing the result of booleans in a form > very similar to an OpenSCAD polyhedron, with unique vertices separate > from the (triangular) faces and each face defined as 3 vertex indices. > This means you have topology to work with, not just a "polygon soup" > as in STL. With STL you would have to rediscover a topology first, a > non-trivial task in the general case. > > So in principle, using a traditional programming language, you could > read the AMF and detect the "boundary lines" by evaluating the angles > between neighbouring faces (finding neighbouring faces requires > topology evaluation). That would be just the start of another > non-trivial task to detect the faces bound by those boundaries. It > could certainly succeed, but a general solution would take quite some > effort. > > Using only OpenSCAD, something like that is not possible at all, since > there is no way in the language to access the vertices and faces of > the result of a boolean operation. > > Carsten Arnholm > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2016.0.7924 / Virus Database: 4739/13648 - Release Date: > 12/24/16 > >

R

runsun

Sun, Dec 25, 2016 2:31 AM

jon_bondy wrote

Note that this is an example shape: I want to work with families of
similar shapes, not just with this one example.

I imagine that if it's possible to generate those shapes in polyhedron, it
won't be hard to achieve what you want.

$ 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-tp19727p19731.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

jon_bondy wrote > Note that this is an example shape: I want to work with families of > similar shapes, not just with this one example. I imagine that if it's possible to generate those shapes in polyhedron, it won't be hard to achieve what you want. ----- $ 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-tp19727p19731.html Sent from the OpenSCAD mailing list archive at Nabble.com.

CA

Carsten Arnholm

Sun, Dec 25, 2016 9:16 AM

On 25. des. 2016 02:52, jon wrote:

That was not the answer I was hoping for, but it certainly is the answer
I was looking for!

Thank you!

You are welcome. At least it may have saved you some time chasing the
unobtainable.

Carsten Arnholm

On 25. des. 2016 02:52, jon wrote: > That was not the answer I was hoping for, but it certainly is the answer > I was looking for! > > Thank you! You are welcome. At least it may have saved you some time chasing the unobtainable. Carsten Arnholm

NH

nop head

Sun, Dec 25, 2016 11:47 AM

Incidental to the question but when I put a # in front of the first
cylinder it doesn't show the whole cylinder. It does for the other three
cylinders. Why is that?

On 25 December 2016 at 09:16, Carsten Arnholm arnholm@arnholm.org wrote:

On 25. des. 2016 02:52, jon wrote:

That was not the answer I was hoping for, but it certainly is the answer
I was looking for!

Thank you!

You are welcome. At least it may have saved you some time chasing the
unobtainable.

Carsten Arnholm

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Incidental to the question but when I put a # in front of the first cylinder it doesn't show the whole cylinder. It does for the other three cylinders. Why is that? On 25 December 2016 at 09:16, Carsten Arnholm <arnholm@arnholm.org> wrote: > On 25. des. 2016 02:52, jon wrote: > >> That was not the answer I was hoping for, but it certainly is the answer >> I was looking for! >> >> Thank you! >> > > You are welcome. At least it may have saved you some time chasing the > unobtainable. > > > Carsten Arnholm > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

R

Ronaldo

Sun, Dec 25, 2016 12:16 PM

cacb wrote

On 25. des. 2016 01:39, jon wrote:
Using only OpenSCAD, something like that is not possible at all, since
there is no way in the language to access the vertices and faces of the
result of a boolean operation.

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
. By using its output file in you OpenSCAD code, you will have access to the
model vertices and a code may be devised to find and unfold the developable
surfaces. However, the latest doesn't seem to be a trivial task. See for
instance:
http://complexitys.com/english/geometry/developable-surfaces/#.WF9isH10ca9
http://complexitys.com/english/geometry/developable-surfaces/#.WF9isH10ca9

--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19735.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

cacb wrote > On 25. des. 2016 01:39, jon wrote: > Using only OpenSCAD, something like that is not possible at all, since > there is no way in the language to access the vertices and faces of the > result of a boolean operation. 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> . By using its output file in you OpenSCAD code, you will have access to the model vertices and a code may be devised to find and unfold the developable surfaces. However, the latest doesn't seem to be a trivial task. See for instance: http://complexitys.com/english/geometry/developable-surfaces/#.WF9isH10ca9 <http://complexitys.com/english/geometry/developable-surfaces/#.WF9isH10ca9> -- View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19735.html Sent from the OpenSCAD mailing list archive at Nabble.com.

P

Parkinbot

Sun, Dec 25, 2016 1:40 PM

Jon,
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.)

Rules:

(unrolling) - Your design is composed by a set of surfaces, which are
unrollable in 2D. This puts a bunch of restrictions on the surfaces (!!!)
(separation) - two edge-adjacent triangles belong to different surfaces,
if the scalar product of their normals exceeds some threshold parameter TH.

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.
b) calculates the scalar products of each two neighboured triag normals and
classifies by means of the threshold TH, if the two triags belong to the
same surfaces or not. Not-on-the-same-surface neighbours will be unhooked.
c) select any triag in T and move it to a set S. Continue with all its
same-surface neighbours and so on, until all same-surface triags are in S.
d. repeat with c until T is empty and get a set SS of surfaces.
e) unroll each surface S in SS into 2D. For example start with any triag t
i) find an affine transformation f that maps t undistorted to 2D (always
can be found).
ii) apply f to all direct neighbours and find for each of them a rotation
g that maps them to the 2D plane
iii) continue with ii using g(f(t)) until done.

You see, the scheme is quite straight forward (and easy to implement) and
the only difficulty you will encounter is step e), where it turns out
whether your design obeys to rule 1 or not. If it doesn't, you will have to
find a way (=heuristics) to deal with it. This can get more nasty.

--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19736.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Jon, 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.) Rules: 1. (unrolling) - Your design is composed by a set of surfaces, which are unrollable in 2D. This puts a bunch of restrictions on the surfaces (!!!) 2. (separation) - two edge-adjacent triangles belong to different surfaces, if the scalar product of their normals exceeds some threshold parameter TH. 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. b) calculates the scalar products of each two neighboured triag normals and classifies by means of the threshold TH, if the two triags belong to the same surfaces or not. Not-on-the-same-surface neighbours will be unhooked. c) select any triag in T and move it to a set S. Continue with all its same-surface neighbours and so on, until all same-surface triags are in S. d. repeat with c until T is empty and get a set SS of surfaces. e) unroll each surface S in SS into 2D. For example start with any triag t i) find an affine transformation f that maps t undistorted to 2D (always can be found). ii) apply f to all direct neighbours and find for each of them a rotation g that maps them to the 2D plane iii) continue with ii using g(f(t)) until done. You see, the scheme is quite straight forward (and easy to implement) and the only difficulty you will encounter is step e), where it turns out whether your design obeys to rule 1 or not. If it doesn't, you will have to find a way (=heuristics) to deal with it. This can get more nasty. -- View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19736.html Sent from the OpenSCAD mailing list archive at Nabble.com.

J

jon

Sun, Dec 25, 2016 1:44 PM

I KNEW there was a reason that I was about to retire! This should keep
me out of trouble for a while! Thanks for the pseudo code!

Jon

On 12/25/2016 8:40 AM, Parkinbot wrote:

Jon,
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.)

Rules:

(unrolling) - Your design is composed by a set of surfaces, which are
unrollable in 2D. This puts a bunch of restrictions on the surfaces (!!!)
(separation) - two edge-adjacent triangles belong to different surfaces,
if the scalar product of their normals exceeds some threshold parameter TH.

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.
b) calculates the scalar products of each two neighboured triag normals and
classifies by means of the threshold TH, if the two triags belong to the
same surfaces or not. Not-on-the-same-surface neighbours will be unhooked.
c) select any triag in T and move it to a set S. Continue with all its
same-surface neighbours and so on, until all same-surface triags are in S.
d. repeat with c until T is empty and get a set SS of surfaces.
e) unroll each surface S in SS into 2D. For example start with any triag t
i) find an affine transformation f that maps t undistorted to 2D (always
can be found).
ii) apply f to all direct neighbours and find for each of them a rotation
g that maps them to the 2D plane
iii) continue with ii using g(f(t)) until done.

You see, the scheme is quite straight forward (and easy to implement) and
the only difficulty you will encounter is step e), where it turns out
whether your design obeys to rule 1 or not. If it doesn't, you will have to
find a way (=heuristics) to deal with it. This can get more nasty.

--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19736.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

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7924 / Virus Database: 4739/13649 - Release Date: 12/24/16

I KNEW there was a reason that I was about to retire! This should keep me out of trouble for a while! Thanks for the pseudo code! Jon On 12/25/2016 8:40 AM, Parkinbot wrote: > Jon, > 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.) > > Rules: > 1. (unrolling) - Your design is composed by a set of surfaces, which are > unrollable in 2D. This puts a bunch of restrictions on the surfaces (!!!) > 2. (separation) - two edge-adjacent triangles belong to different surfaces, > if the scalar product of their normals exceeds some threshold parameter TH. > > 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. > b) calculates the scalar products of each two neighboured triag normals and > classifies by means of the threshold TH, if the two triags belong to the > same surfaces or not. Not-on-the-same-surface neighbours will be unhooked. > c) select any triag in T and move it to a set S. Continue with all its > same-surface neighbours and so on, until all same-surface triags are in S. > d. repeat with c until T is empty and get a set SS of surfaces. > e) unroll each surface S in SS into 2D. For example start with any triag t > i) find an affine transformation f that maps t undistorted to 2D (always > can be found). > ii) apply f to all direct neighbours and find for each of them a rotation > g that maps them to the 2D plane > iii) continue with ii using g(f(t)) until done. > > You see, the scheme is quite straight forward (and easy to implement) and > the only difficulty you will encounter is step e), where it turns out > whether your design obeys to rule 1 or not. If it doesn't, you will have to > find a way (=heuristics) to deal with it. This can get more nasty. > > > > > -- > View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19736.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 > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2016.0.7924 / Virus Database: 4739/13649 - Release Date: 12/24/16 > >

R

Ronaldo

Sun, Dec 25, 2016 2:52 PM

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.

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.

CA

Carsten Arnholm

Sun, Dec 25, 2016 2:55 PM

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

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

P

Parkinbot

Sun, Dec 25, 2016 4:23 PM

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

P

Parkinbot

Sun, Dec 25, 2016 4:32 PM

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.

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.

RP

Ronaldo Persiano

Sun, Dec 25, 2016 5:33 PM

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.

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.

P

Parkinbot

Sun, Dec 25, 2016 6:06 PM

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.

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.

R

Ronaldo

Sun, Dec 25, 2016 8:02 PM

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.

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.

P

Parkinbot

Sun, Dec 25, 2016 8:17 PM

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.

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.

N

Neon22

Sun, Dec 25, 2016 8:56 PM

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.

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.

R

runsun

Mon, Dec 26, 2016 1:17 AM

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.

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.

J

jon

Mon, Dec 26, 2016 1:50 AM

I've been writing some more pseudo code, and it seems that I need a
variety of 3D vector routines, including

dot product
cross product
normal to a triangle
angle between two vectors
rotate points around an axis

I rooted around on the web, and found most of the above. I took trig
and calculus, but it was ... a while ago. All of this is vaguely
familiar. If you know of either of the following resources, they would
be helpful to me.

a complete library for these kinds of routines ... written in ...
Pascal. Yeah. I know. Old habits die hard.

B) a web site that has tutorials on all of this stuff, including matrix
math (which I assume I will need for the rotation).

I wasn't planning on rolling my own, but here I go...

Thanks for any hints

Jon

I've been writing some more pseudo code, and it seems that I need a variety of 3D vector routines, including dot product cross product normal to a triangle angle between two vectors rotate points around an axis I rooted around on the web, and found most of the above. I took trig and calculus, but it was ... a while ago. All of this is vaguely familiar. If you know of either of the following resources, they would be helpful to me. 1) a complete library for these kinds of routines ... written in ... Pascal. Yeah. I know. Old habits die hard. B) a web site that has tutorials on all of this stuff, including matrix math (which I assume I will need for the rotation). I wasn't planning on rolling my own, but here I go... Thanks for any hints Jon

P

Parkinbot

Mon, Dec 26, 2016 1:28 PM

It is always a good project to brush up your math.

dot product

This is the scalar product to be used for the threshold criterium. Apply it
with the normalized (i.e. length=1) normals of your triangles.

cross product

being applied to two vectors spanned by your triag's vertices will get you
the normal of your triangle. Adapt orientation by inverting the sign. Divide
this vector by its length and you get a normalized normal. If you start from
an STL you will already find this value for each triangle there.

angle between two vectors

the scalarproduct of two normalized vectors will be cos(angle). So
acos(dot(a,b)) is your friend.

rotate points around an axis

you find the three matrices in wikipedia

a complete library for these kinds of routines ... written in ...
Pascal. Yeah. I know. Old habits die hard.

http://www.dtic.mil/dtic/tr/fulltext/u2/a218917.pdf

--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19760.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

It is always a good project to brush up your math. > dot product This is the scalar product to be used for the threshold criterium. Apply it with the normalized (i.e. length=1) normals of your triangles. > cross product being applied to two vectors spanned by your triag's vertices will get you the normal of your triangle. Adapt orientation by inverting the sign. Divide this vector by its length and you get a normalized normal. If you start from an STL you will already find this value for each triangle there. > angle between two vectors the scalarproduct of two normalized vectors will be cos(angle). So acos(dot(a,b)) is your friend. > rotate points around an axis you find the three matrices in wikipedia > 1) a complete library for these kinds of routines ... written in ... > Pascal. Yeah. I know. Old habits die hard. http://www.dtic.mil/dtic/tr/fulltext/u2/a218917.pdf -- View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19760.html Sent from the OpenSCAD mailing list archive at Nabble.com.

P

Parkinbot

Mon, Dec 26, 2016 2:06 PM

runsun wrote

I supposed that at this stage, the coordinates of each points are already
known ?

Certainly, the 3D points are known e.g. from the STL. But common-edge
triags share two points. So each triag will be represented by a structure
like in C/C++

struct triag{
point3 x, y, z, n;
triag ** CE_neighbour;
}

while the topologic sets would be implemented as list (or some similar
container type) for easy (un-)hooking.

The definite implementation of course depends on the programming paradigma
you are using. It can be done in OpenSCAD, if you are willing to juggle
around with nested lists.

--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19762.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

runsun wrote > I supposed that at this stage, the coordinates of each points are already > known ? Certainly, the 3D points are known e.g. from the STL. But *common-edge triags* share two points. So each triag will be represented by a structure like in C/C++ > struct triag{ > point3 x, y, z, n; > triag ** CE_neighbour; > } while the topologic sets would be implemented as list (or some similar container type) for easy (un-)hooking. The definite implementation of course depends on the programming paradigma you are using. It can be done in OpenSCAD, if you are willing to juggle around with nested lists. -- View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19762.html Sent from the OpenSCAD mailing list archive at Nabble.com.

NH

nop head

Mon, Dec 26, 2016 3:17 PM

Here is an approximate solution for objects with cylindrical surfaces:

le = 10; // length
d1 = 25; // diameter of top
d2 = 35; // diameter of bottom
d3 = 30; // side cylinders
d = -8; // delta to drop center of bottom

$fn = 100;

z_offset = -6;
x_offset = 10;

module shape() {
translate([0, 0, z_offset])
intersection(c) {
translate([x_offset, 0, 0])
cylinder(h = 100, d = d3);

        translate([-x_offset, 0, 0])
            cylinder(h = 100, d = d3);

         difference() {
            rotate([0, 90, 0])
                cylinder(h = le, d = d1, center = true);

            translate([0, 0, d])
                rotate([0, 90, 0])
                    cylinder(h = le + 2, d = d2, center = true);
        }
   }

}

%translate([0, 0, 5]) render() shape();

module flatten_cylinder(diameter, width, angle = 180, steps = 30 ) {
length = angle / 360 * PI * diameter;

for(i = [-steps / 2 + 1 : steps / 2 - 1])
    translate([0, i * length / steps, 0])
        offset(0.0001) projection() // expand slighly so they overlap
            union() {
                intersection() {
                    cube([width + 1, length / steps, diameter * (1 -

cos(angle / (steps * 2))) * 1.4], center = true);

                    translate([0, 0, -diameter / 2])
                        rotate([i * angle / steps, 0 , 0])
                            children();
                }
            }

}

flatten_cylinder(d1, le)
translate([0, 0, -z_offset])
shape();

translate([le + 1, 0])
flatten_cylinder(d2, le)
translate([0, 0, -z_offset - d])
shape();

translate([2 * le - 3, 0])
flatten_cylinder(d3, 2 * le)
translate([0, 0, x_offset])
rotate([0, 90, 0])
shape();

translate([-le + 3, 0])
flatten_cylinder(d3, 2 * le)
translate([0, 0, x_offset])
rotate([0, -90, 0])
shape();

It works by sampling a segment of the cylindrical surface by rotation,
projecting it flat and stitching the flat sections together. I can't
explain the *1.4 bodge, it is probably a bug in my logic or the fact that
they are not real cylinders.

On 26 December 2016 at 14:06, Parkinbot rudolf@parkinbot.com wrote:

runsun wrote

I supposed that at this stage, the coordinates of each points are already
known ?

Certainly, the 3D points are known e.g. from the STL. But common-edge
triags share two points. So each triag will be represented by a structure
like in C/C++

struct triag{
point3 x, y, z, n;
triag ** CE_neighbour;
}

while the topologic sets would be implemented as list (or some similar
container type) for easy (un-)hooking.

The definite implementation of course depends on the programming paradigma
you are using. It can be done in OpenSCAD, if you are willing to juggle
around with nested lists.

--
View this message in context: http://forum.openscad.org/
flattening-curved-surfaces-tp19727p19762.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

Here is an approximate solution for objects with cylindrical surfaces: le = 10; // length d1 = 25; // diameter of top d2 = 35; // diameter of bottom d3 = 30; // side cylinders d = -8; // delta to drop center of bottom $fn = 100; z_offset = -6; x_offset = 10; module shape() { translate([0, 0, z_offset]) intersection(c) { translate([x_offset, 0, 0]) cylinder(h = 100, d = d3); translate([-x_offset, 0, 0]) cylinder(h = 100, d = d3); difference() { rotate([0, 90, 0]) cylinder(h = le, d = d1, center = true); translate([0, 0, d]) rotate([0, 90, 0]) cylinder(h = le + 2, d = d2, center = true); } } } %translate([0, 0, 5]) render() shape(); module flatten_cylinder(diameter, width, angle = 180, steps = 30 ) { length = angle / 360 * PI * diameter; for(i = [-steps / 2 + 1 : steps / 2 - 1]) translate([0, i * length / steps, 0]) offset(0.0001) projection() // expand slighly so they overlap union() { intersection() { cube([width + 1, length / steps, diameter * (1 - cos(angle / (steps * 2))) * 1.4], center = true); translate([0, 0, -diameter / 2]) rotate([i * angle / steps, 0 , 0]) children(); } } } flatten_cylinder(d1, le) translate([0, 0, -z_offset]) shape(); translate([le + 1, 0]) flatten_cylinder(d2, le) translate([0, 0, -z_offset - d]) shape(); translate([2 * le - 3, 0]) flatten_cylinder(d3, 2 * le) translate([0, 0, x_offset]) rotate([0, 90, 0]) shape(); translate([-le + 3, 0]) flatten_cylinder(d3, 2 * le) translate([0, 0, x_offset]) rotate([0, -90, 0]) shape(); It works by sampling a segment of the cylindrical surface by rotation, projecting it flat and stitching the flat sections together. I can't explain the *1.4 bodge, it is probably a bug in my logic or the fact that they are not real cylinders. On 26 December 2016 at 14:06, Parkinbot <rudolf@parkinbot.com> wrote: > runsun wrote > > I supposed that at this stage, the coordinates of each points are already > > known ? > > Certainly, the 3D points are known e.g. from the STL. But *common-edge > triags* share two points. So each triag will be represented by a structure > like in C/C++ > > > struct triag{ > > point3 x, y, z, n; > > triag ** CE_neighbour; > > } > > while the topologic sets would be implemented as list (or some similar > container type) for easy (un-)hooking. > > The definite implementation of course depends on the programming paradigma > you are using. It can be done in OpenSCAD, if you are willing to juggle > around with nested lists. > > > > > -- > View this message in context: http://forum.openscad.org/ > flattening-curved-surfaces-tp19727p19762.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 >

P

Parkinbot

Mon, Dec 26, 2016 10:11 PM

nophead,
without access to the vertex representation, but to the full set of
construction parameters this looks viable. Nevertheless, it undoutedly is a
lot of hard work, that you will have to do at least for each new object
class.

The sketched algorithm is completely unaware to how the 3D-object was
created or is formed. It uses STL (AMF) data to separate the surfaces by use
of the threshold and builds on the assumption they can be unrolled.
There might be examples, where a practicable threshold can't be found for a
given design. But in most cases this can be solved by retrying with a
rendering with increased resolution.

What, if the assumption doesn't hold? Well, the result will be bad and the
generated 2D shape will be scattered somehow. In this case, I would advise
to review the original design, but one can also try to approximately unroll
an unrollable surface by applying some regression scheme.

Since Jon came up with this idea, I don't want to spoil his enjoyment and
dedication by presenting some code. So let's give him some time and wait for
his results.

--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19768.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

nophead, without access to the vertex representation, but to the full set of construction parameters this looks viable. Nevertheless, it undoutedly is a lot of hard work, that you will have to do at least for each new object class. The sketched algorithm is completely unaware to how the 3D-object was created or is formed. It uses STL (AMF) data to separate the surfaces by use of the threshold and builds on the assumption they can be unrolled. There might be examples, where a practicable threshold can't be found for a given design. But in most cases this can be solved by retrying with a rendering with increased resolution. What, if the assumption doesn't hold? Well, the result will be bad and the generated 2D shape will be scattered somehow. In this case, I would advise to review the original design, but one can also try to approximately unroll an unrollable surface by applying some regression scheme. Since Jon came up with this idea, I don't want to spoil his enjoyment and dedication by presenting some code. So let's give him some time and wait for his results. -- View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19768.html Sent from the OpenSCAD mailing list archive at Nabble.com.

J

jon

Mon, Dec 26, 2016 10:17 PM

LOL! Spoil his enjoyment!

It is written, but not working yet. My approach is to find triangles
that share a side, and then compute the angle between normals for those
two triangles. If the angle is small (the normals are roughly the same)
then I assume those two triangles are on a surface together. Once the
surfaces are identified, then I have to flatten them out. Still a ways
to go, but it seems feasible, and (as Parkinbot wrote) using an STL will
allow others to design surfaces to be flattened.

Just a start at the moment. Rolling all of my vector routines was not
difficult, but then again, it's not working yet, so I'm sure there are
many bugs to be found

:)

On 12/26/2016 5:11 PM, Parkinbot wrote:

nophead,
without access to the vertex representation, but to the full set of
construction parameters this looks viable. Nevertheless, it undoutedly is a
lot of hard work, that you will have to do at least for each new object
class.

The sketched algorithm is completely unaware to how the 3D-object was
created or is formed. It uses STL (AMF) data to separate the surfaces by use
of the threshold and builds on the assumption they can be unrolled.
There might be examples, where a practicable threshold can't be found for a
given design. But in most cases this can be solved by retrying with a
rendering with increased resolution.

What, if the assumption doesn't hold? Well, the result will be bad and the
generated 2D shape will be scattered somehow. In this case, I would advise
to review the original design, but one can also try to approximately unroll
an unrollable surface by applying some regression scheme.

Since Jon came up with this idea, I don't want to spoil his enjoyment and
dedication by presenting some code. So let's give him some time and wait for
his results.

--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19768.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

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7924 / Virus Database: 4739/13653 - Release Date: 12/26/16

LOL! Spoil his enjoyment! It is written, but not working yet. My approach is to find triangles that share a side, and then compute the angle between normals for those two triangles. If the angle is small (the normals are roughly the same) then I assume those two triangles are on a surface together. Once the surfaces are identified, then I have to flatten them out. Still a ways to go, but it seems feasible, and (as Parkinbot wrote) using an STL will allow others to design surfaces to be flattened. Just a start at the moment. Rolling all of my vector routines was not difficult, but then again, it's not working yet, so I'm sure there are many bugs to be found :) On 12/26/2016 5:11 PM, Parkinbot wrote: > nophead, > without access to the vertex representation, but to the full set of > construction parameters this looks viable. Nevertheless, it undoutedly is a > lot of hard work, that you will have to do at least for each new object > class. > > The sketched algorithm is completely unaware to how the 3D-object was > created or is formed. It uses STL (AMF) data to separate the surfaces by use > of the threshold and builds on the assumption they can be unrolled. > There might be examples, where a practicable threshold can't be found for a > given design. But in most cases this can be solved by retrying with a > rendering with increased resolution. > > What, if the assumption doesn't hold? Well, the result will be bad and the > generated 2D shape will be scattered somehow. In this case, I would advise > to review the original design, but one can also try to approximately unroll > an unrollable surface by applying some regression scheme. > > Since Jon came up with this idea, I don't want to spoil his enjoyment and > dedication by presenting some code. So let's give him some time and wait for > his results. > > > > > > -- > View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19768.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 > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2016.0.7924 / Virus Database: 4739/13653 - Release Date: 12/26/16 > >

P

Parkinbot

Mon, Dec 26, 2016 11:39 PM

Hey, it is your project. So don't be modest. Great idea!

jon_bondy wrote

My approach is to find triangles that share a side, and then compute the
angle between normals for those
two triangles.

You don't need to calc the angle. The dot product of two normalized vectors
is 0 when orthogonal, 1 when parallel and -1 when antiparallel. You want
them almost parallel. So you can use a value a bit less then 1 as threshold.

Hint: for every final surface unroll you can easily calculate a bounding
box, and optimize the arrangement of the result for output.

--
View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19770.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Hey, it is your project. So don't be modest. Great idea! jon_bondy wrote > My approach is to find triangles that share a side, and then compute the > angle between normals for those > two triangles. You don't need to calc the angle. The dot product of two normalized vectors is 0 when orthogonal, 1 when parallel and -1 when antiparallel. You want them almost parallel. So you can use a value a bit less then 1 as threshold. Hint: for every final surface unroll you can easily calculate a bounding box, and optimize the arrangement of the result for output. -- View this message in context: http://forum.openscad.org/flattening-curved-surfaces-tp19727p19770.html Sent from the OpenSCAD mailing list archive at Nabble.com.

MS

Mark Schafer

Tue, Dec 27, 2016 1:15 AM

great idea but consider making an edgelist and traversing that.
Two reasons:

an edge will have a face on either side and so the angle between faces
can be easily calculated and associated with the edge.
if you're going to preserve some edges (e.g. where you want a split to
occur), its handy to be able to group edges into lists

On 12/27/2016 11:17 AM, jon wrote:

LOL! Spoil his enjoyment!

It is written, but not working yet. My approach is to find triangles
that share a side, and then compute the angle between normals for
those two triangles. If the angle is small (the normals are roughly
the same) then I assume those two triangles are on a surface
together. Once the surfaces are identified, then I have to flatten
them out. Still a ways to go, but it seems feasible, and (as
Parkinbot wrote) using an STL will allow others to design surfaces to
be flattened.

Just a start at the moment. Rolling all of my vector routines was not
difficult, but then again, it's not working yet, so I'm sure there are
many bugs to be found

:)

On 12/26/2016 5:11 PM, Parkinbot wrote:

nophead,
without access to the vertex representation, but to the full set of
construction parameters this looks viable. Nevertheless, it
undoutedly is a
lot of hard work, that you will have to do at least for each new object
class.

The sketched algorithm is completely unaware to how the 3D-object was
created or is formed. It uses STL (AMF) data to separate the surfaces
by use
of the threshold and builds on the assumption they can be unrolled.
There might be examples, where a practicable threshold can't be found
for a
given design. But in most cases this can be solved by retrying with a
rendering with increased resolution.

What, if the assumption doesn't hold? Well, the result will be bad
and the
generated 2D shape will be scattered somehow. In this case, I would
advise
to review the original design, but one can also try to approximately
unroll
an unrollable surface by applying some regression scheme.

Since Jon came up with this idea, I don't want to spoil his enjoyment
and
dedication by presenting some code. So let's give him some time and
wait for
his results.

great idea but consider making an edgelist and traversing that. Two reasons: - an edge will have a face on either side and so the angle between faces can be easily calculated and associated with the edge. - if you're going to preserve some edges (e.g. where you want a split to occur), its handy to be able to group edges into lists On 12/27/2016 11:17 AM, jon wrote: > LOL! Spoil his enjoyment! > > It is written, but not working yet. My approach is to find triangles > that share a side, and then compute the angle between normals for > those two triangles. If the angle is small (the normals are roughly > the same) then I assume those two triangles are on a surface > together. Once the surfaces are identified, then I have to flatten > them out. Still a ways to go, but it seems feasible, and (as > Parkinbot wrote) using an STL will allow others to design surfaces to > be flattened. > > Just a start at the moment. Rolling all of my vector routines was not > difficult, but then again, it's not working yet, so I'm sure there are > many bugs to be found > > :) > > > On 12/26/2016 5:11 PM, Parkinbot wrote: >> nophead, >> without access to the vertex representation, but to the full set of >> construction parameters this looks viable. Nevertheless, it >> undoutedly is a >> lot of hard work, that you will have to do at least for each new object >> class. >> >> The sketched algorithm is completely unaware to how the 3D-object was >> created or is formed. It uses STL (AMF) data to separate the surfaces >> by use >> of the threshold and builds on the assumption they can be unrolled. >> There might be examples, where a practicable threshold can't be found >> for a >> given design. But in most cases this can be solved by retrying with a >> rendering with increased resolution. >> >> What, if the assumption doesn't hold? Well, the result will be bad >> and the >> generated 2D shape will be scattered somehow. In this case, I would >> advise >> to review the original design, but one can also try to approximately >> unroll >> an unrollable surface by applying some regression scheme. >> >> Since Jon came up with this idea, I don't want to spoil his enjoyment >> and >> dedication by presenting some code. So let's give him some time and >> wait for >> his results. >> >> >>

J

jon

Tue, Dec 27, 2016 1:44 AM

I am not sure that I see the utility in knowing the edges if I'm trying
to create a surface. If I get in trouble with my current approach, I
will check back with y'all

On 12/26/2016 8:15 PM, Mark Schafer wrote:

great idea but consider making an edgelist and traversing that.
Two reasons:

an edge will have a face on either side and so the angle between
faces can be easily calculated and associated with the edge.
if you're going to preserve some edges (e.g. where you want a split
to occur), its handy to be able to group edges into lists

I am not sure that I see the utility in knowing the edges if I'm trying to create a surface. If I get in trouble with my current approach, I will check back with y'all On 12/26/2016 8:15 PM, Mark Schafer wrote: > great idea but consider making an edgelist and traversing that. > Two reasons: > - an edge will have a face on either side and so the angle between > faces can be easily calculated and associated with the edge. > - if you're going to preserve some edges (e.g. where you want a split > to occur), its handy to be able to group edges into lists >

R

runsun

Tue, Dec 27, 2016 5:30 PM

Parkinbot wrote

Certainly, the 3D points are known e.g. from the STL. But common-edge
triags share two points. ...

What I have in mind is that, if the points are known, we should be able to
calc the angles and relative position between points, then copy them onto a
flat surface. That is, no triagulation/hooking/unhooking is needed.

Certainly, this is under the circumstance that we know the shape and be able
to visualize neighboring points before proceeding. I guess you are looking
for a more general approach in which we just throw in points (w/o seeing the
shape) and let the program decides the neighboring points of each point.

$ 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-tp19727p19779.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Parkinbot wrote > Certainly, the 3D points are known e.g. from the STL. But *common-edge > triags* share two points. ... What I have in mind is that, if the points are known, we should be able to calc the angles and relative position between points, then copy them onto a flat surface. That is, no triagulation/hooking/unhooking is needed. Certainly, this is under the circumstance that we know the shape and be able to visualize neighboring points before proceeding. I guess you are looking for a more general approach in which we just throw in points (w/o seeing the shape) and let the program decides the neighboring points of each point. ----- $ 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-tp19727p19779.html Sent from the OpenSCAD mailing list archive at Nabble.com.

discuss@lists.openscad.org

flattening curved surfaces