linear_extrude(height=5, twist=45, scale=[5,1], slices=20)
	square(1, center=true);

To nobody's surprise, this is not a new issue, but it never really got a resolution the last time it came up. The last time was here:  http://forum.openscad.org/Strange-behaviour-of-linear-extrude-tp28408p28425.html This was an unexpected result: linear_extrude(height=5, twist=45, scale=[5,1], slices=20) square(1, center=true); On the left is what I get; on the right is what I expected.  I expected it to scale and *then* apply the twist. I mean, it's not technically *wrong*, but it seems a lot less useful. (I got the one on the right using a DIY implementation of linear_extrude.) Does anybody think that the current behavior is useful enough to retain? Does anybody think that adding a switch to do it in the other order would have enough value to do it? (Note:  A switch would allow for a transition from the current behavior to a new behavior.  You start with the switch defaulting to the old behavior, and you warn if there is both twist and non-uniform scale and the switch is not specified.  You leave it like that for a release or two to give people who want the old behavior to add the switch, and then flip the default to the new behavior and eliminate the warning.)

On 09.03.21 17:04, Jordan Brown wrote: > Does anybody think that adding a switch to do it in the > other order would have enough value to do it? No, with offset_extrude() there's even another operation that would make it even more difficult. I think the much more interesting question would be: Can we split this up into separate operation so that the user can give them in the order that works best for a specific design. ciao, Torsten.

On 2021-03-09 17:04, Jordan Brown wrote: > This was an unexpected result: > >> linear_extrude(height=5, twist=45, scale=[5,1], slices=20) >> square(1, center=true); > > On the left is what I get; on the right is what I expected. I > expected it to scale and *then* apply the twist. I don't see how you came to the "right" expectation, the twist is an angle around Z. Carsten Arnholm

On 3/9/2021 8:27 AM, Torsten Paul wrote: > On 09.03.21 17:04, Jordan Brown wrote: >> Does anybody think that adding a switch to do it in the >> other order would have enough value to do it? > No, with offset_extrude() there's even another operation > that would make it even more difficult. Yeah, ugh, though as with twist vs scale it seems to me that the ordering is mostly constrained by what order is useful. twist vs scale:  scale first, then twist. twist vs offset:  I don't think it matters.  (But offset can add points, so maybe you twist first to keep the number of points low as long as possible.) scale vs offset:  scale first, then offset.  (This both keeps your offset from being non-uniformly scaled, and lets offset sample intelligently without scale then distorting the sampling.) That suggests that the "usual" order be scale, twist, offset. What I want to know is how many people would want something different. For both twist and offset, I'm having a hard time coming up with use cases for scaling after. > I think the much more interesting question would be: > > Can we split this up into separate operation so that > the user can give them in the order that works best for > a specific design. Yes, having the ability to decompose it (without totally DIY) would be good.  But at the same time the obvious case should be as simple as practical. linear_extrude(..., transform=["scale", [sx,sy], "offset", [...], "twist", 45, "scale", [sx2,sy2]], ...); Yuck, but very general and not all that obscure.  A mechanism using a function pointer (whatever OpenSCAD is calling them) would be very general but seems like it would be undesirably intricate to use.