The dark art of non affine transformations part III, solution to: http://forum.openscad.org/Wave-spring-tp14948.html Cheers, Trygon PS for documentation on function fa() see http://forum.openscad.org/fe-Tolerance-based-arc-approximation-tp14212.html // Trygon Dec2015 - non affine transformation: washer -> spring washer $fe=0.01; ro=10; // outside radius ri=5; // hole radius h=1; // washer thickness hw=2; // wave height nw=3; // number of waves washer=WasherObject(ro,ri,h); polyhedron(TransformPoints(washer[0],hw,nw),washer[1]); function WasherObject(ro,ri,h) = let( n=ceil(360/fa(ro)), // number of segments p0=[for(i=[0:n-1]) let(a=i*360/n) [ro*cos(a),ro*sin(a),h/2]], p1=[for(i=p0) [i[0]*ri/ro,i[1]*ri/ro,i[2]]], p2=[for(i=p0) [i[0],i[1],-h/2]], p3=[for(i=p1) [i[0],i[1],-h/2]]) [concat(p0,p1,p2,p3), // vertices Unpack([for(i=[0:n-1]) let(j=(i+1)%n) [ // triangles [i,j,j+n],[i,j+n,i+n], [i+2*n,j+3*n,j+2*n],[i+2*n,i+3*n,j+3*n], [i+2*n,j+2*n,j],[i+2*n,j,i], [i+3*n,j+n,j+3*n],[i+3*n,i+n,j+n] ]])]; function TransformPoints(p,hw,nw) = [for(i=p) WaveTransform(i,hw,nw)]; function WaveTransform(v,hw,nw) = let(x=v[0],y=v[1],z=v[2]) [x,y,z+hw*sin(nw*atan2(x,y))/2]; function Unpack(p) = [for(i=p) for(j=i) j]; function fa(r)=$fn>0?360/($fn>3?$fn:3): $fe>0?$fe<r?min(45,2*acos(1-$fe/r)):45: 360/max(min(360/($fa>0.01?$fa:0.01), 2*PI*r/($fs>0.01?$fs:0.01)),5); -- View this message in context: http://forum.openscad.org/Non-Linear-Transformations-tp14539p14991.html Sent from the OpenSCAD mailing list archive at Nabble.com.

Sorry, I just realised that I had the triangles inverted (points anticlockwise rather than clockwise). I have corrected the original post. Thanks, Trygon -- View this message in context: http://forum.openscad.org/Non-Linear-Transformations-tp14539p14996.html Sent from the OpenSCAD mailing list archive at Nabble.com.

Trygon wrote > OpenSCAD currently supports a whole range of specific * > linear * > transformations such as translate(), rotate() and scale(), in addition to > the generic * > linear * > transformation multmatrix(). > > OpenSCAD does not provide support for non- * > linear * > transformations. Both statements are false. OpenSCAD currently provides both linear transformations (x->a+bx, with a and b constants) and non-linear transformations (for example: translate([sin20,cos(30),tan(10)]) is perfectly legal, though not necessarily meaningful. Rotations are inherently non-linear transformations, as they involve sines and cosines). Instead of *linear*, Trygon should have used the term *affine* to describe current OpenSCAD's capabilities. But doing so has consequences: Since one of the properties of an affine transformation is that straight lines are transformed into other straight lines, this implies that as long as OpenSCAD wants to output .stl files, it cannot support non-affine transformations. After all, a .stl file is nothing but a [structured] list of vertices, which are connected by straight lines, and not curved ones as is inevitable for non-affine transformations. BTW, doug.moen's algorithm does not have any value either. This is because when, say, a square is subjected to an affine transformation, it must remain a quadrangle (i.e. its vertex count remains unchanged), and it must remain flat. That is part and parcel of an affine transformation. Thus there is no need to create extra vertices. Finally, the outcome of the multiplication of one or several vector(s) with a matrix (that is what multmatrix() is) need not be restricted to affine transformations. Some OpenSCAD shapes allow a twist parameter - the restriction arises out of the need to produce .stl files. Twist is the implemented as a succession of skew transformations. wolf -- View this message in context: http://forum.openscad.org/Non-Linear-Transformations-tp14539p16578.html Sent from the OpenSCAD mailing list archive at Nabble.com.

On 19. mars 2016 08:53, wolf wrote: > After all, a .stl file is nothing but a [structured] list of vertices, which > are connected by straight lines, This is somewhat misleading. STL files do not contain a lists of vertices. STL files contain only a set of topologically disconnected triangles with coordinates duplicated locally in every triangle. Every would-be vertex has to be mentioned at least 3 times. This is one of the reasons why why STL is an unfortunate standard. Your description applies better to an AMF file or generally a polyhedron mesh with a structured vector of vertices and where faces are defined via indices into the vertex vector. This is much better as it removes the possibility of ambiguities. > Finally, the outcome of the multiplication of one or several vector(s) with > a matrix (that is what multmatrix() is) need not be restricted to affine > transformations. Every transformation in OpenSCAD and most similar systems is eventually expressed a 4x4 homogeneous coordinate transformation matrix, multmatrix() is just the explicit form of that in OpenSCAD. Although such matrices can express things like perspective, in CAD geometry it is most commonly used to express just translation, scaling, mirroring and rotation. Straight lines are preserved for these, but the curvature of arcs can be affected by scaling. Carsten Arnholm

OpenSCAD supports affine transformations via multmatrix, but it does not support the more general class of projective transformations (which includes the perspective transformation), even though these can also be represented by 4x4 matrixes. I've looked at a number of solid modelling languages, in addition to OpenSCAD, and the only one I've found that supports generalized projective transformations is SGDL. SGDL is based on projective geometry, which is a generalization of Euclidean geometry that includes points at infinity. In SGDL, 3-space coordinates are always represented as homogenous coordinates: [x,y,z,w], where the point is at infinity if w==0. SGDL also supports infinitely large solids. I'm not an expert on projective geometry, but I think the problem with supporting general projective transformations in a Euclidean geometry system like OpenSCAD is just that a projective transformation can map a vertex to a point at infinity, and we have no way to deal with that in our representation. Does anybody on the list have a better understanding of this? What are all the things that would go wrong if we tried to extend multmatrix to support projective transformations? On 19 March 2016 at 03:53, wolf <wv99999@gmail.com> wrote: > Trygon wrote > > OpenSCAD currently supports a whole range of specific > * > > linear > * > > transformations such as translate(), rotate() and scale(), in addition > to > > the generic > * > > linear > * > > transformation multmatrix(). > > > > OpenSCAD does not provide support for non- > * > > linear > * > > transformations. > > Both statements are false. OpenSCAD currently provides both linear > transformations (x->a+bx, with a and b constants) and non-linear > transformations (for example: translate([sin20,cos(30),tan(10)]) is > perfectly legal, though not necessarily meaningful. Rotations are > inherently > non-linear transformations, as they involve sines and cosines). Instead of > *linear*, Trygon should have used the term *affine* to describe current > OpenSCAD's capabilities. > But doing so has consequences: Since one of the properties of an affine > transformation is that straight lines are transformed into other straight > lines, this implies that as long as OpenSCAD wants to output .stl files, it > cannot support non-affine transformations. > After all, a .stl file is nothing but a [structured] list of vertices, > which > are connected by straight lines, and not curved ones as is inevitable for > non-affine transformations. > > BTW, doug.moen's algorithm does not have any value either. This is because > when, say, a square is subjected to an affine transformation, it must > remain > a quadrangle (i.e. its vertex count remains unchanged), and it must remain > flat. That is part and parcel of an affine transformation. Thus there is no > need to create extra vertices. > > Finally, the outcome of the multiplication of one or several vector(s) with > a matrix (that is what multmatrix() is) need not be restricted to affine > transformations. Some OpenSCAD shapes allow a twist parameter - the > restriction arises out of the need to produce .stl files. Twist is the > implemented as a succession of skew transformations. > > wolf > > > > > -- > View this message in context: > http://forum.openscad.org/Non-Linear-Transformations-tp14539p16578.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 > > >

Roger. 

On Sat, Mar 19, 2016 at 11:46:10AM -0400, doug moen wrote: > OpenSCAD supports affine transformations via multmatrix, but it does not > support the more general class of projective transformations (which > includes the perspective transformation), even though these can also be > represented by 4x4 matrixes. > > I've looked at a number of solid modelling languages, in addition to > OpenSCAD, and the only one I've found that supports generalized projective > transformations is SGDL. SGDL is based on projective geometry, which is a > generalization of Euclidean geometry that includes points at infinity. In > SGDL, 3-space coordinates are always represented as homogenous coordinates: > [x,y,z,w], where the point is at infinity if w==0. SGDL also supports > infinitely large solids. I took "computer graphics" at caltech from Prof. Jim Blinn in 1985.... He is a big proponent of this way of working. Points in three-space are represented by [x, y, z, 1]. A projection (in 4-space) towards the origin on the w=1 plane (ehh solid) happens when you divide by w to "come back to 3-space". This also means you can do 3D->2D projections. Because you start with w=1, you have a constant that you can add to xyz, to perform translations. Everything is linear, so for example a rotation followed by a translation can be done in one step by multiplying their matrices. How all this applies to openscad, I don't know. I have too little familiarity with the openscad internals. Roger. -- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 ** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work.

When I researched, and made, my previous comment, I allowed myself to be guided by conservation laws. Conservation laws are very powerful constructs, as they tell you what you need not to bother with when planning a change, and as such reduce the complexity of your task. They also permit you to freely change the direction of your reasoning, going about designing first the roof of your house or the foundations, or even the place where the computer sits on which you do OpenSCAD. The result will always be the same, but the traps you fall into when you do your planning will differ. OpenSCAD's output is not a value in itself, but rather a tool to access the capabilities of other tools, such as a 3D printer or a laser cutter. Thus, it makes sense to start from the end, from the limitations that a .stl file output places on OpenSCAD's internals. If you open up the .stl of cube([1,1,1]) in a text editor, you get, after the removal of some spaces and <newlines> (and sorting on the facet normal, just to make the internal structure clearer), this table: solid OpenSCAD_Model facet normal -1 0 0 outer loop vertex 0 1 1 vertex 0 0 0 vertex 0 0 0 endloop endfacet facet normal -1 0 0 outer loop vertex 0 0 0 vertex 0 1 1 vertex 0 1 1 endloop endfacet facet normal 0 -1 0 outer loop vertex 1 0 1 vertex 0 0 0 vertex 0 0 0 endloop endfacet facet normal 0 -1 0 outer loop vertex 0 0 0 vertex 1 0 1 vertex 1 0 1 endloop endfacet facet normal 0 0 -1 outer loop vertex 1 1 0 vertex 0 0 0 vertex 0 0 0 endloop endfacet facet normal 0 0 -1 outer loop vertex 0 0 0 vertex 1 1 0 vertex 1 1 0 endloop endfacet facet normal 0 0 1 outer loop vertex 1 0 1 vertex 0 1 1 vertex 0 1 1 endloop endfacet facet normal 0 0 1 outer loop vertex 0 1 1 vertex 1 0 1 vertex 1 0 1 endloop endfacet facet normal 0 1 0 outer loop vertex 1 1 0 vertex 0 1 1 vertex 0 1 1 endloop endfacet facet normal 0 1 0 outer loop vertex 0 1 1 vertex 1 1 0 vertex 1 1 0 endloop endfacet facet normal 1 0 0 outer loop vertex 1 1 0 vertex 1 0 1 vertex 1 0 1 endloop endfacet facet normal 1 0 0 outer loop vertex 1 0 1 vertex 1 1 0 vertex 1 1 0 endloop endfacet endsolid OpenSCAD_Model Unlike what Wikipedia https://en.wikipedia.org/wiki/STL_%28file_format%29 makes me expect, there are twice as many facets listed as a cube has faces, and each facet points only to two vertices. I haven't investigated so far whether this is due to an OpenSCAD bug or inappropriate Wikipedia information. As to the question on the usefulness of projective geometry extensions to OpenSCAD, I fail to see the usefulness of it. Yes, the display looks nicer, and you can easily program tapers, but how often is that used? So my vote is against it, as is my vote against extensions to multmatrix(). Here I would rather follow the philosophy projected with OpenSCAD2: simpler is better, and deprecate multmatrix(), because it requires so much background in mathematics to use it effectively. The useful portions of multmatrix() have already been extracted into other transformations, as this program segment shows: TranslatMatrix= [ [1, 0, 0, 10], [0, 1, 0, 20], [0, 0, 1, 30], [0, 0, 0, 1] ]; ScaleMatrix= [ [1, 0, 0, 0], [0, 1/2, 0, 0], [0, 0, 1/3, 0], [0, 0, 0, 1] ]; Rotate_Around_X=[ [1, 0, 0, 0], //source: https://en.wikipedia.org/wiki/Rotation_formalisms_in_three_dimensions [0, cos(30), -sin(30), 0], [0, sin(30), cos(30), 0], [0, 0, 0, 1] ]; Rotate_Around_Y=[ [cos(30), 0, sin(30), 0], [ 0, 1, 0, 0], [-sin(30), 0,cos(30), 0], [0, 0, 0, 1] ]; Rotate_Around_Z=[ [cos(30), -sin(30), 0, 0], [sin(30), cos(30), 0, 0], [0, 0, 1, 0], [0, 0, 0, 1] ]; //SkewMatrix= // source: https://en.wikipedia.org/wiki/Rotation_matrix#Skew_parameters_via_Cayley.27s_formula // https://en.wikipedia.org/wiki/Cayley_transform // https://en.wikipedia.org/wiki/Skew-symmetric_matrix //T_Simple(); //T_mult(); //S_Simple(); //S_mult(); //R_X_Simple(); //R_X_mult(); //R_Y_mult(); R_Z_mult(); module T_Simple() //this is one way of doing a translation translate([10,20,30]) cube([10,20,30]); module T_mult() //this is another way of doing the same translation multmatrix(m = TranslatMatrix) cube([10,20,1/3]); module S_Simple() //this is one way of doing scaling scale([1,1/2,1/3]) cube([10,20,30]); module S_mult() //this is another way of doing the same scaling multmatrix(m = ScaleMatrix) cube([10,20,30]); module R_X_Simple() //this is one way of doing a rotation around the x axis rotate(30,[1,0,0]) cube([10,20,30]); module R_X_mult() //this is another way of doing the same rotation around the x axis multmatrix(m = Rotate_Around_X) cube([10,20,30]); module R_Y_mult() //this is a rotation around the y axis multmatrix(m = Rotate_Around_Y) cube([10,20,30]); module R_Z_mult() //this is a rotation around the z axis multmatrix(m = Rotate_Around_Z) cube([10,20,30]); As far as I know, skew or shear transformations currently require the use of multmatrix(), but then who uses them? Because Marius Kintel asked for them, I outline here another transformation: offset. $fn=50; Diameter=2; // diameter of sphere from which ellipsoid is created Offset=0.1*Diameter; MaxDim=[3*Diameter,1*Diameter,.5*Diameter]; // long axes of ellipsoid MakeOffset(); MakeCutout(); TestPosition(); module MakeOffset() scale([1-2*Offset/MaxDim[0],1-2*Offset/MaxDim[1],1-2*Offset/MaxDim[2]]) // for a true offset, MaxDim[...] needs to be replaced with the norm of each vertex for the ellipsoid Ellipsoid(); module TestPosition() translate([MaxDim[0]/2-Offset/2,0,0]) sphere(d=Offset); translate([0,-(MaxDim[1]/2-Offset/2),0]) sphere(d=Offset); translate([0,0,MaxDim[2]/2-Offset/2]) sphere(d=Offset); module MakeCutout() difference() { Ellipsoid(); translate([0,-15,15]) cube([70,30,30], center=true); } module Ellipsoid() scale([MaxDim[0]/Diameter,MaxDim[1]/Diameter,MaxDim[2]/Diameter]) sphere(d=Diameter); It doesn't quite work in userspace, but comes pretty close. One line, as commented, needs access to the vertex vectors, which OpenSCAD does not readily provide. Work for someone with knowledge of the internals. <http://forum.openscad.org/file/n16588/Offset.jpg> The yellow color in the cutout indicates a problem OpenSCAD has with the faces created by module MakeCutout(). Probably inside-out faces. They were made with version 2015.03-1. wolf -- View this message in context: http://forum.openscad.org/Non-Linear-Transformations-tp14539p16588.html Sent from the OpenSCAD mailing list archive at Nabble.com.

Wolf said: "Unlike what Wikipedia https://en.wikipedia.org/wiki/STL_%28file_format%29 makes me expect, there are twice as many facets listed as a cube has faces, and each facet points only to two vertices. I haven't investigated so far whether this is due to an OpenSCAD bug or inappropriate Wikipedia information." The Wikipedia article is correct and this is not an OpenSCAD bug. An STL file contains a list of triangles, each of which has 3 vertices. A cube has 6 square faces, and each square must be split into 2 triangles in order to be represented by STL. So that's 6 * 2 = 12 triangles. The wikipedia article addresses your point of confusing by stating this:"The structure of the format suggests that other possibilities exist (e.g., facets with more than one "loop", or loops with more than three vertices). In practice, however, all facets are simple triangles." On 19 March 2016 at 22:22, wolf <wv99999@gmail.com> wrote: > When I researched, and made, my previous comment, I allowed myself to be > guided by conservation laws. Conservation laws are very powerful > constructs, > as they tell you what you need not to bother with when planning a change, > and as such reduce the complexity of your task. They also permit you to > freely change the direction of your reasoning, going about designing first > the roof of your house or the foundations, or even the place where the > computer sits on which you do OpenSCAD. The result will always be the same, > but the traps you fall into when you do your planning will differ. > OpenSCAD's output is not a value in itself, but rather a tool to access the > capabilities of other tools, such as a 3D printer or a laser cutter. Thus, > it makes sense to start from the end, from the limitations that a .stl file > output places on OpenSCAD's internals. > If you open up the .stl of cube([1,1,1]) in a text editor, you get, after > the removal of some spaces and <newlines> (and sorting on the facet normal, > just to make the internal structure clearer), this table: > > solid OpenSCAD_Model > facet normal -1 0 0 outer loop vertex 0 1 1 vertex 0 0 0 vertex > 0 0 0 endloop endfacet > facet normal -1 0 0 outer loop vertex 0 0 0 vertex 0 1 1 vertex > 0 1 1 endloop endfacet > facet normal 0 -1 0 outer loop vertex 1 0 1 vertex 0 0 0 vertex > 0 0 0 endloop endfacet > facet normal 0 -1 0 outer loop vertex 0 0 0 vertex 1 0 1 vertex > 1 0 1 endloop endfacet > facet normal 0 0 -1 outer loop vertex 1 1 0 vertex 0 0 0 vertex > 0 0 0 endloop endfacet > facet normal 0 0 -1 outer loop vertex 0 0 0 vertex 1 1 0 vertex > 1 1 0 endloop endfacet > facet normal 0 0 1 outer loop vertex 1 0 1 vertex 0 1 1 vertex > 0 1 1 endloop endfacet > facet normal 0 0 1 outer loop vertex 0 1 1 vertex 1 0 1 vertex > 1 0 1 endloop endfacet > facet normal 0 1 0 outer loop vertex 1 1 0 vertex 0 1 1 vertex > 0 1 1 endloop endfacet > facet normal 0 1 0 outer loop vertex 0 1 1 vertex 1 1 0 vertex > 1 1 0 endloop endfacet > facet normal 1 0 0 outer loop vertex 1 1 0 vertex 1 0 1 vertex > 1 0 1 endloop endfacet > facet normal 1 0 0 outer loop vertex 1 0 1 vertex 1 1 0 vertex > 1 1 0 endloop endfacet > endsolid OpenSCAD_Model > > Unlike what Wikipedia https://en.wikipedia.org/wiki/STL_%28file_format%29 > makes me expect, there are twice as many facets listed as a cube has faces, > and each facet points only to two vertices. I haven't investigated so far > whether this is due to an OpenSCAD bug or inappropriate Wikipedia > information. > > As to the question on the usefulness of projective geometry extensions to > OpenSCAD, I fail to see the usefulness of it. Yes, the display looks nicer, > and you can easily program tapers, but how often is that used? So my vote > is > against it, as is my vote against extensions to multmatrix(). Here I would > rather follow the philosophy projected with OpenSCAD2: simpler is better, > and deprecate multmatrix(), because it requires so much background in > mathematics to use it effectively. The useful portions of multmatrix() have > already been extracted into other transformations, as this program segment > shows: > > TranslatMatrix= [ [1, 0, 0, 10], > [0, 1, 0, 20], > [0, 0, 1, 30], > [0, 0, 0, 1] > ]; > ScaleMatrix= [ [1, 0, 0, 0], > [0, 1/2, 0, 0], > [0, 0, 1/3, 0], > [0, 0, 0, 1] > ]; > Rotate_Around_X=[ [1, 0, 0, 0], //source: > https://en.wikipedia.org/wiki/Rotation_formalisms_in_three_dimensions > [0, cos(30), -sin(30), 0], > [0, sin(30), cos(30), 0], > [0, 0, 0, 1] > ]; > Rotate_Around_Y=[ [cos(30), 0, sin(30), 0], > [ 0, 1, 0, 0], > [-sin(30), 0,cos(30), 0], > [0, 0, 0, 1] > ]; > Rotate_Around_Z=[ [cos(30), -sin(30), 0, 0], > [sin(30), cos(30), 0, 0], > [0, 0, 1, 0], > [0, 0, 0, 1] > ]; > //SkewMatrix= // source: > > https://en.wikipedia.org/wiki/Rotation_matrix#Skew_parameters_via_Cayley.27s_formula > // https://en.wikipedia.org/wiki/Cayley_transform > // https://en.wikipedia.org/wiki/Skew-symmetric_matrix > > //T_Simple(); > //T_mult(); > //S_Simple(); > //S_mult(); > //R_X_Simple(); > //R_X_mult(); > //R_Y_mult(); > R_Z_mult(); > > > module T_Simple() //this is one way of doing a translation > translate([10,20,30]) > cube([10,20,30]); > module T_mult() //this is another way of doing the same translation > multmatrix(m = TranslatMatrix) > cube([10,20,1/3]); > module S_Simple() //this is one way of doing scaling > scale([1,1/2,1/3]) > cube([10,20,30]); > module S_mult() //this is another way of doing the same scaling > multmatrix(m = ScaleMatrix) > cube([10,20,30]); > module R_X_Simple() //this is one way of doing a rotation around the x > axis > rotate(30,[1,0,0]) > cube([10,20,30]); > module R_X_mult() //this is another way of doing the same rotation > around > the x axis > multmatrix(m = Rotate_Around_X) > cube([10,20,30]); > module R_Y_mult() //this is a rotation around the y axis > multmatrix(m = Rotate_Around_Y) > cube([10,20,30]); > module R_Z_mult() //this is a rotation around the z axis > multmatrix(m = Rotate_Around_Z) > cube([10,20,30]); > > As far as I know, skew or shear transformations currently require the use > of > multmatrix(), but then who uses them? > Because Marius Kintel asked for them, I outline here another > transformation: > offset. > > $fn=50; > Diameter=2; // diameter of sphere from which ellipsoid is created > Offset=0.1*Diameter; > MaxDim=[3*Diameter,1*Diameter,.5*Diameter]; // long axes of ellipsoid > > MakeOffset(); > MakeCutout(); > TestPosition(); > > module MakeOffset() > scale([1-2*Offset/MaxDim[0],1-2*Offset/MaxDim[1],1-2*Offset/MaxDim[2]]) > // for a true offset, MaxDim[...] needs to be replaced with the norm of > each > vertex for the ellipsoid > Ellipsoid(); > module TestPosition() > translate([MaxDim[0]/2-Offset/2,0,0]) sphere(d=Offset); > translate([0,-(MaxDim[1]/2-Offset/2),0]) sphere(d=Offset); > translate([0,0,MaxDim[2]/2-Offset/2]) sphere(d=Offset); > module MakeCutout() > difference() > { Ellipsoid(); > translate([0,-15,15]) cube([70,30,30], center=true); > } > module Ellipsoid() > scale([MaxDim[0]/Diameter,MaxDim[1]/Diameter,MaxDim[2]/Diameter]) > sphere(d=Diameter); > > It doesn't quite work in userspace, but comes pretty close. One line, as > commented, needs access to the vertex vectors, which OpenSCAD does not > readily provide. Work for someone with knowledge of the internals. > <http://forum.openscad.org/file/n16588/Offset.jpg> > The yellow color in the cutout indicates a problem OpenSCAD has with the > faces created by module MakeCutout(). Probably inside-out faces. They were > made with version 2015.03-1. > > wolf > > > > > -- > View this message in context: > http://forum.openscad.org/Non-Linear-Transformations-tp14539p16588.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 > > >

> On Mar 19, 2016, at 11:46 AM, doug moen <doug@moens.org> wrote: > > Does anybody on the list have a better understanding of this? What are all the things that would go wrong if we tried to extend multmatrix to support projective transformations? > From the top of my head, I don’t think much can go wrong. It’s still just a linear transformation. Mapping to infinity is only possible through a division by zero when normalizing the resulting homogeneous coordinate, right? ..so that’s roughly similar to having inf values in an affine transformation matrix. Practically, we’re limited to affine transformation since that’s all CGAL supports for Nef polyhedrons. -Marius

A projection may be described by a multmatrix using a zero scale factor for one dimension. So everything is fine. As Kintel says: CGAL is restricted to affine transformations, so more general non-linear transformations can't be offered as long as this restriction holds. Well, linear_extrude() is not a transformation, rather a constructor. As such it touches just the tip of the iceberg of what would be possible in OpenSCAD, without even touching multmatrix. As Wolf wrote "Twist is implemented as a succession of skew transformations." This is the door. Earlier in this thread I've already opted for a nonlinear_extrude() or let's say an "enhanced linear_extrude()" primitive that offers a *richer prototype*. A first step would be to also allow for negative height values - linear_extrude is not 'linear' in this point. That maybe already on the todo list. A second (eady) one would be to allow to specify a vector along which extrusion occurs. But of course much more is possible between linear_extrude() and sweep() without leaving the land of affine operations. While sweep(), depending on its implemetation, more or less expects an explicit description of each frame, also more implicit path and operation descriptions would be possible. E.g. extrusion could follow (well-defaulted) path vectors, scale vectors and even orientation (rotation) vectors. >From the other side, also rotate_extrude() could be enriched to allow for a height argument (definition of screws) or a given height path (scews with nonlinear slopes). Once function arguments are possible xxx_extrude anyway should be prepared to work with them. - Rudolf - -- View this message in context: http://forum.openscad.org/Non-Linear-Transformations-tp14539p16656.html Sent from the OpenSCAD mailing list archive at Nabble.com.