LOGO-L> Local and global 3D geometry (was:RE: 3D Logo source ?)

[Tommaso Russo <trusso@tin.it>]

George Mills wrote about 3D capabilities of MSWlogo:
>Please try the program, I believe 20 minutes
>with the program is worth a 1000 words.

Done: I've spent far more than 20 min. Superb work! Changing the
viewpoint gives possibilities simply impressive. Make it possible
without have to redraw the pictures, and programming a fligth simulator
becomes a task for age 10 or less. My children (8 and 11) have been
astonished by the stereo vison of the shuttle, and the older asked for a
stereo Marklin train. Do it yourself, I've answered, here is the right
tool. He will work on it for some next years.
(By the way: a space laboratory in this Science Park, CARSO, has
developed a stereo color television (to be used on the real shuttle, to
control robot arms working outside) using a PC screen that gives the two
visions polarizing light alternatively, horizontally and vertically, 50
times a second. The glasses needed are just polaroid with one lens
rotated 90 degrees. I'm thinking about a stereo MSWlogo with no loss of
colors...)

>>If we start from home, wich value of ROLL gives
>>SETORIENTATION TOWARDSXYZ [100 100 100] ?
>I don't follow, A ROLL in of itself is not enough to define
>such an orientation.

I apologize for my poor english, the right phrasig of the question had
to be:
"wich value of ROLL is given by SETORIENTATION...? "
hovever, the question remained still wrong, because it assumed rightroll
affecting only roll.

Only now I've realized the meaning of roll, pitch and heading in
MSWlogo: they output the angles a turtle at home must rightroll, uppitch
ad rigth IN THIS ORDER to gain current orientation. It was not clear, is
not documented and can be understood only reading the library procedure
setorientation.

The righ question was: after a SETORIENTATION TOWARDSXYZ and FORWARD
DISTANCEXYZ to gain the corner of a cube, the pilot get lost: how can
she/he know how to downpitch, rigthroll and turn to draw the cube, if
there are infinite triplets of ORIENTATION that could have carried
her/hime there? She/he is forced to use TOWARDSXYZ again.

I' ve seen that TOWARDSXYZ returns always zero as item 2 (pitch), but
this is of course an arbitrary choice hardwired in the C++ or assembler
code. The point is that TOWARSXYZ is not designed to be used intermixed
with rightroll, uppitch and right: but this could be done, and the
result would be a side effect of this particular implementation of
TOWARDSXYZ, not documented at the instruction level.

However, the point I've touched putting the wrong question is even more
general. Experimenting with it, I discovered that MSWlogo 6.3 has a bug
in it that cannot be fixed acting just on the code. Please be patient
and leave me start from the egg.

I' ve always appreciated the turtle (2D) geometry based on FD and RT
because it is local (differential) rather than global and this is what
makes pictures drawn by turtle procedures movable around just moving the
turtle before calling them. Transparent procedures (i.e. leaving the
turtle in a final state identical to the initial one) are best in
absolute, because allow to insert or delete components of a picture just
adding or removing calls (these are not my considerations, I thanks
Brian Harvey read in early '80).

Now, IMHO inspecting the turtle's global coordinates by pos and heading
are good educational tools, but setting them by setpos and setheading
are BAD langage features, for they can (if not used just to restore
previously saved properties) destroy locality and transparency. 

***In 3D, the situation is even worse, because the values of roll, pitch
and heading have meanings hard to grasp, and towardsxyz returns a
triplet picked up among an infinity suitable for the purpose***.

However I recognize that saving and later restoring a pos or a heading
can be a valid help in making transparent a procedure when the
programmer get lost after several FDs, RTs and so, and closing the
polygon she/he is drawing requires complex trigonometry.

My solution has been up to now: "USE THE GOOD FEATURES OF A LANGUAGE;
AVOID THE BAD ONES" (Kerighan and Plauger - The Elements of Programming
Style -  Mc Graw Hill, New York, 1978)

I.E.: never use setpos or setheading by themselves. Encourage rather the
following programming style:

to complexpicture
rememberheading
rememberpos
fd .., rt .., ....
restorepos
restoreheading
end

                 where, as you can guess,

to rememberheading
IF NOT NAMEP "savedheadings [make "savedheadings []]
make "savedheadings fput heading :savedheadings
end

to rememberpos
IF NOT NAMEP "savedposs [make "savedposs []]
make "savedposs fput pos :savedposs
end

to restoreheading
setheading first :savedheadings
make "savedheadings bf :savedheadings
end

to restorepos
setpos first :savedposs
make "savedposs bf :savedposs
end

(I guess you had this in your mind when you wrote:
>SETORIENTATION is designed mainly for 2 things.
>To work with TOWARDSXYZ and to be able to save and
>restore your ORIENTATION like you save and restore HEADING).

***BUT (this is the bug):
*************************
"complexpicture" DOES NOT WORK PROPERLY after a perspective and some up,
rightroll and fd!***

Actually, restoreheading works correctly (because you have purposely
choosen the right order in defining orientation) but restorepos restores
only global x and y, leaving z as it stands, and so does not close the
2D polygon in the 3D space. And the same (getting a quite different
position) happens using setheading towards :originalpos and fd distance
:originalpos.

Possible solutions i can see:

1) -  aligned with your philosophy, "a square remains a square even in
3D": after a perspective command, POS. SETPOS, TOWARDS, DISTANCE should
work with 2 coordinates lying in the plane defined by roll and pitch,
with the Y axis along the direction of zero heading. This had the
advantage that any 2D paint would work also in 3D,  but also the
inconsistency that POS would return two values different from the first
two returned by POSXYZ. 

2) - give up with POSXYZ and SETPOSXYZ - after a perspective command,
POS and SETPOS should take their place working with 3 items rather than
2, and so should do TOWARDS and DISTANCE. But, (last POS) would loose a
defined meaning, instructions would have different behavior depending on
the environment, and 2D paints done using absolute coordinates would
remain always horizontal.

3) - most radical - discourage use of global coordinates. Define
rememberpos (not xyz), rememberheading, rememberorientation and the
corresponding restore as primitives, and make setpos, setheading,
setorientation, towards, distance "deprecated" (i.e. still working for
some more releases, but producing an annoying warning message). Pos,
posxyz, heading and orientation could survive as inspection tools.

I see problems in each of them, but the matter is very complex and, as
long I can see, preserving in 3D all programming styles accepted by 2D
logo is impossible, just because intermixing of local and global
geometry is allowed. A choice must be made. The choice implicit in
version 6.3 of MSWlogo makes the intended usage of pos and setpos (to
save and restore 2D positions) not working properly when used for a 2D
picture that one wants to draw onto the side of a 3D cube. I see this as
a major inconsistency. For coherence and elegance, I would prefer the
third solution, but it would make illegal a lot of logo programs now
working. May be the first solution is the "less pain" one, but I suspect
flawns in it that at present I can't see.

I've not answers at hand. Sorry.

Opinions from the list? 
-------------
Tommaso RUSSO
Abitazione: 
  Strada per Longera 4/1 I-34128 Trieste
  +39(40)568.777
  trusso@tin.it
Ufficio:
  Responsabile Progetto Reti - AREA Science Park
  Padriciano 99 I-34012 Trieste
  +39(40)375.5259 
  Tommaso.Russo@Area.Trieste.It
---------------------------------------------------------------
Please post messages to the Logo forum to logo-l@gsn.org.  Mail
questions about the list administration to logofdn@gsn.org.  To
unsubscribe send    unsubscribe logo-l    to majordomo@gsn.org.