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

["George Mills" <mills@softronix.com>]

You are correct, restoring position using SETPOS while in 3D
mode will not work. I had considered making POS, SETPOS, TOWARDS,
DISTANCE, and even HEADING use 3 argument vectors when in 3D Mode
but decided that would still cause problems with a lot of 2D code
and could break anyway if I did this.

One thing that is very powerful about Brians engine is you
can implement your suggestion #2.

to myperspective
perspective
make "redefp "true
erase "pos
erase "setpos
copydef "pos "posxyz
copydef "setpos "setposxyz
end

I think I had considered your option #1 and have not ruled out
adding it. I think your basically saying after each ROLL or PITCH
(even perhaps SETXYZ) that it define a new 2D origin in which, where
ever the turtle is currently pointing after one of these commands
defines HEADING = 0.

I have an interesting idea, if ROLL and PITCH rotated the world
around a fixed turtle (rather than move a turtle with in a fixed
world) then the turtle would remain on the XY plane and SETPOS, POS
would be correct even in 3D. In some respects it the same as
above.

I also agree that in general absolute coordinates are not
nearly so powerful as relative and relative coordinate 2D
code should work fine.

The new release (which there is a beta kit available of) handles
3D solids and does cache the polygons. So when you change the view
you do not have to redraw.

Keep in mind my goal was to make the transition from 2D to 3D
as clean as possible. Most of what a 2D Logo programer has learned
applies to 3D and most Logo programers and programs do use
relative coordinates, so most 2D code does work in 3D and what
does not usually only requires minor modification (which would be
a learning experience).

-----Original Message-----
From: Tommaso Russo <trusso@tin.it>
To: George Mills <mills@softronix.com>
Cc: logo-l@gsn.org <logo-l@gsn.org>
Date: Thursday, July 09, 1998 11:46 AM
Subject: LOGO-L> Local and global 3D geometry (was:RE: 3D Logo source ?)


>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.
>

---------------------------------------------------------------
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.