Strange behaviour of linear_extrude()

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of linear_extrude()

Parkinbot
Ronaldo,

the first code mimics exactly what you get from

linear_extrude(height = 100, twist = 310, scale = [1, .2]) translate([30, 0,
0])square(20, center = true);

and creates the yellow object in my shot with skew. So you might have mixed
it up? The problem is: You can't serve two masters. Either semantics has its
relevance to real world problems and an implementation must choose any of
them or offer means to make a choice.

What I miss most in linear_extrude() is an exposed control variable like
*$slice*' allowing for customized transformations or any other operations on
the operands. This would be a tremendous gain for linear_extrude(). Here two
hypothetic code examples, what could be done with such a means:

linear_extrude(height = 100, slices = 90)
    translate([10*sin(4*$slice), 0, 0]) square(20, center = true);  

<http://forum.openscad.org/file/t887/le1.png>

linear_extrude(height = 100, slices = 90)
    square(20*(1.5+sin(4*$slice), center = true)

<http://forum.openscad.org/file/t887/le2.png>










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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of linear_extrude()

Ronaldo
So you might have mixed
it up? The problem is: You can't serve two masters. Either semantics has its
relevance to real world problems and an implementation must choose any of
them or offer means to make a choice.

Yes, you are right: I have mixed it up.
What I miss most in linear_extrude() is an exposed control variable like
*$slice*' allowing for customized transformations or any other operations on
the operands. This would be a tremendous gain for linear_extrude(). 

I agree that it would be a huge gain but I guess your syntax will offend the compiler because $slice
would not be a defined variable. It might be an alternative to resort to function literals :

linear_extrude(height = 100, slices = 90, transform=function(slicenum) translate([10*sin(4* slicenum  ), 0, 0])
    square(20, center = true);   

linear_extrude(height = 100, slices = 90, transform=function(sl)  scale(20*(1.5+sin(4*sl) )
    square(1, center = true);

However, that alternative is not so general as your syntax and could not produce forms like:

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

genlinext.PNG (23K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of linear_extrude()

jon_bondy
In reply to this post by Parkinbot
Very nice indeed!

On 2/16/2020 7:18 AM, Parkinbot wrote:

> Ronaldo,
>
> the first code mimics exactly what you get from
>
> linear_extrude(height = 100, twist = 310, scale = [1, .2]) translate([30, 0,
> 0])square(20, center = true);
>
> and creates the yellow object in my shot with skew. So you might have mixed
> it up? The problem is: You can't serve two masters. Either semantics has its
> relevance to real world problems and an implementation must choose any of
> them or offer means to make a choice.
>
> What I miss most in linear_extrude() is an exposed control variable like
> *$slice*' allowing for customized transformations or any other operations on
> the operands. This would be a tremendous gain for linear_extrude(). Here two
> hypothetic code examples, what could be done with such a means:
>
> linear_extrude(height = 100, slices = 90)
>      translate([10*sin(4*$slice), 0, 0]) square(20, center = true);
>
> <http://forum.openscad.org/file/t887/le1.png>
>
> linear_extrude(height = 100, slices = 90)
>      square(20*(1.5+sin(4*$slice), center = true)
>
> <http://forum.openscad.org/file/t887/le2.png>
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of linear_extrude()

adrianv
In reply to this post by Ronaldo
Ronaldo wrote
> I agree that it would be a huge gain but I guess your syntax will offend
> the compiler because $slice
> would not be a defined variable.

What do you mean that $slice is not a "defined variable"?  You can use any
"$" variable you want.  Consider

module two() {
    for(i=[0:1]) {
      $index=i;
      translate([5*i,0,0]) children();
    }  
}


two(){
   if ($index==0) sphere(r=2);
   else cube([2,2,2]);
}





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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of linear_extrude()

Parkinbot
In reply to this post by Ronaldo
Well, I don't think the compiler will be offended. OpenSCAD supports the
basic mechanism and $slice could be exposed locally to the operands of
linear_extrude like $fn and so on. See the following code:

mymodule($i=13)
{
  echo($i);
  translate([0,0,10*$i]) cube(5);
}
module mymodule($i)  
  for($i=[0:$i])
    children();

Its output is 14 cubes lined up in z direction plus the following console
output :

ECHO: 0
ECHO: 1
...
ECHO: 13
<http://forum.openscad.org/file/t887/le3.png>
And currently the compiler lets you write:

linear_extrude(100, $slice=100) square($slice);

The only change required in the implementation of linear_extrude would be to
mirror the value of the internal control variable to $slice. This is not
such a big deal.





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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of linear_extrude()

Ronaldo
In reply to this post by adrianv
What do you mean that $slice is not a "defined variable"?  You can use any
"$" variable you want. 

Yes, you can, provided that it has been properly initialized as in your example. I may be wrong but in the Parkinbot syntax, $slices would be initialized inside linear_extrude, out of the reach of the compiler. I realize now that there is "exceptions" like $children that is always defined inside a module definition. However, $children is not defined inside a children.

module two() {
    for(i=[0:1]) {
      $index=i;
      translate([5*i,0,0]) children();
    }
    echo(inside=$children);
}

two()
{  echo(outside=$children);
   if ($index==0) sphere(r=2);
   else cube([2,2,2]);
   }



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of linear_extrude()

Ronaldo
In reply to this post by Parkinbot
And currently the compiler lets you write:

linear_extrude(100, $slice=100) square($slice);


That is legal because $slice is seen by the compiler as an initialize variable!

( (Whispering) C'mon, Parkinbot! linear_extrude with your syntax would be almost like your sweep or my loft and its name would be misleading. :) )

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of linear_extrude()

Parkinbot
In reply to this post by Parkinbot
But there is a different and more severe problem. If i had such a variable, I
could express joins and furcations (e.g. two distanced circles with growing
radii that join into a single shape during extrusion) and other fancy stuff,
like shapes from polygons with a growing number of vertices, that can't be
coated any more by use of a *natural* semantics.




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of linear_extrude()

Ronaldo

But there is a different and more severe problem. If i had such a variable, I
could express joins and furcations (e.g. two distanced circles with growing
radii that join into a single shape during extrusion) and other fancy stuff,
like shapes from polygons with a growing number of vertices, that can't be
coated any more by use of a *natural* semantics.

Yes, you could but linear_extrude might check whether all slices are polygons with the same number of vertices as it does to reject cubes and strings as children. It would painful however to check they all have the same topology.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of linear_extrude()

Parkinbot
Yes, a topology check is painful and the restrictions will make things
difficult for novices.

However, back to reality, I can think of at least one valuable extension to
linear_extrude() that seems to be safe: a xy-translation parameter:

linear_extrude(height = 100, translate = [x, y]) object2D();

The semantics would obviously be a slice-wise growing translation during
extrusion. But again: the order of the three affine operations scale, twist,
and translate will have to be chosen, so we end up with having to introduce
another parameter like *mode* that allows to choose the order of the three
slice-wise operations.



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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12