Discussion:
translate(10), like rotation(90)
(too old to reply)
Peter Falke
2014-06-05 02:28:47 UTC
Permalink
Would it be possible to modify the translate command so that a simple value
as argument would result in a z-translation.
Very much like rotation(90) rotates around the z axis or cube(10) produces
a "square" cube.

Sincerely,

TakeItAndRun
--
***@googlemail.com <***@rohrbach.de>

P.S. Falls meine E-Mail kÌrzer ausfÀllt als Dir angenehm ist:
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu
schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.

P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.

Enjoy!
Marius Kintel
2014-06-05 03:13:44 UTC
Permalink
Would it be possible to modify the translate command so that a simple value as argument would result in a z-translation.
Very much like rotation(90) rotates around the z axis or cube(10) produces a "square" cube.
It feels a bit arbitrary.

-Marius
Oskar
2014-06-05 05:20:04 UTC
Permalink
What about translate(z=5) ?

/Oskar



--
View this message in context: http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8255.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
nop head
2014-06-05 07:17:25 UTC
Permalink
Post by Marius Kintel
It feels a bit arbitrary.
Seem like symmetry with rotate to me. I find myself often translating in Z
only.
Post by Marius Kintel
What about translate(z=5) ?
/Oskar
--
http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8255.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
doug moen
2014-06-05 08:05:23 UTC
Permalink
Marius says: "It feels a bit arbitrary."

It does seem arbitrary to have a special abbreviation for the z axis that
isn't available for the x or y axes.

Here's an alternative way of abbreviating the code, which works equally
well for all 3 axes.

Abbreviation #1.
translate([0,0,k]) ...
can be abbreviated as
translate [0,0,k] ...
The parentheses around the argument list for a module can be dropped if
there is exactly one argument of the form [...].

Abbreviation #2.
[0,0,k]
can be abbreviated as
[,,k]
An missing item in a list literal defaults to 0.

Put these together, and you can use
translate [,,k] ...
to translate on just the z axis.
On Jun 4, 2014, at 22:28 PM, Peter Falke <
Post by Peter Falke
Would it be possible to modify the translate command so that a simple
value as argument would result in a z-translation.
Post by Peter Falke
Very much like rotation(90) rotates around the z axis or cube(10)
produces a "square" cube.
It feels a bit arbitrary.
-Marius
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
MichaelAtOz
2014-06-05 11:45:08 UTC
Permalink
Perhaps this is the time to introduce a thought I have had for a while.

Some languages allow you to redefine the base language functions/modules, ie
retaining the name of the built-in's but using your code, AND allowing your
code to then call the built-in. My altzimers memory goes to forth, and maybe
lisp.

So how about some syntax, within a function/module to flag a call as 'call
the built-in of the same name' or even better 'call the module/function of
the same name that is next lowest in the stack such'.

This would allow you to redefine the default behaviour.

So for example (have not thought much about the syntax) say... '@' as a
prefix to mean call the previous definition.

module translate(v) { // to default to z-axis translate
if len(v)=undef
@translate([0,0,v) children();
else // assume 3-vector
@translate(v) children();
}

Thus

use <transZ.scad>
difference()
cube(10,true);
// -
translate(-0.05)
cube([9,9,10.1]);




--
View this message in context: http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8260.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
nop head
2014-06-05 12:05:02 UTC
Permalink
The problem with user space definitions is everybody will create their own
dialect of the language and you won't then be able to exchange snippets of
code. Also what should be small stand alone files end up with dependencies
on personal libraries.

IMHO it is much better to put these things in the core language so they are
always available and consistent. Libraries should only be needed for
non-trivial things like involute gears, not syntactic sugar.
Post by MichaelAtOz
Perhaps this is the time to introduce a thought I have had for a while.
Some languages allow you to redefine the base language functions/modules, ie
retaining the name of the built-in's but using your code, AND allowing your
code to then call the built-in. My altzimers memory goes to forth, and maybe
lisp.
So how about some syntax, within a function/module to flag a call as 'call
the built-in of the same name' or even better 'call the module/function of
the same name that is next lowest in the stack such'.
This would allow you to redefine the default behaviour.
prefix to mean call the previous definition.
module translate(v) { // to default to z-axis translate
if len(v)=undef
@translate([0,0,v) children();
else // assume 3-vector
@translate(v) children();
}
Thus
use <transZ.scad>
difference()
cube(10,true);
// -
translate(-0.05)
cube([9,9,10.1]);
--
http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8260.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
jon
2014-06-05 12:15:13 UTC
Permalink
I agree
Post by nop head
IMHO it is much better to put these things in the core language so
they are always available and consistent. Libraries should only be
needed for non-trivial things like involute gears, not syntactic sugar.
Felipe Sanches
2014-06-05 12:38:29 UTC
Permalink
I would call it "raise" instead os "transZ". Because it raises the object
in the coordinate system.

raise(10) cube(3);

would be the same as translate([0,0,10]) cube(3);
Post by jon
I agree
Post by nop head
IMHO it is much better to put these things in the core language so
they are always available and consistent. Libraries should only be
needed for non-trivial things like involute gears, not syntactic sugar.
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Szelp, A. Sz.
2014-06-05 12:36:34 UTC
Permalink
Rather into a "standard library" (shipped with the product) than the actual
core language.
This is common best practice.

Szelp, André Szabolcs

+43 (650) 79 22 400
Post by nop head
The problem with user space definitions is everybody will create their own
dialect of the language and you won't then be able to exchange snippets of
code. Also what should be small stand alone files end up with dependencies
on personal libraries.
IMHO it is much better to put these things in the core language so they
are always available and consistent. Libraries should only be needed for
non-trivial things like involute gears, not syntactic sugar.
Post by MichaelAtOz
Perhaps this is the time to introduce a thought I have had for a while.
Some languages allow you to redefine the base language functions/modules, ie
retaining the name of the built-in's but using your code, AND allowing your
code to then call the built-in. My altzimers memory goes to forth, and maybe
lisp.
So how about some syntax, within a function/module to flag a call as 'call
the built-in of the same name' or even better 'call the module/function of
the same name that is next lowest in the stack such'.
This would allow you to redefine the default behaviour.
prefix to mean call the previous definition.
module translate(v) { // to default to z-axis translate
if len(v)=undef
@translate([0,0,v) children();
else // assume 3-vector
@translate(v) children();
}
Thus
use <transZ.scad>
difference()
cube(10,true);
// -
translate(-0.05)
cube([9,9,10.1]);
--
http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8260.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Joseph Lenox
2014-06-05 12:39:36 UTC
Permalink
You are always going to get "personal dialect" issues, as people will do
whatever they feel like to make the representation seem "natural" to
them. Better to keep it in userspace, where at worst the snippet can be
transformed with a preprocessor (maybe an "extract self-contained
snippet" routine would be a useful tool to this end) to not depend on an
external library.

I suggest caution in adding shortcut functions--I don't think anyone
(who has to maintain OpenSCAD) wants to go down the PHP route. That way
lay madness and multiple functions that do the same thing part of the
base system because somewhere someone decided it was good to have a
specialized shortcut.
Post by nop head
The problem with user space definitions is everybody will create their
own dialect of the language and you won't then be able to exchange
snippets of code. Also what should be small stand alone files end up
with dependencies on personal libraries.
IMHO it is much better to put these things in the core language so
they are always available and consistent. Libraries should only be
needed for non-trivial things like involute gears, not syntactic sugar.
--
--Joseph Lenox, BS, MS
I'm an engineer. I solve problems.
Marius Kintel
2014-06-05 13:20:29 UTC
Permalink
Hi,

Some clarifications:
* For cube, square and scale, a single argument (a) will expand to a vector where all arguments is a, depending on whether it’s a 2D or 3D object ([a,a] or [a,a,a])
* Rotate is declared like this: rotate(angle, axis=[0,0,1]). i.e., there is no expansion from scalar to vector, just a default value.

The reason why rotate appears to be managed differently is that rotation in 2D only really makes sense around the Z axis. The default is thus a special case for 2D, but works in 3D as well, since it’s the _axis_, not the angle that’s got a default value.

Now, for translate, it doesn’t make a whole lot of sense to expand a single scalar (a) to a vector [a,a,a]. Also, in the special case of 2D, it makes sense to pad with zeros; [a,b] => [a,b,0].

Introducing support for scalar values seem illogical to me unless we introduce a syntax like rotate, e.g. translate(value, axis=[0,0,1]).

-Marius
nop head
2014-06-05 13:40:40 UTC
Permalink
In my mind it just makes sense that given a single scalar argument it would
be Z as X and Y are symmetrical and Z is different.
Post by Marius Kintel
Hi,
* For cube, square and scale, a single argument (a) will expand to a
vector where all arguments is a, depending on whether it's a 2D or 3D
object ([a,a] or [a,a,a])
* Rotate is declared like this: rotate(angle, axis=[0,0,1]). i.e., there
is no expansion from scalar to vector, just a default value.
The reason why rotate appears to be managed differently is that rotation
in 2D only really makes sense around the Z axis. The default is thus a
special case for 2D, but works in 3D as well, since it's the _axis_, not
the angle that's got a default value.
Now, for translate, it doesn't make a whole lot of sense to expand a
single scalar (a) to a vector [a,a,a]. Also, in the special case of 2D, it
makes sense to pad with zeros; [a,b] => [a,b,0].
Introducing support for scalar values seem illogical to me unless we
introduce a syntax like rotate, e.g. translate(value, axis=[0,0,1]).
-Marius
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Szelp, A. Sz.
2014-06-05 16:04:35 UTC
Permalink
Inhowfar are x and y "symmetrical"?
Why is "z" special?

In 3D space these are indistinguishable.
Or do you assume that the frame of reference is "Earth", and z=[0,0,-1] is
"marked" (i.e. special) by being the direction of the gravitational force?

-- This assumption cannot hold in a cartesian coordinate system, as for the
point [x,y,0] for large x and y [0,0,-1] is *not* the direction of gravity.



Szelp, André Szabolcs

+43 (650) 79 22 400
Post by nop head
In my mind it just makes sense that given a single scalar argument it
would be Z as X and Y are symmetrical and Z is different.
Post by Marius Kintel
Hi,
* For cube, square and scale, a single argument (a) will expand to a
vector where all arguments is a, depending on whether it’s a 2D or 3D
object ([a,a] or [a,a,a])
* Rotate is declared like this: rotate(angle, axis=[0,0,1]). i.e., there
is no expansion from scalar to vector, just a default value.
The reason why rotate appears to be managed differently is that rotation
in 2D only really makes sense around the Z axis. The default is thus a
special case for 2D, but works in 3D as well, since it’s the _axis_, not
the angle that’s got a default value.
Now, for translate, it doesn’t make a whole lot of sense to expand a
single scalar (a) to a vector [a,a,a]. Also, in the special case of 2D, it
makes sense to pad with zeros; [a,b] => [a,b,0].
Introducing support for scalar values seem illogical to me unless we
introduce a syntax like rotate, e.g. translate(value, axis=[0,0,1]).
-Marius
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
nop head
2014-06-05 16:30:20 UTC
Permalink
Z is special because OpenScad has a 2D system that exists in XY and
cylinder and linear_extrude are in the Z direction.

About 1/4 of all my translates are in Z only.

Also as you point out our experience on earth makes Z different from X and
Y. My 3D printers all have Z pointing up but X and Y are aligned with the
walls of my house, which is arbitrary. Also FFF printing makes Z special
compared to X & Y.
Post by Szelp, A. Sz.
Inhowfar are x and y "symmetrical"?
Why is "z" special?
In 3D space these are indistinguishable.
Or do you assume that the frame of reference is "Earth", and z=[0,0,-1] is
"marked" (i.e. special) by being the direction of the gravitational force?
-- This assumption cannot hold in a cartesian coordinate system, as for
the point [x,y,0] for large x and y [0,0,-1] is *not* the direction of
gravity.
Szelp, André Szabolcs
+43 (650) 79 22 400
Post by nop head
In my mind it just makes sense that given a single scalar argument it
would be Z as X and Y are symmetrical and Z is different.
Post by Marius Kintel
Hi,
* For cube, square and scale, a single argument (a) will expand to a
vector where all arguments is a, depending on whether it's a 2D or 3D
object ([a,a] or [a,a,a])
* Rotate is declared like this: rotate(angle, axis=[0,0,1]). i.e., there
is no expansion from scalar to vector, just a default value.
The reason why rotate appears to be managed differently is that rotation
in 2D only really makes sense around the Z axis. The default is thus a
special case for 2D, but works in 3D as well, since it's the _axis_, not
the angle that's got a default value.
Now, for translate, it doesn't make a whole lot of sense to expand a
single scalar (a) to a vector [a,a,a]. Also, in the special case of 2D, it
makes sense to pad with zeros; [a,b] => [a,b,0].
Introducing support for scalar values seem illogical to me unless we
introduce a syntax like rotate, e.g. translate(value, axis=[0,0,1]).
-Marius
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
runsun
2014-06-05 14:01:01 UTC
Permalink
Post by Marius Kintel
Rotate is declared like this: rotate(angle, axis=[0,0,1])
Is this default recently added? I am using 2014-03-11 snapshot on Linux
Mint 14. Just tried this with:

rotate( 360$t ) // (a)
rotate( 360$t, axis=[0,0,5] ) // (b)
rotate( 360$t, axis=[0,5,0] ) // (c)
rotate( 360$t, axis=[5,0,0] ) // (d)

They behave exactly the same, all rotate about the z-axis, as though the
axis argument doesn't have any effect.


Another issue :

IMHO, the existence of an argument like axis in a "rotate" action would
indicate that a rotation about "any" axis is allowed. But if axis takes only
one vector like [0,0,1], even if we can make it to work with [0,1,1],
[1,1,0],[1,0,1] and [1,1,1], it is still limited to "rotating about an axis
that passes through [0,0,0]."

So, ideally, it could also be made to take a 2-pointer like
[[2,1,0],[1,-1,0]] such that the rotation can be made about any axis in the
space.







-----
Runsun Pan, PhD
--
View this message in context: http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8270.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Marius Kintel
2014-06-05 14:09:15 UTC
Permalink
Post by runsun
rotate( 360$t ) // (a)
rotate( 360$t, axis=[0,0,5] ) // (b)
rotate( 360$t, axis=[0,5,0] ) // (c)
rotate( 360$t, axis=[5,0,0] ) // (d)
Sorry, my bad, the second argument name is “v”, not “axis”. I don’t really use that too much apparently : /

-Marius
Lester Hall
2014-06-05 14:19:34 UTC
Permalink
shouldn’t there be an asterisk (*) between the 360 and the $t?

Les
Post by runsun
Post by Marius Kintel
Rotate is declared like this: rotate(angle, axis=[0,0,1])
Is this default recently added? I am using 2014-03-11 snapshot on Linux
rotate( 360$t ) // (a)
rotate( 360$t, axis=[0,0,5] ) // (b)
rotate( 360$t, axis=[0,5,0] ) // (c)
rotate( 360$t, axis=[5,0,0] ) // (d)
They behave exactly the same, all rotate about the z-axis, as though the
axis argument doesn't have any effect.
IMHO, the existence of an argument like axis in a "rotate" action would
indicate that a rotation about "any" axis is allowed. But if axis takes only
one vector like [0,0,1], even if we can make it to work with [0,1,1],
[1,1,0],[1,0,1] and [1,1,1], it is still limited to "rotating about an axis
that passes through [0,0,0]."
So, ideally, it could also be made to take a 2-pointer like
[[2,1,0],[1,-1,0]] such that the rotation can be made about any axis in the
space.
-----
Runsun Pan, PhD
--
View this message in context: http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8270.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Felipe Sanches
2014-06-05 14:26:33 UTC
Permalink
I think the reason for the rotations to be always around an axis that
necessarily crosses [0,0,0] has a tight relation to the fact that rotate()
capabilities are mapped to the capabilities of a rotation transform matrix
as we learn in linear algebra.
Post by runsun
Post by Marius Kintel
Rotate is declared like this: rotate(angle, axis=[0,0,1])
Is this default recently added? I am using 2014-03-11 snapshot on Linux
rotate( 360$t ) // (a)
rotate( 360$t, axis=[0,0,5] ) // (b)
rotate( 360$t, axis=[0,5,0] ) // (c)
rotate( 360$t, axis=[5,0,0] ) // (d)
They behave exactly the same, all rotate about the z-axis, as though the
axis argument doesn't have any effect.
IMHO, the existence of an argument like axis in a "rotate" action would
indicate that a rotation about "any" axis is allowed. But if axis takes only
one vector like [0,0,1], even if we can make it to work with [0,1,1],
[1,1,0],[1,0,1] and [1,1,1], it is still limited to "rotating about an axis
that passes through [0,0,0]."
So, ideally, it could also be made to take a 2-pointer like
[[2,1,0],[1,-1,0]] such that the rotation can be made about any axis in the
space.
-----
Runsun Pan, PhD
--
http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8270.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
runsun
2014-06-05 15:46:17 UTC
Permalink
@ Marius: v works fine. Thx.
@ Lester: yes, it shoulda been 360*$t. Typed too fast.
@ Felipe: Thx. Would have been better if OpenSCAD takes care of the

translation
rotation_about_line_crossing_[0,0,0]
translation_back

for the users so a rotation about any axis in space becomes easy.



-----
Runsun Pan, PhD
--
View this message in context: http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8276.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
runsun
2014-06-05 15:50:39 UTC
Permalink
Post by runsun
Would have been better if OpenSCAD takes care of the
translation
rotation_about_line_crossing_[0,0,0]
translation_back
for the users so a rotation about any axis in space becomes easy.
In fact, come to think of it, the above process is easy enough ...



-----
Runsun Pan, PhD
--
View this message in context: http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8277.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Szelp, A. Sz.
2014-06-05 16:06:52 UTC
Permalink
Roll your own ;-)

But true, such operations
translate(-x) rotate(y,v) translate(x) module()


are *very* common.

Szelp, André Szabolcs

+43 (650) 79 22 400
Post by runsun
@ Marius: v works fine. Thx.
@ Lester: yes, it shoulda been 360*$t. Typed too fast.
@ Felipe: Thx. Would have been better if OpenSCAD takes care of the
translation
rotation_about_line_crossing_[0,0,0]
translation_back
for the users so a rotation about any axis in space becomes easy.
-----
Runsun Pan, PhD
--
http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8276.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Kenneth Sloan
2014-06-05 16:23:35 UTC
Permalink
Rotation about an arbitrary axis can also be done with the same type of matrix.
The computation is just a bit more complicated.

If rotation is to be generalized (or another, more powerful version created), I would
like:

rotate(a=angle, p0=[x0,y0,z0], p1=[x1,y1,z1])

Where p0 can be omitted (default = [0,0,0])
and p1 can be omitted (default = [0,0,1])

In addition (actually, this might be an alternative), I’d like:

map(f0=[v00,v01,v02], f1=[v10,v11,v12])

which applies a transform which maps the Origin to the Origin and reference frame f0 to reference frame f1.
Both f0 and f1 could default to [[0,0,1],[0,1,0],[1,0,0]]. A more complicated version might include Origin0 and Origin1,
both of which might default to [0,0,0].

In my experience, these *can* be done by the user, given the current translate(), rotate(), and scale(), but
they require enough calculation that it’s best included in the core.

I’m not *at all* happy with the current rotate - with it’s non-standard (to my eye) convention of performing
several rotations in a fixed order. I try not to use it that way (using several distinct rotate() calls, instead
because I find that the resulting code is easier (for me) to read. No doubt a personal failing.

While I’m listing “druthers”, I’d like to suggest full support for 4x4 transformation matrices and 4x1
points and vectors - but, I can also make strong arguments on the opposing side.

At bottom, all you really need is full support for 4x4 and 4x1 objects (creation, manipulation, all the standard
operators), plus a well designed (user level) package that hides all of that from the designer.

The current crop of standard operators represents the “easy to implement” and “all you need for simple objects” level of ambition, with a few (poorly thought out, in my view) “optimizations” for common cases.
For more complex modeling, the x,y, and z axes lose their special status, and it becomes much more
useful to have, for example, the more powerful “rotate about an arbitrary axis”, or “map this reference frame to that reference frame”. Not every interesting object is, or can be, “axis aligned”, esp. if we are talking about
current 3D printing technology instead of lathes or simple self-supporting geometry.

On the other side of the coin, I would like at all costs to RESIST the temptation to take “sphere” down the same
route as “cube”. I *much* prefer cubical cubes and spherical spheres, and I think it’s much cleaner and clearer
to create a sphere and then separately squash it. If possible, I would roll back the abomination of a “cube” with
three different dimensions!

And finally (rant #32) - there seems to me to be a continuing tension between those who would prefer a read-only
language (like APL) for it’s lapidary elegance, and those who would prefer verbose, human-readable code.
I’m caught in the middle. I adopted OpenSCAD for my own work precisely because it was lean and mean - a “scripting” language. The history of “scripting” languages is that when they expand into general purpose “programming” languages, they become bloated and fail. Instead of growing OpenSCAD one convenient feature at a time, it may be time
to consider TWO new languages: a) a stripped back scripting language intended for simple model description, and b) a new language, designed from the start to be a programming language which includes CSG and related topics as first class
entities. In my opinion, OpenSCAD is *right now* at the point where future additions may hurt rather than help.

Note that I take no position on “functional” vs “procedural” - I’m happy with either choice (but unhappy with
poorly motivated blends).

Just my opinion, for what it’s worth.

--
Kenneth Sloan
I think the reason for the rotations to be always around an axis that necessarily crosses [0,0,0] has a tight relation to the fact that rotate() capabilities are mapped to the capabilities of a rotation transform matrix as we learn in linear algebra.
Post by Marius Kintel
Rotate is declared like this: rotate(angle, axis=[0,0,1])
Is this default recently added? I am using 2014-03-11 snapshot on Linux
rotate( 360$t ) // (a)
rotate( 360$t, axis=[0,0,5] ) // (b)
rotate( 360$t, axis=[0,5,0] ) // (c)
rotate( 360$t, axis=[5,0,0] ) // (d)
They behave exactly the same, all rotate about the z-axis, as though the
axis argument doesn't have any effect.
IMHO, the existence of an argument like axis in a "rotate" action would
indicate that a rotation about "any" axis is allowed. But if axis takes only
one vector like [0,0,1], even if we can make it to work with [0,1,1],
[1,1,0],[1,0,1] and [1,1,1], it is still limited to "rotating about an axis
that passes through [0,0,0]."
So, ideally, it could also be made to take a 2-pointer like
[[2,1,0],[1,-1,0]] such that the rotation can be made about any axis in the
space.
-----
Runsun Pan, PhD
--
View this message in context: http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8270.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Szelp, A. Sz.
2014-06-05 17:04:13 UTC
Permalink
+1,
especially on the "language split" lest bloat-to-doom.
Post by Kenneth Sloan
Rotation about an arbitrary axis can also be done with the same type of matrix.
The computation is just a bit more complicated.
If rotation is to be generalized (or another, more powerful version created), I would
rotate(a=angle, p0=[x0,y0,z0], p1=[x1,y1,z1])
Where p0 can be omitted (default = [0,0,0])
and p1 can be omitted (default = [0,0,1])
map(f0=[v00,v01,v02], f1=[v10,v11,v12])
which applies a transform which maps the Origin to the Origin and
reference frame f0 to reference frame f1.
Both f0 and f1 could default to [[0,0,1],[0,1,0],[1,0,0]]. A more
complicated version might include Origin0 and Origin1,
both of which might default to [0,0,0].
In my experience, these *can* be done by the user, given the current
translate(), rotate(), and scale(), but
they require enough calculation that it’s best included in the core.
I’m not *at all* happy with the current rotate - with it’s non-standard
(to my eye) convention of performing
several rotations in a fixed order. I try not to use it that way (using
several distinct rotate() calls, instead
because I find that the resulting code is easier (for me) to read. No
doubt a personal failing.
While I’m listing “druthers”, I’d like to suggest full support for 4x4
transformation matrices and 4x1
points and vectors - but, I can also make strong arguments on the opposing side.
At bottom, all you really need is full support for 4x4 and 4x1 objects
(creation, manipulation, all the standard
operators), plus a well designed (user level) package that hides all of
that from the designer.
The current crop of standard operators represents the “easy to implement”
and “all you need for simple objects” level of ambition, with a few (poorly
thought out, in my view) “optimizations” for common cases.
For more complex modeling, the x,y, and z axes lose their special status,
and it becomes much more
useful to have, for example, the more powerful “rotate about an arbitrary
axis”, or “map this reference frame to that reference frame”. Not every
interesting object is, or can be, “axis aligned”, esp. if we are talking
about
current 3D printing technology instead of lathes or simple self-supporting geometry.
On the other side of the coin, I would like at all costs to RESIST the
temptation to take “sphere” down the same
route as “cube”. I *much* prefer cubical cubes and spherical spheres, and
I think it’s much cleaner and clearer
to create a sphere and then separately squash it. If possible, I would
roll back the abomination of a “cube” with
three different dimensions!
And finally (rant #32) - there seems to me to be a continuing tension
between those who would prefer a read-only
language (like APL) for it’s lapidary elegance, and those who would prefer
verbose, human-readable code.
I’m caught in the middle. I adopted OpenSCAD for my own work precisely
because it was lean and mean - a “scripting” language. The history of
“scripting” languages is that when they expand into general purpose
“programming” languages, they become bloated and fail. Instead of growing
OpenSCAD one convenient feature at a time, it may be time
to consider TWO new languages: a) a stripped back scripting language
intended for simple model description, and b) a new language, designed from
the start to be a programming language which includes CSG and related
topics as first class
entities. In my opinion, OpenSCAD is *right now* at the point where
future additions may hurt rather than help.
Note that I take no position on “functional” vs “procedural” - I’m happy
with either choice (but unhappy with
poorly motivated blends).
Just my opinion, for what it’s worth.
--
Kenneth Sloan
I think the reason for the rotations to be always around an axis that
necessarily crosses [0,0,0] has a tight relation to the fact that rotate()
capabilities are mapped to the capabilities of a rotation transform matrix
as we learn in linear algebra.
Post by runsun
Post by Marius Kintel
Rotate is declared like this: rotate(angle, axis=[0,0,1])
Is this default recently added? I am using 2014-03-11 snapshot on Linux
rotate( 360$t ) // (a)
rotate( 360$t, axis=[0,0,5] ) // (b)
rotate( 360$t, axis=[0,5,0] ) // (c)
rotate( 360$t, axis=[5,0,0] ) // (d)
They behave exactly the same, all rotate about the z-axis, as though the
axis argument doesn't have any effect.
IMHO, the existence of an argument like axis in a "rotate" action would
indicate that a rotation about "any" axis is allowed. But if axis takes only
one vector like [0,0,1], even if we can make it to work with [0,1,1],
[1,1,0],[1,0,1] and [1,1,1], it is still limited to "rotating about an axis
that passes through [0,0,0]."
So, ideally, it could also be made to take a 2-pointer like
[[2,1,0],[1,-1,0]] such that the rotation can be made about any axis in the
space.
-----
Runsun Pan, PhD
--
http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8270.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Oskar
2014-06-05 20:48:06 UTC
Permalink
Hi Kenneth,

Long post – I'll hopefully not write something even longer. :-)
Post by Kenneth Sloan
If rotation is to be generalized (or another, more powerful version created), I would
rotate(a=angle, p0=[x0,y0,z0], p1=[x1,y1,z1])
Where p0 can be omitted (default = [0,0,0])
and p1 can be omitted (default = [0,0,1])
I think a better parametrization of the directed line that defines the axis
of rotation in this case is _point_ and _direction_. In that case, the
default values make more sense as either or both could be omitted. It would
also be analogous to and compatible with the 2D case of rotation_angle and
center_of_rotation.
Post by Kenneth Sloan
map(f0=[v00,v01,v02], f1=[v10,v11,v12])
which applies a transform which maps the Origin to the Origin and
reference frame f0 to reference frame f1.
Both f0 and f1 could default to [[0,0,1],[0,1,0],[1,0,0]]. A more
complicated version might include Origin0 and Origin1,
both of which might default to [0,0,0].
Maybe it would make sense to have a more explicit built in (or at least
standardized) form of reference frames. Some scad libraries make use of
custom reference frames for attachment points and similar. By standardizing
that, there could also be some GUI interaction possibilities.
Post by Kenneth Sloan
In my experience, these *can* be done by the user, given the current
translate(), rotate(), and scale(), but
they require enough calculation that it’s best included in the core.
I personally often need a functional form of all transformations (i.e.
functions returning 4x4 matrices). With the separate namespaces OpenSCAD
currently has, they could even be defined with the same names. I.e.

translate(a) rotate(b) scale(c)

is identical to

multmatrix(translate(a) * rotate(b) * scale(c))

These are useful for among other things calculating distances and global
coordinates for points expressed in different reference frames.
Post by Kenneth Sloan
I’m not *at all* happy with the current rotate - with it’s non-standard
(to my eye) convention of performing
several rotations in a fixed order. I try not to use it that way (using
several distinct rotate() calls, instead
because I find that the resulting code is easier (for me) to read. No
doubt a personal failing.
I agree. I’ve never liked Euler angle notation and all my 3D rotate() calls
involves a vector with two zero elements.
Post by Kenneth Sloan
While I’m listing “druthers”, I’d like to suggest full support for 4x4
transformation matrices and 4x1
points and vectors - but, I can also make strong arguments on the opposing side.
At bottom, all you really need is full support for 4x4 and 4x1 objects
(creation, manipulation, all the standard
operators), plus a well designed (user level) package that hides all of
that from the designer.
Full (projective) 4x4 matrices are a bit tricky to support due to to the
degeneracies they can create in the geometry. For example, a cone could be
expressed as a 3D projective transformation of a cylinder, but due to
floating point inexactness, one could get a minimal non-manifold vertex at
the tip. 3D affine transformations are already fully supported (i.e.
arbitrary 3x4 matrices, or 4x4 matrices with the last row starting with
three zeros), and they get you a long way.

For example, one transformation that most likely is underused is shearing,
and it can be implemented simply as follows:

function shear(xy=0,yz=0,xz=0) =
[[1,xy,xz,0],[0,1,yz,0],[0,0,1,0],[0,0,0,1]];
module shear(xy=0,yz=0,xz=0) multmatrix(shear(xy,yz,xz)) children();

2d example:
shear(0.75) square();

3d:
shear(xy=0.5, xz=0.5) cube();
Post by Kenneth Sloan
On the other side of the coin, I would like at all costs to RESIST the
temptation to take “sphere” down the same
route as “cube”. I *much* prefer cubical cubes and spherical spheres, and
I think it’s much cleaner and clearer
to create a sphere and then separately squash it. If possible, I would
roll back the abomination of a “cube” with
three different dimensions!
Remember: It’s spelled ”cube”, but pronounced ”cuboid”. It’s an abbreviation
:-)
Post by Kenneth Sloan
And finally (rant #32) - there seems to me to be a continuing tension
between those who would prefer a read-only
language (like APL) for it’s lapidary elegance, and those who would prefer
verbose, human-readable code.
I’m caught in the middle. I adopted OpenSCAD for my own work precisely
because it was lean and mean - a “scripting” language. The history of
“scripting” languages is that when they expand into general purpose
“programming” languages, they become bloated and fail. Instead of growing
OpenSCAD one convenient feature at a time, it may be time
to consider TWO new languages: a) a stripped back scripting language
intended for simple model description, and b) a new language, designed
from the start to be a programming language which includes CSG and related
topics as first class
entities. In my opinion, OpenSCAD is *right now* at the point where
future additions may hurt rather than help.
I fully agree that leanness and simplicity are key strengths of OpenSCAD
– strengths that we should strive to preserve. And I also agree that
OpenSCAD is currently at a crossroads – it could stay as it is, focus on
robustness and speed; become well polished but limited. On the other
extreme, it could evolve into a full featured programming language
specialized on geometric description and computation. I think both ways
would be wrong.

We should not lose sight of what problems OpenSCAD is primarily designed to
solve, and what users it caters for. I assume that a major and narrowly
defined use-case for OpenSCAD is designing functional physical objects
– primarily for FDM/FFF manufacturing. But even for this use case, there are
a number of things that are either missing or much harder to accomplish than
they should. Off the top of my head, a few examples are:

* Fillets – a functional element that distributes stress and thereby
increases strength. Very hard to accomplish today.
* Sweep volumes – use cases are for example subtracting the interference
volume of a moving mechanical part. No proper way exists today.
* Rounds and chamfers – maybe primarily aesthetic, but also serves
functional uses. Hard to effectively realize today.
* ”Lofted” shapes – a shape that gradually transforms from one profile to
another. Has useful functional properties.

Then we have interesting opportunities for creative experimentation.
Algorithmically defined shapes, Voronoi tessellated mesh surfaces,
algorithmically generated subelements, constraint based parametric creation
of complex objects, etc.

Some of these features would need to be developed specifically – others can
be enabled via extending the functional language. Currently (version
2014.03), the functional language lacks only very minor things to be
dramatically more useful, so why not add these? In my view, the critical
things are the let()-expression, concat(), and guaranteed tail call
optimization. Apart from that, what are the minor changes to the language we
need to make in order to support other wanted features? Sweep volumes and
generalized extrusion needs ways to specify space paths. There are probably
an infinite number of ways to parametrize such paths, so the most
reasonable approach would be to leave as much of the expressive power to
user-space. To fully support that, function values and list comprehensions
makes things much easier for the user.

Apart from these features, my personal wish list contains improved speed and
scriptable export() statements. Both of these would save me a lot of time
and manual work.

As for the rest of your rant #32, I’m not sure where you find the crowd
preferring APL-like syntax. I have nothing against lapidary elegance of
course, but it should not be at the expense of readability. IMHO, OpenSCAD
should remain at least just as approachable to new users and non-programmers
as it is today.

I’m not sure there is much to gain by going in the opposite direction –
stripping away features and further simplifying the language unless the main
work flow is to use OpenSCAD only as a geometry evaluation tool – leaving
geometry definition to something else.
Post by Kenneth Sloan
Note that I take no position on “functional” vs “procedural” - I’m happy
with either choice (but unhappy with
poorly motivated blends).
My primary motivation for a purely functional language with immutable
”variables” is that it both simplifies things tremendously under the hood,
and at the same time allows for very powerful and simple to implement
optimizations, such as parallelization and memoization. Memoization that
could be extended to be both persistent and even distributed. And
interestingly – at least for the use cases of defining geometry – the purely
functional single assignment paradigm doesn't feel limiting at the least.

By the way, which parts of the recently discussed proposals do you consider
poorly motivated blends? What would be your ideal direction for OpenSCAD?

Best,

Oskar




--
View this message in context: http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8285.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Peter Falke
2014-06-05 22:41:01 UTC
Permalink
Presently I work like this:

I define 3 vectors (norm vectors?)

xaxis=[1,0,0];
yaxis=[0,1,0];
zaxis=[0,0,1];

and then do my translation like this:

translate(-h/2*zaxis)cube([a,a,h],true);

This works fine and is well readable.
(And I dislike typing brackets .-))

After reading this discussion I like the following best:
expand translate to accept value arguments like this:

translate(x=value)
translate(y=value)
translate(z=value) identical with translate(value)


The only advantage of this change is to make writing down simple
translations easier.

Pros:
-will not break existing code
-easy to implement
-easy to write code

Cons:

-

Sincerely,

TakeItAndRun
Post by Oskar
Hi Kenneth,
Long post – I'll hopefully not write something even longer. :-)
Post by Kenneth Sloan
If rotation is to be generalized (or another, more powerful version created), I would
rotate(a=angle, p0=[x0,y0,z0], p1=[x1,y1,z1])
Where p0 can be omitted (default = [0,0,0])
and p1 can be omitted (default = [0,0,1])
I think a better parametrization of the directed line that defines the axis
of rotation in this case is _point_ and _direction_. In that case, the
default values make more sense as either or both could be omitted. It would
also be analogous to and compatible with the 2D case of rotation_angle and
center_of_rotation.
Post by Kenneth Sloan
map(f0=[v00,v01,v02], f1=[v10,v11,v12])
which applies a transform which maps the Origin to the Origin and
reference frame f0 to reference frame f1.
Both f0 and f1 could default to [[0,0,1],[0,1,0],[1,0,0]]. A more
complicated version might include Origin0 and Origin1,
both of which might default to [0,0,0].
Maybe it would make sense to have a more explicit built in (or at least
standardized) form of reference frames. Some scad libraries make use of
custom reference frames for attachment points and similar. By standardizing
that, there could also be some GUI interaction possibilities.
Post by Kenneth Sloan
In my experience, these *can* be done by the user, given the current
translate(), rotate(), and scale(), but
they require enough calculation that it’s best included in the core.
I personally often need a functional form of all transformations (i.e.
functions returning 4x4 matrices). With the separate namespaces OpenSCAD
currently has, they could even be defined with the same names. I.e.
translate(a) rotate(b) scale(c)
is identical to
multmatrix(translate(a) * rotate(b) * scale(c))
These are useful for among other things calculating distances and global
coordinates for points expressed in different reference frames.
Post by Kenneth Sloan
I’m not *at all* happy with the current rotate - with it’s non-standard
(to my eye) convention of performing
several rotations in a fixed order. I try not to use it that way (using
several distinct rotate() calls, instead
because I find that the resulting code is easier (for me) to read. No
doubt a personal failing.
I agree. I’ve never liked Euler angle notation and all my 3D rotate() calls
involves a vector with two zero elements.
Post by Kenneth Sloan
While I’m listing “druthers”, I’d like to suggest full support for 4x4
transformation matrices and 4x1
points and vectors - but, I can also make strong arguments on the
opposing
Post by Kenneth Sloan
side.
At bottom, all you really need is full support for 4x4 and 4x1 objects
(creation, manipulation, all the standard
operators), plus a well designed (user level) package that hides all of
that from the designer.
Full (projective) 4x4 matrices are a bit tricky to support due to to the
degeneracies they can create in the geometry. For example, a cone could be
expressed as a 3D projective transformation of a cylinder, but due to
floating point inexactness, one could get a minimal non-manifold vertex at
the tip. 3D affine transformations are already fully supported (i.e.
arbitrary 3x4 matrices, or 4x4 matrices with the last row starting with
three zeros), and they get you a long way.
For example, one transformation that most likely is underused is shearing,
function shear(xy=0,yz=0,xz=0) =
[[1,xy,xz,0],[0,1,yz,0],[0,0,1,0],[0,0,0,1]];
module shear(xy=0,yz=0,xz=0) multmatrix(shear(xy,yz,xz)) children();
shear(0.75) square();
shear(xy=0.5, xz=0.5) cube();
Post by Kenneth Sloan
On the other side of the coin, I would like at all costs to RESIST the
temptation to take “sphere” down the same
route as “cube”. I *much* prefer cubical cubes and spherical spheres,
and
Post by Kenneth Sloan
I think it’s much cleaner and clearer
to create a sphere and then separately squash it. If possible, I would
roll back the abomination of a “cube” with
three different dimensions!
Remember: It’s spelled ”cube”, but pronounced ”cuboid”. It’s an
abbreviation
:-)
Post by Kenneth Sloan
And finally (rant #32) - there seems to me to be a continuing tension
between those who would prefer a read-only
language (like APL) for it’s lapidary elegance, and those who would
prefer
Post by Kenneth Sloan
verbose, human-readable code.
I’m caught in the middle. I adopted OpenSCAD for my own work precisely
because it was lean and mean - a “scripting” language. The history of
“scripting” languages is that when they expand into general purpose
“programming” languages, they become bloated and fail. Instead of
growing
Post by Kenneth Sloan
OpenSCAD one convenient feature at a time, it may be time
to consider TWO new languages: a) a stripped back scripting language
intended for simple model description, and b) a new language, designed
from the start to be a programming language which includes CSG and
related
Post by Kenneth Sloan
topics as first class
entities. In my opinion, OpenSCAD is *right now* at the point where
future additions may hurt rather than help.
I fully agree that leanness and simplicity are key strengths of OpenSCAD
– strengths that we should strive to preserve. And I also agree that
OpenSCAD is currently at a crossroads – it could stay as it is, focus on
robustness and speed; become well polished but limited. On the other
extreme, it could evolve into a full featured programming language
specialized on geometric description and computation. I think both ways
would be wrong.
We should not lose sight of what problems OpenSCAD is primarily designed to
solve, and what users it caters for. I assume that a major and narrowly
defined use-case for OpenSCAD is designing functional physical objects
– primarily for FDM/FFF manufacturing. But even for this use case, there
are
a number of things that are either missing or much harder to accomplish than
* Fillets – a functional element that distributes stress and thereby
increases strength. Very hard to accomplish today.
* Sweep volumes – use cases are for example subtracting the interference
volume of a moving mechanical part. No proper way exists today.
* Rounds and chamfers – maybe primarily aesthetic, but also serves
functional uses. Hard to effectively realize today.
* ”Lofted” shapes – a shape that gradually transforms from one profile to
another. Has useful functional properties.
Then we have interesting opportunities for creative experimentation.
Algorithmically defined shapes, Voronoi tessellated mesh surfaces,
algorithmically generated subelements, constraint based parametric creation
of complex objects, etc.
Some of these features would need to be developed specifically – others can
be enabled via extending the functional language. Currently (version
2014.03), the functional language lacks only very minor things to be
dramatically more useful, so why not add these? In my view, the critical
things are the let()-expression, concat(), and guaranteed tail call
optimization. Apart from that, what are the minor changes to the language we
need to make in order to support other wanted features? Sweep volumes and
generalized extrusion needs ways to specify space paths. There are probably
an infinite number of ways to parametrize such paths, so the most
reasonable approach would be to leave as much of the expressive power to
user-space. To fully support that, function values and list comprehensions
makes things much easier for the user.
Apart from these features, my personal wish list contains improved speed and
scriptable export() statements. Both of these would save me a lot of time
and manual work.
As for the rest of your rant #32, I’m not sure where you find the crowd
preferring APL-like syntax. I have nothing against lapidary elegance of
course, but it should not be at the expense of readability. IMHO, OpenSCAD
should remain at least just as approachable to new users and
non-programmers
as it is today.
I’m not sure there is much to gain by going in the opposite direction –
stripping away features and further simplifying the language unless the main
work flow is to use OpenSCAD only as a geometry evaluation tool – leaving
geometry definition to something else.
Post by Kenneth Sloan
Note that I take no position on “functional” vs “procedural” - I’m happy
with either choice (but unhappy with
poorly motivated blends).
My primary motivation for a purely functional language with immutable
”variables” is that it both simplifies things tremendously under the hood,
and at the same time allows for very powerful and simple to implement
optimizations, such as parallelization and memoization. Memoization that
could be extended to be both persistent and even distributed. And
interestingly – at least for the use cases of defining geometry – the
purely
functional single assignment paradigm doesn't feel limiting at the least.
By the way, which parts of the recently discussed proposals do you consider
poorly motivated blends? What would be your ideal direction for OpenSCAD?
Best,
Oskar
--
http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8285.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
--
***@googlemail.com <***@rohrbach.de>

P.S. Falls meine E-Mail kÌrzer ausfÀllt als Dir angenehm ist:
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu
schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.

P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.

Enjoy!
MichaelAtOz
2014-06-05 07:27:43 UTC
Permalink
Post by Peter Falke
Would it be possible to modify the translate command so that a simple value
as argument would result in a z-translation.
module tranZ(z=-0.05 translate([0,0,z]) children();




--
View this message in context: http://forum.openscad.org/translate-10-like-rotation-90-tp8253p8257.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Stefaan Claes
2014-06-05 11:43:08 UTC
Permalink
Post by Peter Falke
Would it be possible to modify the translate command so that a simple value
as argument would result in a z-translation.
Very much like rotation(90) rotates around the z axis or cube(10) produces a
"square" cube.
Sincerely,
TakeItAndRun
--
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu
schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.
Enjoy!
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Stefaan Claes
2014-06-05 11:51:51 UTC
Permalink
What about e.g. sphere(r=[5,5,4], $fn=20);
to get a squashed sphere?

i.e. the same as
scale([1,1,4/5]) { sphere(r=5, $fn=20); }

just an idea...

regards,
Stefaan
Post by Peter Falke
Would it be possible to modify the translate command so that a simple value
as argument would result in a z-translation.
Very much like rotation(90) rotates around the z axis or cube(10) produces a
"square" cube.
Sincerely,
TakeItAndRun
--
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu
schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.
Enjoy!
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Lester Hall
2014-06-05 11:58:03 UTC
Permalink
I have often wanted to do exactly this, as Stefaan says. The alternative,

scale([5, 5, 4])
sphere(r=0.5, $fn=20);

works fine but is slightly clumsy and less readable.

By the way, I have mostly skimmed over these discussions and I find it refreshing and pleasant to know that the future of OpenSCAD, despite it’s many peculiarities already, is in good hands! I plan to use this language for a loooong time, so let’s make it a good one!!! :)

Les
Post by Stefaan Claes
What about e.g. sphere(r=[5,5,4], $fn=20);
to get a squashed sphere?
i.e. the same as
scale([1,1,4/5]) { sphere(r=5, $fn=20); }
just an idea...
regards,
Stefaan
Post by Peter Falke
Would it be possible to modify the translate command so that a simple value
as argument would result in a z-translation.
Very much like rotation(90) rotates around the z axis or cube(10) produces a
"square" cube.
Sincerely,
TakeItAndRun
--
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu
schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.
Enjoy!
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Continue reading on narkive:
Loading...