discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Current status of multmatrix() for projective transformations

C
Circonflexe
Mon, Nov 16, 2020 7:15 PM

So I want to write a wrap module that performs a cylindrical coordinate
transform to roll its children around a cylinder. (This would have lots of
uses, e.g. a cylinder for a music box, a crown, or a cookie roller). A
natural way to do this in userland is to dissect the children into slices
and map each slice to a wedge of the cylinder. (It could even be generalized
to wrap around any user-defined shape. This is actually what I was writing).
However, the slice->wedge transformation is not linear (it has a singularity
at the axis of the cylinder). It would be possible to implement this using
projective transformations from multmatrix(), i.e. those transformations
where the last row is anything but [0,0,0,1]. This topic seems to have
frequently been discussed online;  the most recent answer I see
http://forum.openscad.org/flaring-a-model-td28127.html  , on this very
forum, says that this is currently not possible, because OpenSCAD always
replaces the last row by [0,0,0,1]. (I just confirmed this empirically).
So the current status of multmatrix is (to me) insufficient, but I don't
know if improving it is in the pipeline in any way. I believe that allowing
generic projective transforms would be very simple for at least the basic
CSG operations (union, intersection etc.), by applying the matrix to all
coordinates /before/ calling any rendering library: namely, all these
set-wise operations are compatible with generic projective transforms. Even
convex hull would mostly work (because projective transformations preserve
lines: as long as your singularities lie outside your object, line
/segments/ are also preserved and you are good); only Minkowski would be a
problem. So implementing a generic multmatrix() would only be a matter of
applying linear tansformations down the CSG tree, and raising a warning
whenever a hull() or minkowski() operation is found with a non-trivial
fourth row. Is this a current goal of OpenSCAD development?
(as a proof of concept, I am writing a part of this in OpenSCAD language
right now. This would work, but ultimately not be the right way to do
this!).

--
Sent from: http://forum.openscad.org/

So I want to write a `wrap` module that performs a cylindrical coordinate transform to roll its children around a cylinder. (This would have lots of uses, e.g. a cylinder for a music box, a crown, or a cookie roller). A natural way to do this in userland is to dissect the children into slices and map each slice to a wedge of the cylinder. (It could even be generalized to wrap around any user-defined shape. This is actually what I was writing). However, the slice->wedge transformation is not linear (it has a singularity at the axis of the cylinder). It would be possible to implement this using projective transformations from multmatrix(), i.e. those transformations where the last row is anything but [0,0,0,1]. This topic seems to have frequently been discussed online; the most recent answer I see <http://forum.openscad.org/flaring-a-model-td28127.html> , on this very forum, says that this is currently not possible, because OpenSCAD always replaces the last row by [0,0,0,1]. (I just confirmed this empirically). So the current status of multmatrix is (to me) insufficient, but I don't know if improving it is in the pipeline in any way. I believe that allowing generic projective transforms would be very simple for at least the basic CSG operations (union, intersection etc.), by applying the matrix to all coordinates /before/ calling any rendering library: namely, all these set-wise operations are compatible with generic projective transforms. Even convex hull would mostly work (because projective transformations preserve lines: as long as your singularities lie outside your object, line /segments/ are also preserved and you are good); only Minkowski would be a problem. So implementing a generic multmatrix() would only be a matter of applying linear tansformations down the CSG tree, and raising a warning whenever a hull() or minkowski() operation is found with a non-trivial fourth row. Is this a current goal of OpenSCAD development? (as a proof of concept, I am writing a part of this in OpenSCAD language right now. This would work, but ultimately not be the right way to do this!). -- Sent from: http://forum.openscad.org/
P
Parkinbot
Thu, Nov 26, 2020 10:24 AM

An operator using this "generalized" transformation would have to do exactly
what you mentioned:
It would have to slice the object into chops (i.e. some refined
triangulation has to take place) and then apply your suggested
transformation in a pointwise fashion. While this map is obviously not
affine (by definition) it is also not injective in general. Thus it is prone
to produce singularities and have a lot of nasty effects that can harm the
integrity of an object and mess up a design. This not exactly what an
operator should be allowed to do. Just keep general sweep or skin operations
in mind which allow for self-intersections.

Of course it would be possible to implement such behaviour and put an "enter
at our own risk" sign in front of the door. But, first it is not an easy
task (think of the refinement) to accomplish and second such an "unsave"
operation will never make it into a release version.

--
Sent from: http://forum.openscad.org/

An operator using this "generalized" transformation would have to do exactly what you mentioned: It would have to slice the object into chops (i.e. some refined triangulation has to take place) and then apply your suggested transformation in a pointwise fashion. While this map is obviously not affine (by definition) it is also not injective in general. Thus it is prone to produce singularities and have a lot of nasty effects that can harm the integrity of an object and mess up a design. This not exactly what an operator should be allowed to do. Just keep general sweep or skin operations in mind which allow for self-intersections. Of course it would be possible to implement such behaviour and put an "enter at our own risk" sign in front of the door. But, first it is not an easy task (think of the refinement) to accomplish and second such an "unsave" operation will never make it into a release version. -- Sent from: http://forum.openscad.org/