Parkinbot wrote:

I want to clarify some terminology.

Yes, it's true that projection() is mathematically equivalent to
scale([1,1,0]). Thanks for pointing this out. Mathematically, a projection
is just a special case of a linear transformation! In OpenSCAD, these two
aren't actually equivalent, because projection() returns a 2D object, while
scale([1,1,0]) returns something that looks like the output of
projection(), and looks like a 2D object, but which is labelled internally
as 3D.

But a projection is not the same thing as a projective transformation.

There are 3 classes of matrix-based geometric transformations.

• The smallest class is linear transformations. These can be represented
  by a 3x3 matrix (in 3D). Linear transformations include rotation,
  reflection, scaling and shearing, but you can't perform a translation. The
  point [0,0,0] is always mapped to [0,0,0].
• The next largest class is affine transformations, which are a superset
  of linear transformations. This adds the ability to perform translations.
  You need a 4x4 matrix, but there are restrictions on the matrix. The bottom
  row consists of [0,0,0,1], and the right column is [tx,ty,tz,1], where
  [tx,ty,tz] is the translation component of the affine transformation. The
  top-left 3 rows and columns are the 3x3 matrix of the linear component of
  the affine transformation.
• The largest class is projective transformations, which are a superset
  of affine transformations. This adds the ability to map rectangles onto
  trapezoids and perform perspective transformations. You can map points out
  to infinity, so you can transform a finite object into an infinite object.
  For example, you can map a finite circle to an infinite parabola. You can
  also do the reverse, and map points at infinity to a finite range.
  Projective transformations are represented by an arbitrary 4x4 matrix.

Be careful when you talk about non-linear transformations, because
translate() is a non-linear transformation. You might instead be referring
to a non-affine transformation.

The reason I brought up projective transformations is in response to a
comment by Wolf, who said: "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."

I wanted to point out that there are some technical challenges in
generalizing multmatrix() to support arbitrary 4x4 matrices (projective
transformations).

On 22. mars 2016 13:49, Parkinbot wrote:

Perhaps, in rotate_extrude, a pitch parameter combined with an ability
to specify many revolutions in the angle parameter would be enough to
define threads.

Carsten Arnholm

Doug, you are right in the sense of strict terminology. But also with respect
to the title of the thread I rather prefer the term non-linear
transformation instead of 'non-affine' transformation. The notion is
commonly used and understood to characterize functions that do not just
introduce a new cartesian coordinate system.

Neverless when we talk about 'non xxx' operations in CAD we have objects in
mind that maybe approximated by one (or many) shapes and a sequence of
affine transformations. You also mention the implementational difference
between 2D and 3D-shapes - which in my eyes is a strong restriction OpenSCAD
really should get rid of. Why shouldn't a 2D shape be allowed to live in 3D?
Therefore linear_extrude() is again a good candidate to see where
expectation and implementation clash and OpenSCAD's sematics gets unexpected
for newcomers.

It was also mentioned by others, that rotate_extrude() does unexpectedly an
implicit rotation (and even a 'strange' z-shift, when an y-offset is used).

At least an axis argument like "x", "y", "z" defaulting to "z" would here be
helpful.

So, for what reason are linear_extrude() and rotate_extrude() restricted to
2D shapes being placed at z=0 at all? Why can't they also operate over 2D
objects living in 3D space or even 3D objects being placed anywhere? See
this example (which can't be fully implemented with current language means,
think of "twist"):

http://forum.openscad.org/file/n16670/linear3D.png

xxx_extrude() in my eyes are the mightiest features in OpenSCAD, but still
far away from what is possible - with current language means.

--
View this message in context: http://forum.openscad.org/Non-Linear-Transformations-tp14539p16670.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

@Parkinbot, I have been looking at this problem of generalized extrusion,
in a context slightly removed from OpenSCAD. I've been messing around with
functional representation (F-Rep). My idea is that OpenSCAD would be more
powerful if the geometry engine could be generalized to support F-Rep, in
addition to the current mesh representation.

F-Rep allows you to provide an exact representation for any shape that can
be described by a mathematical function. And it turns out to be quite easy
to define powerful new geometrical primitives with not very much code. So
much easier than mesh algorithms. There are a bunch of OpenSCAD-like tools
that implement this already, so it's trendy, and there are open source
implementations to look at.

Even with F-Rep, it's still cheaper and more convenient to implement
linear_extrude and rotate_extrude with the same interface as in OpenSCAD,
where the shape being extruded is required to be 2D. With this restriction,
the code is simple and fast. I've got another variant (not tested) called
perimeter_extrude, which sweeps one 2D shape along the perimeter of another
2D shape. The code looks simple and fast, but I dunno if it will work in
all cases yet.

I am investigating the more general problem of sweeping a 3D shape through
space along a parameterized curve. One paper I found describes a general
solution to this problem, allowing the shape being swept to continuously
vary according to the curve parameter. Self intersections are handled. It's
totally general, but the code is complex and slow. I haven't actually tried
coding it.

I've found another research paper that describes a different solution,
where you achieve the sweep by constructing a higher dimensional shape and
then project that down to 3D. I'm not finished reading the paper.

Anyway, my answer to your comment is that there are engineering tradeoffs
where the more general algorithms may be much slower than the specialized
ones, so there is room for both.

There are definitely some annoying bugs where the geometric operations fail
to report bad arguments, and produce unexpected results instead, like what
you mentioned. Those bugs should be fixed.

I am undecided about the status of 2D shapes in my F-Rep geometry system:
should they have a different type than 3D shapes? Should they be 3D objects
that are distinguished by having a bounding box of height 0 that confines
them to the x-y plane? We do need to have identifiable 2D objects, so that
you can create a 2D object, preview it, export it to DXF.

I refuse to call translate() a linear transformation. It's technically
wrong, and it creates too much confusion if, like me, you are trying to
learn enough computational geometry to make full use of OpenSCAD, including
the linear algebra parts. I don't care about pop-culture misunderstandings
of what "non-linear" means, it's more important for me to not be confused
about the math.

On 22 March 2016 at 17:31, Parkinbot rudolf@parkinbot.com wrote:

doug.moen wrote

I've done some work on sweep() and spline interpolation on the basis of
OpenSCAD functions. Out of this background I don't see any significant
computational difference between extruding a 2D shape living in 2D or 3D.
Neither in allowing for directional vectors instead of [0,0,1].
Of course implementing linear_extrude() to operate over 3D shapes is more
sophisticated, but don't forget what is gained. It could replace hull() and
get rid of its convexity restriction. If it is done as proposed additional
costs will be limited. One could also live with twists and scales not being
applied to the objects halfs at the ends.

I'am afraid you will have to deal with self intersections as soon as
linearity is lost.

My approach for sweeps with fixed (or locally only smoothly morphing) shapes
is to evaluate the slope and rotation axes and calculate possible
intersections for extreme values analytically for each slice. Whenever an
intersection is found, the operation will be split and resulting shapes
finally combined with union(). The less pathologic a sweep is formulated the
faster the code.

• Rudolf -

--
View this message in context: http://forum.openscad.org/Non-Linear-Transformations-tp14539p16673.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Parkinbot wrote:

Okay, but linear_extrude() 3dshape is, except for the end caps, the same as
linear_extrude() projection() 3dshape. Little is gained except for some
convenience. But now I agree that it's not a burden to implement.

Consider this:

module linear_extrude3(h)
{
children();
linear_extrude(h) projection() children();
translate([0,0,h]) children();
}

linear_extrude3(10)
{
cube(8,center=true);
for(i=[0:90:270]) {
rotate([0,0,i]) translate([4,0,0]) sphere(2);
}
}

My comment about twist is that most of the F-Rep solid modelling systems
have a separate twist() operator that applies to any shape. It's only a
couple lines of code, so it's easy to implement, and more general than a
twist that can only be applied to the result of linear_extrude. This would
be an example of one of those functional transforms that Trygon was
promoting in the original post.

Yes, a separate twist operator allowing for an axis argument defaulted to [0,
0, 1] would gain a lot. But I am afraid it is not so easy to implement,
because it requests a decomposition of the operands into slices.

To have the endcaps is of course the salt in the soup. After all the shapes
need to be split, twisted and scaled. I tried to add a twist, which does not
twist the endcaps in lack of the twist operator. It has already CSG shadows
(F6 works fine). But no way to add a scale, because it is not expressible in
OpenSCAD.
Btw the code shows just another linear_extrude() bug. The twist parameter
rotates with wrong sign.

http://forum.openscad.org/file/n16678/lin3.png

--
View this message in context: http://forum.openscad.org/Non-Linear-Transformations-tp14539p16678.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Nice. I now see that the end caps need to be twisted in order for this to
work correctly with a twist parameter. A twist() operator would be needed.

In order to correctly scale the end caps, we need a projective
transformation, an extension discussed in this thread.

Interesting. The 'scale' parameter actually applies a projective
transformation to the output of linear extrude. If we supported these
transformations directly, the 'scale' parameter wouldn't be needed.

Doug.

On Wednesday, 23 March 2016, Parkinbot <rudolf@parkinbot.com
javascript:_e(%7B%7D,'cvml','rudolf@parkinbot.com');> wrote: