Non-Linear Transformations
ctchin said:
For non-linear or more precisely non-affine transformation to
work the way you imagine it, will require re-meshing the children
with some level of smartly selected resolution. Which spells...
no universally acceptable algorithm exists.
I just described (in a vague way) a smart re-meshing algorithm in a
previous post. I'd like to hear why my algorithm might not be acceptable.
Here it is again, in more detail. Let's assume the polyhedron mesh is made
of triangles. For each triangle, we transform the vertexes. Then, we
perform a trial subdivision of the triangle into 4 smaller triangles, by
bisecting each of the original edges. This adds 3 new vertexes. We
transform each vertex, and compute the height of the vertex above the
parent triangle, in the direction of the parent triangle's normal vector. A
height of 0 means the new vertex lies in the plane of the parent triangle.
If all of the 3 new vertexes have a height of < $fe, then we discard the
new vertexes. Otherwise, we keep the new vertexes, and iterate, subdividing
the newly created triangles.
Doug.
On 16 November 2015 at 13:35, ctchin c.t.chin@szu.edu.cn wrote:
The more I read the more I understand the request, the more
I'm convinced there's a lot loony ideas being thrown around.
The syntax x(), whether it's built-in or not, is a function call
with no input parameters (adopting the default values if possible).
For non-linear or more precisely non-affine transformation to
work the way you imagine it, will require re-meshing the children
with some level of smartly selected resolution. Which spells...
no universally acceptable algorithm exists.
If it doesn't work sensibly on a cube() primitive, it's highly
questionable it ought to be added to OpenSCAD.
--
View this message in context:
http://forum.openscad.org/Non-Linear-Transformations-tp14539p14553.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
You are perfectly right!
Anyway only ismorphic nonlinear transformations would make sense. Most of
them are not isomorphic in a general sense - but might be in a subset, as
the given examples.
A more general approach for this feature would be to get hands on the mesh
points, as requested in my topic "feature request: obj2vec(); bug report:
freeze on standby recovery (Windows)". Then, everyone is free to use his own
mappings even non-isomorphic ones and also responsible if the resulting
polyhedron will be malformed.
If it doesn't work sensibly on a cube() primitive, it's highly
questionable it ought to be added to OpenSCAD.
--
View this message in context: http://forum.openscad.org/Non-Linear-Transformations-tp14539p14565.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Parkinbot, could you explain your comment "Anyway only ismorphic nonlinear
transformations would make sense." What will go wrong if a non-isomorphic
transformation is specified?
Isomorphic means that the structure of the geometric object is preserved,
in the sense that there is a reverse transformation that takes the
transformed object back to the original.
I can imagine evil transformations that result in a non-manifold object, or
which cause my smart-remeshing algorithm to go into an infinite loop. I
think we'd want error checking to detect these situations and report an
error.
I'm not sure how to prove that all non-isomorphic transformations are evil.
My math is not as strong as some of the other people on this list. But you
seem to know this as a fact, so how do you know?
On 16 November 2015 at 14:27, Parkinbot rudolf@parkinbot.com wrote:
You are perfectly right!
Anyway only ismorphic nonlinear transformations would make sense. Most of
them are not isomorphic in a general sense - but might be in a subset, as
the given examples.
A more general approach for this feature would be to get hands on the mesh
points, as requested in my topic "feature request: obj2vec(); bug report:
freeze on standby recovery (Windows)". Then, everyone is free to use his
own
mappings even non-isomorphic ones and also responsible if the resulting
polyhedron will be malformed.
If it doesn't work sensibly on a cube() primitive, it's highly
questionable it ought to be added to OpenSCAD.
--
View this message in context:
http://forum.openscad.org/Non-Linear-Transformations-tp14539p14565.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
Well, a non-isomorphic map in R³->R³ will have singularities (points, lines
or planes) in the sense that more than one points will be mapped to the same
point - so no inverse map can be found. As bijectivity is lost, vertices and
triangles simply might get lost.
Restricting a non-isomorphic map to a region (partial isomorphism), say to
the unit cube, it might be locally isomorphic as long as the region does not
contain any fix points.
So if we have a (partial) isomorphism all points (of a region) will be
mapped to separate image points and no merging can occur (numerically yes,
which is still another severe problem). Also triangle orientation will be
mapped in the same sense, as a partial flip of orientation of a triangle
would need a singularity for separation.
But you are right. Proving that a map is a (partial) isomorphism will only
be a first step. Even then, non-intersecting triangles might intersect after
being mapped (think of simply mapping one axis to a vortex like the
Archimedian spiral), and demand some careful post processing.
To sum it up: Non-linear operations have many pitfalls.
I guess one could allow for some of them in very specific contexts, like
with extrusion operations. For linear_extrusion() instead of linear scaling
and twisting one could think of nonlinear stepping or allow for a vector
expressing an ordered list of values, which will be used as z-heights, while
scaling and twisting will be done in a linear fashion with equidistant
stepping as it is done now.
--
View this message in context: http://forum.openscad.org/Non-Linear-Transformations-tp14539p14578.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
@ctchin you said, "conic: I believe it's actually linear and doable with a
simple multmatrix()", with regard to:
transform(xz/20 ,yz/20 ,z)
This transformation would be really useful for a model that I am scripting
at present, I couldn't work out how to do it with multmatrix(), please could
you provide the affine transformation matrix to use.
Thanks,
Trygon
--
View this message in context: http://forum.openscad.org/Non-Linear-Transformations-tp14539p14579.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
@Doug - This remeshing algorithm was designed specifically for this exact
purpose and worked very well at the time. (1992). May be worth a read:
--
View this message in context: http://forum.openscad.org/Non-Linear-Transformations-tp14539p14581.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Hi Trygon. Wikipedia uses the term "perspective transformation" for what
you call a conic transformation.
I tried using the perspective transformation matrix from wikipedia in
OpenSCAD and it didn't work, I got a run-time error. Don't remember the
details, it was a while ago. At the time, I concluded that we don't support
arbitrary affine transformations.
If someone has working code, I'd like to see it.
On 16 November 2015 at 16:37, Trygon db5765@outlook.com wrote:
@ctchin you said, "conic: I believe it's actually linear and doable with a
simple multmatrix()", with regard to:
transform(xz/20 ,yz/20 ,z)
This transformation would be really useful for a model that I am scripting
at present, I couldn't work out how to do it with multmatrix(), please
could
you provide the affine transformation matrix to use.
Thanks,
Trygon
--
View this message in context:
http://forum.openscad.org/Non-Linear-Transformations-tp14539p14579.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
Oh, nice. This algorithm "removes excess detail in crowded regions where
the surface is contracting", which is more sophisticated than what I
specified.
On 16 November 2015 at 16:45, Neon22 mschafer@wireframe.biz wrote:
@Doug - This remeshing algorithm was designed specifically for this exact
purpose and worked very well at the time. (1992). May be worth a read:
--
View this message in context:
http://forum.openscad.org/Non-Linear-Transformations-tp14539p14581.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 Nov 16, 2015, at 16:52 PM, doug moen doug@moens.org wrote:
I tried using the perspective transformation matrix from wikipedia in OpenSCAD and it didn't work, I got a run-time error. Don't remember the details, it was a while ago. At the time, I concluded that we don't support arbitrary affine transformations.
The perspective transformation is not affine. We currently don’t support non-affine transformations because CGAL doesn’t.
-Marius
- Given that a transform function could be defined in OpenSCAD as:
function transform(v)=let(x=v[0], y=v[1], z=v[2]) [xz/20, yz/20, z];
which maps a single vertex to a new position (as per doug.moen: vector in,
vector out), perhaps a better syntax would be:
transform()=[xz/20, yz/20, z] { ... }
- I have been using non affine transformations in my code for a while and
the world has not ended. Yes they do have to be used with care, but are
useful. The main issue is that they can only be used at present when all the
geometry data has been computed directly so that the vertex data is visible.
-Trygon
--
View this message in context: http://forum.openscad.org/Non-Linear-Transformations-tp14539p14585.html
Sent from the OpenSCAD mailing list archive at Nabble.com.