P
Parkinbot
Sun, Feb 16, 2020 12:18 PM
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([10sin(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/
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/
RP
Ronaldo Persiano
Sun, Feb 16, 2020 1:48 PM
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([10sin(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:
>
> 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:
J
jon
Sun, Feb 16, 2020 2:12 PM
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([10sin(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
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>
>
A
adrianv
Sun, Feb 16, 2020 2:16 PM
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/
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/
P
Parkinbot
Sun, Feb 16, 2020 2:40 PM
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/
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/
RP
Ronaldo Persiano
Sun, Feb 16, 2020 2:45 PM
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]);
}
>
> 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]);
}
RP
Ronaldo Persiano
Sun, Feb 16, 2020 2:51 PM
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. :) )
>
> 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. :) )
P
Parkinbot
Sun, Feb 16, 2020 2:59 PM
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/
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/
RP
Ronaldo Persiano
Sun, Feb 16, 2020 3:29 PM
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.
> 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.
>
P
Parkinbot
Sun, Feb 16, 2020 5:11 PM
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/
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/
