Animator: an object-oriented approach

Rochester Institute of Technology

RIT Scholar Works

Theses Thesis/Dissertation Collections

1987

Animator: an object-oriented approach

Stephen Kurtz

Follow this and additional works at:http://scholarworks.rit.edu/theses

This Thesis is brought to you for free and open access by the Thesis/Dissertation Collections at RIT Scholar Works. It has been accepted for inclusion in Theses by an authorized administrator of RIT Scholar Works. For more information, please [email protected].

Recommended Citation

Rochester Institute of Technology School of Computer Science and Technology

Animator

An Object-Oriented Approach to the

Creation and Direction of Computer Animated Actors by

Stephen Kurtz

A thesis,submitted to

The Faculty of the School of Computer Science and Technology,

inpanial fulfillment of the requirements for the degree of Master of Sciencein Computer Science

Approved by:

A thesis,submitted to

The Faculty of the School of Computer Science and Technology,

Title of Thesis: Animator: An Object-Oriented Approach to the Creation and Direction of Computer Animated Actors.

I hereby grant permission to the Wallace Memorial Library of RIT, to reproduce this thesis in whole or in part. Any reproduction will not be for commercial use or profit.

1. Preliminary Information

1.1. Abstract

Object-oriented programming is presented as a paradigm for developing interactive systems for computer animation. Object types, evolved conceptually from graphics turtles, are implemented to provide the animator with familiar metaphors for the specification of motion in three-dimensional space. The intention is to create objects that can represent actors, cameras, and decor that the user can direct and animate in a relatively intuitive manner. Vector and turtle objects support the actors, which respond to messages to orient, accelerate and draw themselves on the screen. The MacApp object libraries are used to implement the standard Macintosh user interface and a unit is developed which implements vectors, actors and three-dimensional graphics turtles as objects. The object-oriented approach encourages a conceptual consistency in the external and internal interfaces and is intended to facilitate the development of extensible characters and tools through the cooperative efforts of animators and programmers.

1.2. Key Words and Phrases

1.3. TableofContents

1. _Preliminary Informatioa 2

1.1 Abstract 2

1.2 _Key WordsandPhrases 2

1.3 TableofContents 3

2. Proposal 7

3. IntroductionandBackground 9

3.1 Computer Animation 9

3.2 Object-Oriented_ProgrammingSystems_(OOPS) 9

3.3 Actor BasedSystemsandtheLogoTurtle 10

3.4 Animator 11

4. Vectors 12

4.1 TVectorObject Type 12

4.2 Thedatafields 12

4.3 _{Methods for assigning}values. 12

4.4 A geometricinterpretation 13

4.5 Vectorcoordinates 14

4.6 The geometryof vector addition 14

4.7 Thecomponents fX,fY andfZ 15

4.8 Theimplementationof vectoraddition ₁₅

4.9 The implementationofthe scalarproduct ₁₆

4.11 Thedotproduct 17

4.12 ImplementationoftheTVectorObject Type 18

5. Local Coordinate Systems andtheTLCS ObjectType 20

5.1 The TLCS Object Type 20

5.2 _fYaw,fPitchandfRoll 21

5.3 fLensandfitsView 21

5.4 Allocation and assignment 22

5.5 _Deepand shallow methods 22

5.6 Methodsofrotation 22

5.7 The_TiltUp method. 23

5.8 _Moving 23

5.9 ImplementationofTLCS Object Type 24

6. The Turtle: aVector-BasedGraphics Pen 29

6.1 Turtlegraphics 29

6.2 _Drawingan actor 30

6.3 TTurtleobjecttype- datafields 30

6.4 Projectionontotheplane 31

6.5 The geometry ofTTurtle. Project 31

6.6 Perspectiveprojection 32

6.7 _Drawingwith the turtle 32

6.8 _Overridinginheritedmethods 33

7. Actors: aTemplate for PicturesthatMove 39

7.1 An animatedobjecttype 39

7.2 TActordata fields 40

7.3 _UpdatingthePolygon 40

7.4 _{Overriding DrawPoly} 41

7.5 _Movingthepicture 41

7.6 Navigation in 3-D space 42

7.7 DescendantsofTActor 43

7.8 Commandsastext 44

7.9 Implementation ofTActorObject Type 45

8. Animator: a stageforthe actors 54

8.1 Thestagefortheactors 54

8.2 _Initializingactors thecast 54

8.3 _Drawingtheview 55

8.4 _Selectingobjects - _{mousecommands} 55

8.5 Thecontrols menu 56

8.6 _Simulating themove 56

9. Conclusions 57

9.3 Lessons Learned 57

9.2 Future ExtensionsofAnimator'sObject Types 57

9.3 Extensions to theSystem 58

10. Appendix: ObjectPascal 59

10.2 Methodsor messages 59

10.3 Inheritance. 60

10.4 Instancesof an objecttype 60

10.5 _MacAppunits 61

10.6 TApplicationandTDocument 61

10.7 TFrameandTWindow 62

10.8 TView 62

10.9 TCommand 63

2. Proposal

Althoughthe real-time creation and_display ofanimated sequences in three-dimensional

space remains a problem forthe _future, a greatdeal has been done to assist the animator in creating animated films frame _by frame. Currently, computers are used in the

interactive creation of_objects,the generation ofsuccessiveimages to simulate motion or

other_{transformations,} andthe control ofhardware inthe production andpost-production

stages of_making afilmor video. Thisthesis willfocus on the problems _surrounding the

specification of motion_by theanimator.

Many animators are interested in _using the computer as a _tool, but few are prepared to become programmers in the process. The resistance to the mathematical _modeling of

objects and motion is in part due to the nature of the work _involved, but of equal importance for many animators is the conviction that traditional animation owes its

appeal not to the _accuracy with which it portrays the physical world, but rather to the

expressiveness ofthe artist/animator. The goal _{for many is} not to simulate the laws of

motion butratherto simulate traditional animation. User-orientedpaintsystemsdonot as

yet provide the animator with the tools to _{describe satisfying} movement in a

three-dimensionalspace.

Iam_{particularly interested inworking}towardaninteractive environmentfortheanimator

that _{is conceptually} compatible with an extensible object-oriented _programming language. The system would be modal, providing separate environments for creating

differentclasses ofobjects _along with the methods that class of objects might support.

My intention is to give the animatordirectcontrol ofthe scene whenever _possible, while

offering the_{extensibility}ofa_programminglanguage in othermodes. Forexample,a new

classof objects might becreatedin one mode, while a new actor orinstance ofthatclass

might be described in a second mode, anda script created for that actor in athird. The

modificationor creation ofthenew classmight require theuse ofa computerlanguage _by the animatoror a_programming co-worker, while the other tasks might be accomplished moredirectly.

I hope to implementa systemin order toexplore methods of_creating objects with parts

that move relative to a local co-ordinate system while the entire object accelerates or

Iwouldliketogive the animatorthe_abilitytosimulate cameramovements and perhaps a

variablelight source. Theemphasis willbe on_providingan intuitiveinterface anduseful feedbackforbothprogrammed andinteractivework.

I intend to use a version of Pascal with support for object-oriented programming. _My

current thought is that objects which can behave like three-dimensional graphics turtles

canbecomeactors in an animation script. I hopetoallow the animatortoexpress changes

in position and rates of change relativeto feedback about current position, _heading and

velocity, rather than _relating these changes to a global coordinate system. _{To my}

knowledge,thisis anovel approachto the specificationof motion.

I would like to acknowledge _{my debt} to Nadia and DanielThalmann, for the guidance and direction supplied _by their_book, Computer_{Animation, Theory} and Practice [Thai

1985] and to Harold Ableson and Andrea _diSessa, for their _{extraordinary text, Turtle}

3. Introduction and Background

3.1. Computer Animation

The creation of animated pictures is a complex andlabor intensiveprocess in which the

computer can _{play many}roles. _Subsequently the term "computer

animation" is not well

defined. Computers are usedinthecreationof_drawings, the simulationofmovement and

in various stages of the production and _editing process. Although the real-time

computation and _display of animated graphics is now possibile for simpler _images, the emphasis here is on the use ofcomputers to animate complex three-dimensional scenes

thatrequire a frame-by-frameapproach.

Systemsthat aidin the _drawing stage_vary from paint systemsthat assistthe artistin the

creation of an image on the _screen, to _modeling systems which can represent

three-dimensional solids as stored data and render stored objects to reflectdifferent points of

view, _lightingand surface attributes. _They alsodiffer markedly in the skills _they require of _{the user,} which _{may vary from} studio _{drawing ability} to advanced _programming

techniques. Different parts of the process are often handled _by different systems and

assigned todifferentmembersofaproduction team.

In the creation of motion the computeris often usedfor in-betweening. In this process

the animatorcreates a setofdrawingscalled_keyframes, whichdepictan object at various stages _during an animated sequence, and the computer creates the drawings that are

required in-between the _keyframes. These systems are modeled after adivision oflabor

thatwas often usedin hand animation. Other systems can generate the framesrequired

to show an _{image moving along} apath described _by the animator. Modeled animation

systems often allow three-dimensional movements to be programmed _by the _animator,

and then create therequired sequence offrames from the storedinformation. Real-time

playback of animated sequences is not yet possible for realistic three-dimensional

animation,but many systems now offer real-time_previewing orfeedbackwith simplified

(wire_frame) images.

Computer animators are involved in the _modeling of complex objects and the

specification of their behavior. Recent work on data abstraction _{[Guttag 77]} has had important implications for computer animation [Thai 83]. _Many of the objects modeled

by animators (i.e. actors, props, cameras, lights, backgrounds) are specific examples of

classes of _conceptually similar objects which interact with each other in a prescribed

manner to create the scenes recorded on film. Object-oriented programming systems

such as SMALLTALK [Gold _84] offer tools _{extraordinarily} well suited to the graphics programmer.

SMALLTALK defines objects as entities _consisting of private _memory and a set of

operations which communicate _{by sending} messages. Each object is an instance of an

abstract data type _{(class), binding} adata structure with a setofoperations (responses to

messages) that constitute the _only access to that data. Classes of objects can be

customized _{by defining} new classes whichrefine and extend the inherited interface and

data structureoftheirdeclaredancestors.

The three concepts that characterize OOPS are: objects, messages and inheritance. Object-oriented programming encourages a _{design strategy} that organizes programs

around a _hierarchy of abstract data types, rather than the refinement of procedural objectives. An object-oriented system evolves as a collection of_objects, customized and

refined _{by descendants, interacting by} message sending. A version ofPascal [Appl _87]

supporting these conceptswas usedtocreatethe graphicsobjectsin Animator.

3.3. Actor Based Systemsand theLogo Turtle

The term

"actor"

[Hewitt _73] describes an object that can send and receive messages.

Hewitt describes a system in which all elements are actors and the _{only activity} is

messages sent between them. _Programming in this system consists of _defining the

responses made _bydifferentclasses ofactorstoreceivedmessages.

Kenneth Kahn created a system called DIRECTOR [Kahn _76] based on an actor that

could be

"asked"

to do all the things a LOGO turtle can do. LOGO [Papert _70] is a

language developed at M.I.T. for use with children. The LOGO turtle responds to the

withproceduraldefinitions. Kahn animated scenes_{by synchronizing}responsesto aclock

with control structureslike AFTER2 MORE TICKS.

Reynolds created the Actor/Scriptor Animation System _(ASAS) at the Architecture Machine _Group at_{M.I.T. [Reynolds 82]. ASAS} messages are lisp-like functions which

rotate an actor's local three-dimensional coordinate system. These messages extend the

LOGO turtle's LEFT andRIGHT commands toinclude _{UP, DOWN,} CLOCKWISE and COUNTER _CLOCKWISE, so that his actors can be animated in three-dimensions. Reynoldsdescribeshis"actor"

as a "chunk" ofcodethatisexecutedonce eachframe.

Also at _M.I.T, Abelson and diSessa described a similar three-dimensional turtle in their

text, Turtle _Geometry [Abel 81]. It was Abelson's description of a three-dimensional turtle and _my experiences _helping students learn to program with turtle graphics, that

inspired Animator.

3.4. Animator

Animator's actors are a class of _objects, with private _information, that respond to

messages and are refined through inheritance _very much like the SMALLTALK objects described in section 3.2 above. _They were developed before I learned about Hewitt's

actors, and should not be confused with them. Animator's actors were designed to be animated or scripted _{interactively} and _easily extended through inheritance _by a

programmer. All actors, graphicsturtles, and cameras descend from a common ancestor from which _they inherittheirgeneral abilitiesto respondto messages to orient and move in space.

Their inherited data structures includealocal coordinate system based on vector objects

4. Vectors

4.1. _{Vectors: TVector Object Type}

The TVector type implements the fundamental vector methods on which all of the

graphics objectsin Animator are based. The definition ofvectors as an object type is

more for the purpose of data abstraction than inheritance (the object type is itself childless),butalldescendantsoftheTLCS (localcoordinate_{system) type}inherit TVector

data fields. The descendants of TLCS include all of Animator's actors, turtles and cameras.

Thevectorrepresentationofsuch quantities asposition, distance,orientation,velocityand

acceleration,is geometrically intuitiveand_analyticallypowerful. The fundamental vector

methodsdescribed in this section supportthe_{drawing, moving} and projection techniques used to _specify and simulate motion in Animator. Where appropriate, a geometric

interpretation willbeoffered. An Object Pascal [Appl _87] implementationoftheTVector

typeis includedat the endofthis section.

4.2. Vectors: thedatafields

A vector in three-dimensional space is an ordered triple of real numbers. _They are represented _by threedata_{fields, fX,}fY andfZ in theTVectorobjecttype. _Early versions

ofAnimatorused MPW Pascal'sFDCED type, which represents areal numberin 4_bytes,

using the first two bytes for the integer and thelast two for the fractional part of a real

number. Precision is adequate and storage is half that of the Pascal REAL type. Arithmetic withnegativevalues was cumbersome and assignment was inconvenient. As

Animatorevolved,computational speed proved morevaluable thanstorage _space,andthe

current version benefits in this regard from using the MPW EXTENDED type to

represent all real values. This 10 byte representation was _chosen, not for the added

precision,but because all representations of real numbersin theStandard Apple Numeric Environmentare convertedto this typebeforecomputation. [Appl _85]

Vectors are represented as objects rather than as Pascal records to provide data

encapsulation. Although Object Pascalpermitsdatafieldsto bereferencedandmodified

much as a programmer might assign a value toa fieldof a Pascal record, this is avoided

inAnimator. Vector data fieldsare altered_{only by calling}the methodsdefined as partof

the TVectorobject type. In this _respect,TVector is atemplate foran abstract datatype.

Direct references to an object's data _fields, which take the form aVector.fX, should be

thoughtofasfunction callsthatreturnthevalue ofthereferenced field.

An instance variable oftype TVector is morelike aPascalpointer(it is actually ahandle

ordouble_pointer) thanaPascal record. The NEW statement allocates spaceforthe data

fields andthe shallow Free_method,which allobjectsinherit from_TObject, issufficientto

deallocate ordisposeofthe allocated memory. Forthe sake ofthe_{following discussion,} assume that firstVector and secondVector are instance variables of type TVector for

which_{memory has been} allocated. Then thestatements or messages:

firstVector.Init(20, 22.5, 25);

secondVector._CopyOf(firstVector);

wouldinitialize theobjectfirstVectorto the triple _{<20, 22.5,}25>andmake secondVector

a _copy of firstVector. Init and CopyOf are methods of the TVector object _type, or

messages that allobjectsofthis type respondto. Thesemethods are defined like Pascal

procedures, but called in the style of a Pascal record_reference, as above. It should be

noted that thestatement:

secondVector : = _firstVector;

would make secondVector a second pointer to the object _already pointed to _by

firstVector,ratherthan a separatecopy.

4.4. Vectors: ageometric interpretation

When interpreted as a directed line segment, vectors can be used todescribe quantities

that have both magnitude and direction, such as _{displacement, velocity, acceleration,} or

AB = _CD

fig. 4.1

Since two vectors _having the same direction and magnitude are equal even when their

initial andterminalpoints_{differ, displacing}avectorin space doesnot changeits valueas

long as the new line segment is parallel to the original (see fig. 4.1). In Animatorthis

property of vectors allows graphics objects and their motion to be described without

referenceto a particular coordinate system. In orderto represent these quantities in the

program and draw them on _{the screen,} a correspondence must be established between

vectorsandthecartesian coordinatesofthree-dimensional space.

4.5. Vectors: vector coordinates

Thecartesian coordinate system associates an ordered_{triple, (X, Y, Z),} of real numbers with each point in three-dimensional _space, whereX is the directeddistance ofthepoint fromthe _YZ-plane,Y is the thedirected distance fromthe_XZ-plane, andZ isthedirected

distance from theXY-plane. We can establish a 1 to 1 correspondencebetween the setof

vector triples, <x, y, z>, and the points of three-dimensional space if we choose the cartesian coordinates _(x, y, z) of_any point todescribe a _{corresponding} vector_A, whose magnitude anddirection allow us todisplaceit inspace, suchthatits initialpointis atthe origin _(0, 0, 0), andits terminal pointis thepoint whosecartesian coordinates are _(x, y,

z). _Anyvector_displaying the required magnitude anddirection is _by definition equal to

A.

(x,y,z) _(x,y,z)

4.6. Vectors: the_geometryof vector addition

Let AandBbevectors. If B isdisplaced sothatits initial pointisthe terminalpoint ofA,

the vector C from theinitial point ofA to the terminalpointofB is the sum ofA and B

(fig.4.3).

fig. 4.3

In section 4.4 we described each ofthe cartesian coordinates as directed distances from

planes through the origin. Let X, Y and Z be vectors _{corresponding} to these directed

distances. _{For any} point _(x,y,z), the _{corresponding} vector A is equal to the sum of the

vectors_X,Yand_Z,which whenplaced endto_end, willtraceapath fromtheorigin to the

point(x,y,z). See fig. 4.2.

4.7. Vectors: thecomponents _fX,fYand fZ

Scalar Product geometric definition: Let A be avector, andc be a scalar_{constant, then}

the scalar productcA is avector with c times the magnitude ofA. The direction ofcA

willbe oppositethatofA ifcis negativeandthe same as thedirectionofAotherwise.

Let X, Y and Z be unit vectors (magnitude = _{1) whose} directions _{correspond to the}

positivex, y andzaxisrespectively. Let A be a positionvector_initiating fromthe origin

and _terminating at the point _(x,y,z) as in the previous section. When we _say that the

vector A is represented _by the triple <x,y,z> we mean that x, y and z are scalar

coefficientsofthe three unitvectors above such thatxX + _yY + zZ = _{A. In this notation}

the vectors _X, Y andZare called a _basis, and the scalarcoefficients _{x, y} andz are called

the components of vector A. The data fields fX, fY and fX of TVector are vector

components.

4.8. Vectors: implementation ofvectoraddition

LetX, Y and Z be vectors and constitute a basis. Let A and B bevectors such that A =

B =_{aX + bY + cZ +dX}

+ eY _+fZ, or_collecting liketerms: A +B = (a+ d)X + (b + e)Y + (c +_f)Z.

The TVector object has two vector addition methods: SumOf and AddTo. If aVector,

bVectorand cVector are oftype TVector then the statement : aVector.SumOf(b_Vector,

cVector), assignsthe sumofbVectorand cVectorto aVector.

The statement: aVector.AddTo(b_Vector), assigns the sum of aVector and bVector to

aVector. Note that in either case _only the object whose method is called _(aVector) is

modified.

4.9. Vectors: implementation ofthescalar product

LetX, Y andZ bevectors and constitute abasis. Let k be a scalarandA beavectorsuch

that A = _{aX + bY}

-i-cZ where _a, b and c are scalar constants. ThenkA = _kaX + kbY +

kcZ.

IftheVector isan objectoftype TVectorandk is scalarthen the messageormethod call:

theVector._Scale(k),will_multiplyeachcomponentoftheVector_byk.

Notes on scalar multiplication: If k = _{1 then kA} = A. Ifk = _{-1 then} kA _{will be the}

additive inverse of A. If the magnitude of A is 1 then the magnitude of kA is k. ChoosingX, Y,andZasunit vectors parallel totheirrespective axis provides abasis such

that the components <x,y,z> of a vector from the origin to a point correspond to the

cartesian coordinatesforthatpoint.

4.10. Vectors: rotationof avector in a plane

In aplane we candecompose any vectorinto a basis consisting of _any twonon-parallel

vectors. Let V be a vector we wish to rotate ANG degrees. Let P be vector, of equal

magnitude, perpendicular to V. Ifwe use V and P as a basis for the vector we seek,

co8(ANG)xV

8in(ANG)xP

V

fig. 4.4

Vrot=

(cos(ANG))V+ _(sin(ANG)) P

The rotation method is equivalent to the vector sum of two scalar products. TVector objects respond to the method call or message: aVector.Rotate(angle, perpVector), _by

rotatingaVectorangledegrees in theplanedetermined_byaVectorand perpVector.

4.11. Vectors:the dot product

Let V = _{aX +} bY _{+ cZ and W} = dX + eY + _fZ, where _{X, Y,} and Z are a basis and a,b,c,d,e, and f are scalar coefficients. Then the dot product ofV andW is the scalar obtained_{by summing} theproductsoftheir_{corresponding}cefficients ₍₁₎ V-W=

(axe)+ (bx_f) + (cx e).

If V andWare placedsothat _theyhavethe sameinitialpointthenitcanbe shown, _by the law ofcosines, thatthe sameresultisobtained_by theformula ₍₂₎ V-W= IWI IVI

cos(A),

where A is the anglebetween V and W. The TVector.Dot function is implemented with formula _(1), but the geometricinterpretation (theprojection ofVon Wmultiplied _by the

Let W in formula (2) be a unit _vector, then the magnitude ofW equals 1 and we have:

V-W = IWI IVI

cos(A) = _IVI

cos(A), which is equal to the scalar projection of V on the

extensionofthevectorW.

This result can _be used to implement a change in basis for a vector. Let V be a Vector and_I, JandK be non-parallelunit vectors. _I,J andKconstitute abasis. The coefficient fortheIcomponentofV isthe magnitudeoftheprojection ofVon aline inthedirection ofI or_{V-I (see fig. 4.5b).} Thetriple _{<VI, VJ,} VK> are the components ofV in the_I,

J, Kbasis. Thecameraorviewpoint usedin animatorprojectionsis a basis similarto _{I, J,}

4.12. Vectors: Implementation oftheTVectorObjectType

TVector=OBJECT

(TObject)

fX,fY, fZ: _EXTENDED; {triple of_floatingpoint_numbers]

(TVectormethods}

PROCEDURE TVector.Init(x, y,z: _EXTENDED); PROCEDURE TVector. CopyOf(v:TVector); PROCEDURE TVector.Sumof(vl,v2: _TVector); PROCEDURE TVector. AddTo(v:TVector);

PROCEDURE TVector.Rotate(angle: EXTENDED; perp: _TVector); PROCEDURE TVector. Scale(k: EXTENDED);

FUNCTION TVector.DotWith(v: TVector): EXTENDED; END; (TVector}

(ImplementationofVector_Methods)

PROCEDURE_{TVector.Init(x,} y, z: _EXTENDED);

(Initialize data fieldsfX, fY & fZto x, y &z]

BEGIN fX:=x; fY :=_y; fZ:=z

END; (TVector.Init)

PROCEDURE TVector.CopyOf(v:TVector);

(Initialize data fieldsfX,fY & fZ to v.fX, v.fY, v.fZ}

BEGIN fX :=_v.fX; fY :=_v.fY; fZ:=v.fZ

END; (TVector.CopyOf]

PROCEDURE TVector.Sumof(vl,v2: TVector);

(vectoris assignedthe sum of vl andv2]

BEGIN

fX:=vl.fX +_v2.fX; fY:=vl.fY +v2.fY;

fZ:=vl.fZ+ v2.fZ

PROCEDURE TVector.AddTo(v: _TVector);

(thevectorvisaddedto theobject_vector}

BEGIN fX :=_{fX +}

v.fX;

fY:=fY +_v.fY; fZ:=fZ +v.fZ

END; {TVector._AddTo}

PROCEDURE TVector. Scale(k:_EXTENDED);

(vector ismultiplied_bythe scalar_k)

BEGIN fX :=_fX * _k;

fY :=_fY * _k;

fZ:=fZ*k

END; {TVector.Scale}

PROCEDURE TVector.Rotate(angle: EXTENDED; perp: _TVector);

(rotatesvectorangledegrees in theplanedetermined_byvector

and_perp, a secondvectorperpendicularto theobject_vector}

VAR

c,s: _EXTENDED;

BEGIN

angle :=_angle * _gDEGRAD;

c :=_Cos(angle);

s :=_Sin(angle); Init(fX*

c +perp.fX * s, fY * c+perp.fY * s, fZ* c +perp.fZ* _s)

END; {TVector.rotate}

FUNCTIONTVector.DotWith(v:TVector): _EXTENDED;

(return dotproduct of vector object withv}

BEGIN

DotWith :=_fX * v.fX +fY *

v.fY +fZ *

v.fZ

5. Local CoordinateSystemsand fheTLCS Ohiect Tvne

5.1. Local _{Coordinate Systems: theTLCS Object Type}

The TLCS object type is the ancestor of all of Animator's actor types as well as the

graphicsturtle. It provides movement and rotation methodsforallof_{Animator's moving}

objects.

LCS tree

Hierarchyof

objecttypes for

Local Coordinate

Systems.

(

)

TLCS

TActor

D

C

J

TTurtle

1

(

)

(

)

(

)

TUector

₎

J

fig. 5.1

TLCS objects contain 4 vector fields: fPos, fFwd, _fUp and _fLeft, that store data about

position, _heading and orientation in 3-dimensional space. An Object Pascal declaration

for the TLCS objecttype follows at theend of this section. The Position vector _(fPos)

locates a LCS in space. The other three fields represent _mutually perpendicular unit

vectors (see fig.5.2) thatestablisha_{heading (fFwd)} and an orientationfortheLCS. Each

ofthevectordatafields is represented_by an ordered_{triple, <x,y,z>, relating it}to a global

basis, but all orientation andmovement methods are implementedrelative to the local

basis determined _by fUp, fFwd and fLeft. A fifth vector _{field, fTemp,} facilitates

fig. 5.2

5.2. LocalCoordinate Systems: _fYaw, ("Pitch and fRoll

The TLCS objects have three REALorEXTENDED data_{fields, fYaw,} fRoll and_fPitch,

used to store information about changes in orientation or angular momentum. These

values represent rotations aboutan axis ofthe local coordinate systems in degrees. The

yaw, pitch and roll _terminology is often used to describe rotation in three-dimensional

space _{(nautical, aviation,}robot motion).

Let yaw be a rotation ofthe vectors fLeft and fFwd about theaxis defined_{by fUp,} pitch

be the rotation of _fUp and fFwd about _fLeft, and roll be the rotation of fLeft and _fUp

about fFwd. Actors and graphics turtles reference these data fields to update their

orientation.

5.3. Local Coordinate Systems: fLensandfitsView

The_{fLens field is only} used _by an LCS when it is_functioning as a camera or viewpoint

for the 2-dimensional projection onto the screen. Earlier versions of Animator

implemented a camera object type, but the inclusion of the fLens in all LCS objects

allows _any actor to be used as the viewpoint. The fLens data field is a REAL or

EXTENDED number used to scale the image. Image size on the screen is _directly

proportional tothevalue offLens.

ThefitsView field isahandleordoublepointertoa_MacApp TViewobject. Thepointer

allows _{any LCS} object connected to a particular view to reference information in that

5.4. Local _{Coordinate Systems:} allocation and assignment

If CS is declaredas aninstancevariableoftype_TLCS, thenit isahandle (double _pointer)

whose value is undefined. The NEW command allocates _memory to CS. The

initializationofits datafieldsis now acomplished_{by sending} messagesto CS inthe form

of method calls. For_{example, CS.Init(50,25, 40), is} a message_telling CS toinitialize its

position vectorto the triple _<50,25, 40>. Theorientationvectors will be assigneddefault

values _{corresponding}to thebasis oftheglobal coordinate system,withfFwd directed like the positive x-axis and _fUp directed like the positive y-axis, as in fig. 5.2. If the

orientation is to be altered, rotation messages will direct CS to compute the new

components for the unit vectors _fUp, fLeft and fFwd. The EXTENDED fields are

initialized to zeroand can bereset_bymessages such as: _CS.Yaw(90) and_{CS.Zoom(300),}

which tell CS to set the fYaw field to 90 and the fLens field to 300respectively. Actors

override theTLCS. Init method in ordertoextend it. The inheritedmethod _{is, however,}

called_by theTActor.Initoverride.

5.5. Local Coordinate Systems: _deepand shallow methods

The Free methodde-allocates memory for an object. It is inherited from TObject _by all

other _objects, butmust be overridden _by those objects whose data fields are themselves

dynamically allocated. The inherited method is called a shallow Free method and the

override thatfrees space allocated to each ofitspointertype fields is called a_deep Free

method.

TLCS. Freemust freeeach ofits fivevectorobjects. Most descendantsofTLCS override

this methodin order todeal with additional fields forwhich _{memory has been} allocated.

Typically, these _deepfree methods call onTLCS. Free to finish thejob. Pointers such as

TLCS.ItsView, which serve as connections to independent objects need not, and in fact

should never be used tofree the _memory that _theyreference. TLCS.CopyOf is another

shallow method (copies fPos, fFwd, fUp andfLeft_only) that is overridden and extended

bymanyofits descendants.

Each _{of the rotation methods provided for the TLCS object type rotates two} of the

orientation vectors about an axis _alongthe third. Thesemethods exploit thefactthat_fUp,

fLeft and fFwd (fig. _5.3) are _mutually perpendicular unit vectors in two ways: ₍₁₎ the

rotations are always within the plane determined_by the rotated pair ofvectors, (2) each

member oftherotated pair provides a perpendicualrunitvectorthatfacilitatestherotation

computationfortheother(see section_4.10,rotationof a vectorin theplane).

fUp

,fLeft

I fFwd

fig5.3

TurnLeft and TurnRight rotate fLeft and fFwd about an axis _{along fUp. TiltUp} and

TiltDown are rotationsoffFwd and_fUp about fLeft. RollRightandRollLeftrotatefLeft

and_ffUp aboutfFwd.

5.7. Local CoordinateSystems: the_TiltUp method

Let CS be a TLCS object, then the message _{CS.TiltUp(30),} will rotate CS.fFwd and

CS.fUp 30 degrees about the axis determined _by CS.Left in the direction from fFwd

towardfUp.

fFwd is rotated _by the message _{fFwd.rotate(30,} fUp). The second argument to rotate

must be a unit vector that is perpendicular to fFwd (90 degrees in the direction of

rotation). ForfFwd, the vector_fUp is therequired perpendicular. In orderto rotate_fUp

we require a similar perpendicular which is not _directly available, but easily computed.

Thecorrectvectorwould resemble fFwdwithits directionreversed. The _TiltUp method

initializes _fTemp to be the negative of _fFwd, and sends the message _{fUp.Rotate(30,}

fTemp). Theother rotations areimplemented similarly.

fPos

CS

fPos

fig. 5.4

Let dP be a vector parallel to CS.fFwd with magnitude _D, then dP is the vector

represention of the change in position or movement. dP is the product of the vector

5.9. Local_{Coordinate Systems:} Implementation ofTLCS ObjectType

TLCS =_OBJECT

(TObject) (Local Coordinate _System] fPos, (positioninglobal_coordinates)

fUp, (unitvector_providing up/down_reference} fLeft, {unit vectorforright/leftreference_}

fFwd, (forward indicatesthe directionof_motion} fTemp:_TVector; (useful_duringrotationsofLCS_}

fLens: _EXTENDED; (zoom factorwhen usedas_camera}

fYaw, fPitch,fRoll: _EXTENDED; (change inorientation per_frame} fltsView: TLCSView; (linkto_{MacApp view}}

(Local Coordinate System_Methods}

PROCEDURE TLCS.Init(theView:TLCSView; x, y, z: EXTENDED); PROCEDURE TLCS.CopyOf(lcs: TLCS);

PROCEDURE TLCS.TurnRight(angle:EXTENDED);

PROCEDURE TLCS.TurnLeft(angle: EXTENDED);

PROCEDURE TLCS.TiltUp(angle: EXTENDED);

PROCEDURE TLCSTiltDown(angle: EXTENDED);

PROCEDURE TLCS.RollRight(angle: EXTENDED);

PROCEDURE TLCS.RollLeft(angle:_EXTENDED); PROCEDURE TLCS.Move(distance: _EXTENDED); PROCEDURETLCS.MoveAbs(x,y, z: _EXTENDED); PROCEDURETLCS.Zoom(length: _EXTENDED); PROCEDURETLCS.Free; OVERRIDE;

PROCEDURE TLCS.Yaw(delta: EXTENDED);

PROCEDURE TLCS.Pitch(delta: EXTENDED);

PROCEDURE TLCS.Roll(delta: EXTENDED);

END; (TLCS)

(Implementation ofMethods for Local Coordinate Systems}

PROCEDURETLCS.Free; OVERRIDE;

(deepfree for local coordinatesystem}

BEGIN

fPos.Free; fUp.Free; fLeft.Free; fFwd.Free;

fTemp.Free;

PROCEDURE TLCS.Init(theView:_TLCSView; x, y, z: EXTENDED);

(initializelocalcoordinate system atx, y, zoriented likeglobalCS}

VAR

vl, v2, v3,v4: _TVector;

BEGIN

fltsView :=_theView;

new(vl);

vl.Init(x, y, z); fPos:=vl;

new(v2);

v2.Init(0, 1,0);

fUp :=_v2; new(v2);

v2.Init(0, 0, 1); fLeft :=_v2;

new(v3);

v3.Init(1,0,0); fFwd :=_v3;

new(v4);

fTemp :=_v4; fYaw :=_0; fPitch :=_0; fRoll :=₀ END; (LCS._Init}

PROCEDURE TLCS.CopyOfdcs:TLCS);

(MakeobjectTLCS a_copyof_lcs)

BEGIN

fPos.CopyOf(lcs.fPos); fLeft.CopyOf(lcs.fLeft); fUp.CopyOf(lcs.fUp); fFwd.CopyOf(lcs.fFwd)

END; {LCS.CopyOf}

PROCEDURETLCS.TurnRight(angle: EXTENDED);

(rotateLocal Coordinate Systemangledegreesto the_right}

fTemp.Init( fFwd.fX, - fFwd.fY,- fFwd.fZ); fFwd.rotate( - _angle,fLeft);

fLeft.rotate( angle,fTemp)

PROCEDURE_{TLCS.TurnLeft(angle: EXTENDED);}

(rotateLocalCoordinateSystemangledegreesto the_fLeft}

BEGIN fTemp.Init(

-fFwd.fX,

-fFwd.fY,

-fFwd.fZ);

fFwd.rotate(angle,fLeft);

fLeft.rotate(angle,fTemp) END; {LCS.TurnLeft}

PROCEDURETLCS.TiltUp(angle:_EXTENDED);

(rotateLocal CoordinateSystemangledegreesupward}

BEGIN

fTemp.Init( fFwd.fX,

-fFwd.fY,

-fFwd.fZ); fFwd.rotate(angle, fUp);

fUp.rotate(angle, fTemp) END; (LCS._TiltUp}

PROCEDURE TLCSTiltDown(angle: EXTENDED);

(rotateLocalCoordinate Systemangledegrees_downward}

BEGIN

fTemp.Init( fFwd.fX, - fFwd.fY,- fFwd.fZ);

fFwd.rotate(

-angle, fUp); fUp.rotate(

-angle, fTemp) END; {LCS.TiltDown}

PROCEDURE TLCS.RollRight(angle: EXTENDED);

(roll Local Coordinate Systemangledegreesclockwise}

BEGIN

fTemp.Init( fLeft.fX,

-fLeft.fY, - fLeft.fZ); fLeft.rotate(angle, fUp);

fUp.rotate(angle,fTemp) END; {LCS.RollRight}

PROCEDURETLCS.RollLeft(anjgle: _EXTENDED);

(rollLocalCoordinate Systemangledegreescounter-clockwise}

PROCEDURE_{TLCS.Move(distance: EXTENDED);}

(movesposition of object_byamount specified asdistance in direction

ofthevectorcomponent_fFwd}

BEGIN

fTemp._CopyOf_(fFwd);

fTemp.Scale(distance); fPos.AddTo(fTemp);

END; {LCS.Move}

PROCEDURE TLCS.Move_{Abs(x, y,}z:_EXTENDED); (setobject's position _{to x, y,z}}

BEGIN

fPos.Init(x,y, z) END; {LCS.MoveAbs}

PROCEDURE TLCS.Zoom(length: _EXTENDED); (setobject's lensequalto_length}

BEGIN

fLens :=_length END; (LCS._Zoom}

PROCEDURE TLCS.Yaw(delta: _EXTENDED);

(changetheangular_velocityabouttheverticalaxis_bydelta}

BEGIN

fYaw := _delta

END; (TLCS._Yaw}

PROCEDURETLCS.Pitch(delta:_EXTENDED);

(changetheangular_velocity aboutthehorizontalaxis_bydelta}

BEGIN

fPitch :=_delta

END; {TLCS.Pitch}

PROCEDURE TLCS.Roll(delta:EXTENDED);

(change the angular_velocityabouttheforwardaxis_bydelta}

BEGIN

fRoll:= _delta

6. TheTurtle: aVector-Based GraphicPph

6.1. The Turtle: turtlegraphics

Theturtlemetaphor _{for scripting} themotionofa graphics pen onthescreen ofa computer

demystified computer _programming for a generation of school children who were

introduced to turtle graphics through the _{Logo programming language [Papert 1970].}

Graphics turtles draw _by 'dragging'

a graphics pen which marks theirpath as _{they obey}

ordersto move andturn. Thepower ofthemetaphor seems tocome fromthe_immediacy

ofthecommands.

Beginningprogrammers learn Logo in an environment where eachcommandis executed

immediately, avoidingpossibleconfusionabouthowprevious commandshavealtered the

turtle's position or heading. The programmer must assume the turtle's point of view in

order to give proper instructions which take the form ofcommands like "turn left (90

degrees)"

or "move forward (10 steps)". Higher level commands are built up from

primitive ones as procedures orsub-programs.

The_followingexampleof aproceduretodrawa square is in aturtledialectsimilarto the

onedefined fortheTLCSobject typeintheLocalCS section ofthispaper.

procedure square(distance :extended);

begin

move(distance); turnleft(90); move(distance); turnleft(90); move(distance); turnleft(90);

Tur*le"

move(distance); turnleft(90); end; {square}

Notethatthesquares above are_{equallylikely} outcomesof_sendingtheSquare messageto

6.2. The Turtle: _drawingan actor

From an analytic point of _view, the unusual aspect of _specifying a _drawing in this

manneris the freedom ofthe descripion _{from any} coordinate system. All _lines, points

anddirectionsare relative to theturtle's inititialpositionandheading. Animatorexploits these procedural _definitions of _drawing to implement transformations: rotations and

translations are accomplished _{by altering} the turtle's position before the _drawing

procedureis begun.

In _Animator, each actor has a method of_{drawing itself consisting} ofa setof commands

for a graphics turtle. An actor is moved or rotated _by messages _modifying the position

and orientation data inits vectorfields. Similar fields are inherited_by all TLCS object

types, _includingturtles. When an actor iscalled upontoredraw _itself, itsendsits turtle a

messageto_copy theseposition and orientationvectors overitsown. Sinceall ofthelines

drawn_bythe turtleare relativetoits initialpositionandorientation, theeffectis similarto

multyiplyingby atransformation matrixinaconventional graphicspackage.

6.3. The Turtle: TTurtleobjecttype- data fields

The TTurtle object type is descendant from theTLCS objecttype andinherits all ofthe

TLCS data fields and methods described in the Local CS section. These vector based

methods allow TTurtle objects to respond to messages to turn and move. The TTurtle

object typeadds the_followingdatafields, which arespecific toits function.

The boolean field fVisible works with the PenUP and PenDown messages to

determine whether the _moving turtle will draw a line or _simply move to a new

position.

fCenterXandfCenterY locate the center ofthe screenfortheprojection method.

fViewPointis ahandle _allowingthe turtles projection methods to access the data

fieldsofthecurrent camera.

fSave provides a place to save the position vector when a _drawing is more

efficientlycompleted by _{moving back}topreviouslyvisitedpoint.

fPositionPitch, fPositionYawand fPositionRoll savedegrees of rotation about each

Animator's Rotation Menu commands use these fields in conjunction with the TTurtle

object's inherited fields _fPitch, fYaw and fRoll to maintain and _display angular

momentum about one or more axis that is independent ofthe rotationof the actor's local

coordinate system. The messagesto update thesefields and rotate the turtle are sent _by

theTActor. _{DrawPoly method,}just before_drawingis begun.

6.4. The Turtle: projection ontothe plane

Assumingits fVisible field is settotrue _{(aTurtle.PenDown),} aTurtleissues a commandto

draw aline from its initial position toits destination. In Animator this line is not drawn

immediatelyon the screen,but is collectedin aMacintoshtoolboxdata structurecalled a

Polygon, which is usedlikea segmentina _displayfile.

The lines collectedinthe polygonareexpressed in theView's integercoordinate system,

an awkwardsystem with thepositive y-axis_pointingdown. TTurtle objectsrespond toa

message like aTurtle.Project _byoutputtinga _LineTo(x,y) command, where x and_y are

View coordinates. The projection of the three-dimensional point associated with its

positiononto anx, yplaneisaccomplished _bycomputinga new set of coordinatesforthe

point basedon the local coordinate system ofthe current camera, a TLCS object whose

datafields arereferencedthroughthefViewPointpointer.

6.5. The Turtle : the_geometryofTTurtle.Project

LCS ofCamera 4.

Global CS

thepoint we want to project

onto the xy plane of

Let C be the position vector ofthe cameraandT be the position vector ofthe _turtle, then

P, a vectorfrom the _tip ofCto the _tip ofT can becomputed as thedifference between T

andC.

P - T-C, _{can also}

be viewed as the positionvectorof the point to be projected from the

coordinate system ofthe camera. The vector Pcan be resolved into components ofthe

x,y,z basisof the cameraLCS _{by finding}thedot productor scalar projection ofP on the

extensions ofeach of the unit vectors in the basis ofthe camera LCS. _Drawing lines

between points obtained from the x and _y components found above would produce a

parallelprojection(noperspective).

6.6. TheTurtle: perspective projection

Animator produces a three-dimensional perspective _{by multiplying} each of the

coordinates found in the parallel projection _by a ratio of a magnification _factor,

fViewPoint._fLens, and the orthogonol distance of the projected point from the _x,y

projection plane. _{The distance is simply} the z component found _{by TTurtle.Project,} and

fLens is a value set _by TLCS.Zoom. Theresult is to shrinkthe projected coordinates of

distantobjects toward the center oftheprojection. _IncreasingfLens magnifiesallobjects

equally.

TTurtle.Project then rounds the result and resolves the differences between the image

space coordinate system used _by QuickDraw (Macintosh graphics package [Appl _85])

and Animator's world coordinates. If fVisible is true, a line is added to the polygon,

otherwise a QuickDraw call is made to MoveTo which moves the graphics pen to _(x,y)

without_drawingtheline.

6.7. The Turtle: _drawingwith the turtle

Thepostspicturedin_fig6.3 weredrawn _bythe turtle. Except fortheir z-coordinates _they

are identical. The perspective and size differences are due to the projection. _They are

made _by repeated calls to the turtle's StackCube method, which draws a cube from the

lower, leftcomerandleaves theturtle atthe upper, leftcorner_ready todrawanothercube

s-s

s /

m=:>

.=p

J '

fig. 6.3

The cube is drawn _{by having} the turtle walkaround the block with left rums, pausingat

each corner todraw a squarewith _tilt-up turns. _{An important strategy in designing} turtle

subroutines, such as the _tilt-up square, is to return the turtle to its initial position and

orientation. The advantagein thisexample is that the _tilt-up squares do not complicate

thewalkaroundthe block.

6.8. The Turtle: overridinginheritedmethods

As an immediate descendantofthe TLCS object _type, TTurtleobjects inheritall TLCS

methods. Several of these methods are useful but _incomplete, in view of the TTurtle

object's specialization. A straightforward example is the inherited Move method. It

works _fine, butunlike _anyotherobject oftheTLCS type, turtlesneed todraw lines when

they move. The OVERRIDE method _simply calls the INHERITED Move method

followed _by the Project method. The MoveAbs method for _transporting an LCS to a

position whose coordinates areknownisoverridden inthe same manner.

The Init method is _similarly extended to accommodate additional data fields. A more

interesting case is the inheritedTLCS.CopyOfmethodwhich _only copies fields common

to all descendants ofthe object type. This _{is particularly} useful when the position and

It _{is, however,} sometimes useful to make one turtle an exact _{copy (all data} fields) of

another. The TTurtle OVERRIDE ofCopyOfwill make such acopy, if, and_onlyif, the

argumenttoTTurtle.CopyOfisoftype TTurtle.

In the_{implementation}the_membershipoftheargumentin TTurtletypeistested andifthe

argumentisofthecorrecttype,typecoercionisusedtoassignahandleofthecorrecttype

to point to the data fields. In MPW _Pascal, when a type identifier is used as a Pascal

functionthe argument isrecast as thedesignatedtype andreturned _by the function. This

permits _siblingobjects to bepassed as actual parametersto thesame routine,with noloss

ofinformation.

6.9. The Turtle: _movingparts

Inthecaseofan overidden methodtheinheritedmethodis alsoavailable_byprefacingthe

callwiththereserved wordINHERITED. Inthecurrentversion ofAnimator,actorswith

parts that move _{independently} are implemented with a single turtle. _Increasingly

complex actors would be better served _by multiple _turtles, so that each turtle could

maintain static data about its orientation with respect to its immediate predecessor in a

hierarchical structure.

In such a_design, subordinate turtles wouldtake theirinitial positionand orientation data

fromother_turtles,rather thanfromtheactor. Inthis case theinheritedCopyOfwouldbe

appropriate, so as to avoid _writing over data fields like fPositionPitch, which must

6.10. Turtle: _{Implementation}ofTTurtleobject type

TTurtle= OBJECT

(TLCS)

fVisible: _{boolean; (moving} turtledraws linewhen _true}

fViewpoint: _TLCS; (handleforcamera _} fCenterX,fCenterY: _EXTENDED; fSave: _TVector;

fPositionPitch: _EXTENDED; fPositionYaw: _EXTENDED; fPositionRoll: _EXTENDED;

PROCEDURE_{TTurtle.PenUp;} PROCEDURE_{TTurtle.PenDown;}

PROCEDURE TTurtle.CopyOf(lcs: TLCS); OVERRIDE; PROCEDURE TTurtle.ChooseCamera(vp: TLCS);

PROCEDURE TTurtle.Move(distance: EXTENDED); OVERRIDE;

PROCEDURE TTurtle. MoveAbs(x,y, z: _{EXTENDED); OVERRIDE;}

PROCEDURETTurtle.Init(theView:_TLCSView;x, y, z: _EXTENDED); OVERRIDE;

PROCEDURE_{TTurtle.Project;}

PROCEDURE TTurtle. Square(side: _EXTENDED); PROCEDURE TTurtle.Cube(side: _EXTENDED); PROCEDURE TTurtle.StackCube(side: _EXTENDED); PROCEDURE TTurtle.Triangle(side: EXTENDED); END; {TTurtle}

(Methodsforgraphics_turtle}

(initialize turtle_usingx, y toestablish center ofCS andz forzoom_value}

PROCEDURE TTurtle.Init(theView: TLCSView; x, y, z: _{EXTENDED); OVERRIDE;}

VAR

vp: TLCS;

aVector: _TVector,

BEGIN

INHERITED Init(theView,x, y, z); ChooseCamera(fltsView.fCamera);

new(aVector); fSave :=_aVector,

fCenterX :=_kCenterX;

fCenterY :=_kCenterY;

PROCEDURE TTurtle.CopyOf(lcs:_{TLCS); OVERRIDE;}

VAR aTurtle: _TTurtle;

BEGIN

INHERITED _CopyOf(lcs);

IF _{MEMBER(lcs, TTurtle)THEN} BEGIN

aTurtle :=_{TTurtle(lcs);} fYaw := _{aTurtle.fYaw;} fPitch := _{aTurtle.fPitch;}

fRoll :=

aTurtle.fRoll; fPositionYaw:=_aTurtle.

fPositionYaw;

fPositionPitch :=

aTurtle.fPositionPitch;

fPositionRoll :=

aTurtle.fPositionRoll;

fVisible :=_{aTurtle.fVisible;}

fViewPoint :=_{aTurtle.fViewPoint}

END _{if}

END _{{TTurtle.CPOf} ;}

PROCEDURE_{TTurtle.Project;}

(projectturtleposition with respect toplane of_viewingeye)

VAR

px,py: _EXTENDED; {projection cooordinatesfor imagespace]

x, y, z:_EXTENDED; {coordinates in viewpoint's_LCS}

BEGIN

fTemp.CopyOf(fViewPoint.fPos);

fTemp._Scale( 1); fTemp.AddTo(fPos);

x :=_{fTemp.DotWith(fViewPoint.fFwd);}

y :=_{fTemp.DotWith(fViewPoint.fUp);}

z :=_{fTemp.DotWith(fViewPoint.fLeft);}

px :=_x * fViewPoint.fLens/z +_fCenterX; py :=_fCenterY

-y* fViewPoint.fLens/z; IF fVisible THEN

LineTo(ROUND(px), ROUND(py)) ELSE

MoveTo(ROUND(px),ROUND(py));

END; (project)

PROCEDURETTurtle.PenDown;

(setvisibleto truesomovementdrawslines}

BEGIN

fVisible :=_True

PROCEDURE_{TTurtle.PenUp;}

(setvisibletofalseso movementdoesn't draw_lines}

BEGIN

fVisible :=_FALSE END; {TTurtle.PenUp}

PROCEDURE TTurtle.ChooseCamera(vp: TLCS);

(assign vp as camera viewpointfor_drawing}

BEGIN

fViewPoint:= vp

END;

PROCEDURETTurtle.Move(distance: _{EXTENDED); OVERRIDE;}

(The inherited TLCS.Move isextendedtoproject and output a2-D linetocommand}

BEGIN

INHERITED _{Move(distance);} Project

END; {TTurtle.Move}

PROCEDURETTurtle.MoveAbs(x, y,z: EXTENDED); OVERRIDE;

(The inheritedTLCS.MoveAbsisextendedtoprojectandoutputa2-Dlinetocommand}

BEGIN

fPos.Init(x,y, z); Project

END; {TTurtle.MoveAbs}

PROCEDURETTurtle.Square(side:EXTENDED);

(drawstate transparentsquare)

VAR

i: INTEGER;

BEGIN

FOR i:= _{1 TO 4 DO} BEGIN

Move(side);

TiltUp(90)

PROCEDURE TTurtle.Cube(side: _EXTENDED);

{drawstatetransparent_cube)

VAR

i: _INTEGER;

BEGIN

FOR i := _{1 TO 4 DO}

BEGIN Square(side); Move(side); TurnLeft(90)

END;

END; {TTurtle.Cube}

PROCEDURETTurtle.StackCube(side: _EXTENDED);

(drawscubes oneon_topof_another)

BEGIN

Cube(side); TiltUp(90); Move(side); TiltDown(90); END;

PROCEDURETTurtle.Triangle(side:EXTENDED);

{drawsstate transparent_triangle)

VAR

i: INTEGER;

BEGIN

FORi:= ₁ TO 3 DO

BEGIN

Move(side);

TurnLeft(120) END; (for)

7, Actors; a TemplateforPictures thatMovp

7.1. Actors: an _{animated objecttype}

Animator's actors maintain data about their postion in the world coordinate system and

how thatposition is _{changing (instantaneous velocity, acceleration,} angular momentum

and acceleration). _They are designed to remain in motion (change their position and

orientationbeforeeach frameisrecorded) until_theyreceive amessageto altertheirdata.

Animator'smenu and mouse controls allow usersto _stop the actor's clockworkworld and

senditmessages. Actorsalso respondtomessages fromobjects _(TView) thatcontrol the

image drawn onthemonitor. The design anticipates more_interestingdescendantswhose

behavior might be modified _by messages fromother objects in the _scene, perhaps even

fromother actors.

As TActorobjects, actorscan storeinformation in theirdatafields and respondto certain

messages_{corresponding} to theirdeclared methods. When anew objecttypeis declared

tobeadescendantof an_existingoneitcan add toor_{modify its inheritance} ofdata fields

and methods. EachofAnimator'sactortypescan trace _{its ancestry back}throughTActor

to theTLCS objecttypeandTObject. (recallfig. _5.1)

LCS tree

Hierarchyof

object typesfor

LocalCoordinate

Systems.

c

(

)

TLCS

D

C

J

(

₎

J

C~

7.2. Actors: TActor datafields

The data fororientation and position is stored invectorfields inherited from the TLCS

object type. _They are discussed in detail in the sections Local CS and Vectors. The

TActor object typedeclares the _followingadditional data fields in ordertomaintain and

update a_displayimage:

fPoly is a handle or double pointer to a QuickDraw data structure called a

Polygon. Polygons are used to store line _drawing commands which can be

displayed with a single _FramePoly commandwhen the view sends a message to

an actortodraw itself.

fValidPoly is a boolean field which is set to false if an actor or the camerahas

been moved or rotated, _indicating it will be _necessary to update the Polygon

before display.

fTurtle is ahandle forthegraphicsturtlewhich will beused to redrawthe actor's

Polygon.

fExtent is arectangle defining the area ofthe View effected _{by erasing} theold

Polygon and_framing the newone.

f/elocityis afield indicating thedistance an actor should bemoved in the next

frame.

fAcceleration is an increment or decrement applied to _fVelocity before each

move.

fID is anidentification number.

fHiLight indicatesthatan actoris currently selectedand should be shaded on the

display.

7.3. Actors: Updatingthe Polygon

Whenever an actor has received a message to move or rotate it will set _fValidPoly to

false. The TActor.InvalidatePoly method affords other objects (such as the _View) the

opportunity of _sending an actora message to invalidate its polygon. The View object

otherwise alters the viewpoint of projection. Before a view is redrawn an UpDate messageissenttoall actors whose _fValidPoly field is false.

Topreparefor_{drawing,TActor.UpDatePolyfirstsends a messageto the}objectpointedto

by fCamera to initialize the _{projection coordinate system (projection} onto the plane is

described in theTurtle section). _Next, the _boundingrectangle ofthe _existingpolygon is saved (this area of the view will have to be _redrawn), and a new one is initialized. Finally, messages are sent _passing the actor's local coordinate system to the graphics

turtle and_instructingthe turtle toredrawthepolygon.

7.4. Actors: _{OverridingDrawPoly}

TActor is an abstract object type. It serves as a template forall descendant actor_types, but is never instantiated. The _DrawPoly method inherited _by each of TActor's descendantsmakes somefinaladjustments to the turtle toaccountfortransformations that

are independentofthe actor's coordinate system, but doesnot contain _{any instructions for} drawing. Each descendant of TActor must OVERRIDE the INHERITED _DrawPoly

methodin ordertoprovide an appropriate method for_drawing itself. _Typically thenew methodwillcalltheinherited oneto takeadvantageofthegeneralroutinesit implements. The _drawing method consists of messages to move the graphics _turtle, which in turn issuesQuickDrawcommandstocreate thepolygon.

Upon completion of the polygon, control returns to _UpDate, and the polygon data structure is closed. The _bounding rectangle of the new polygon is then combined with

that ofthe original polygon to provide a description ofthe portion ofthe view area that has been altered_by the update. Finally, theUpDate method resets _fValidPoly to true.

7.5. Actors: moving the picture

production program that will create the frames for scripts _involving the simultaneous

movementof a cast of_actors, butimplementationofaframe-by-frameproduction system

was not attempted.

Anactor'smovement betweenoneframeandthenextisrepresentedas adirected distance

(vector)takingits direction from theactor's _headinganditsmagnitudefromthe datafield

fVelocity. _{Animator's interface} allows the user to select a single _actor, in order to

preview its progress as the framecounter_{advances, by double clicking} onthat actor and

holding down themouse button. _Releasingthemousebutton willhaltthe process. Ifthe

halted sequence was not _satisfactory itcan be undone (the actor will revertto its initial

position) witha menu command.

The user can _stop and start the production of frames in order to change the value of

fVelocity. Sincethesemodificationsaltertheactor'sspeedabruptly, smoothtransitions to

new states would require _many stops for small modifications. The user _{may instead}

choose to _{modify fAcceleration, specifying} an increment or _{decrement in velocity} to be

appliedbeforeeach movementis computed,thus _avoidingthe frequent_keyingthatwould

otherwise berequiredto_specifygradual changes.

Since movement will always be directed along the actor's _heading, the user is also

providedwith theoption of _rotating theactorso astochange theheading. Thechangein

direction can beeither immediateor incremental (per frame). Anincremental changeis

achieved_{by modifying}angular momentum. Itcan be likened to theinfluence ofarudder

onthe_headingofa_boat,orthe _steeringwheelonthe_headingofa car.

7.6. Actors: Navigation in 3-D space

Rotations in Animatorarerelative to the actor's_heading andorientation ratherthan toan

external reference. The user is asked to assume the point of view of the actor he is

directing, or even _better, to assume the actor's position in space. Left is the direction

pointed to _by the extended left arm, and _{up isdirectly} over the actor's _head, even ifthe

actorhappensto beupsidedown. Althoughthisisoccasionally counterintuitive,the local

Up

Left.

<

fig.7.2

When _directing Animator'sactors, leftand right turns are bestunderstoodas rotationsof

fig. 7.2 in which the left and forward axes will rotate _{together, pivoting} around the UP

axis. _{Tilting up} or down is a rotation in which UP and FWD move together _pivoting

around the LEFTaxis. _Rolling leftor rightproduces a rotation ofUPand LEFT about

FWD (nochangeinheading).

The commands: _{Turn, Tilt,} Roll and Acceleration are found in the Control _Menu, and

operate on the _currently selected actor. Rotations that do not affect the movement of

actorsthrough space (i.e. _spinning) can be specified withthe Rotation Menu in a similar

manner.

The move command inherited from the TLCS object type takes a DISTANCE as a

parameter and moves the object forward along its present heading. The TActorobject

type overrides this method in order to make changes in orientation and compute an

appropriatedistanceparameterbasedon fAccelerationandfVelocity. The inherited fields

fYaw, fPitchand_fRoll,correspondto rum, tiltandroll_respectivelyand are usedto record

rotationstobe madebeforeeach move orframe.

7.7. Actors: Descendants ofTActor

Creatinga new actortyperequires some _{programming in}order to describe how thenew

object will differ from its ancestor. For instance, if the actor is to _{differ only in}

appearance,onlytheTActor._DrawPolymethod needbechanged(overridden).

Currently the most successful actors are of the TFish object type. _They are paper thin

angelfish made oftwotriangles. Thesmaller_triangle, or_tail, swishesbehindthe_moving

fishasitswims. The _necessityof_redrawingthepolygonsforeach movedictatesa simple

design,where realtimefeedback isrequired. Inframe-by-frameproduction, adescendant

ofTFish thatwas_visuallymore_{interesting, but} slowerto_draw, couldbe used to produce

the finalframes. Thenewfish need_{differ only in itsDrawPoly}method.

7.8. Actors: commandsastext

In anticpation of an application for the production of Animator scripts each menu or

mouse commandthatalters theappearance or position of an actor could bewritten astext

to anotherfile. Thetextdescription shouldinclude theselected actor'sIDnumber andthe

current frame _number, as well as the data entered to complete the command. All

commands would bewritten toatext filewhich can be sorted_according toframenumber

and editedtocreate scenes.

Theproduction applicationwoulddraw framesoneata_{time, using}the command fileas a

script. Inordertodraweach _frame, itwouldexecuteall ofthecommandswith thatframe

number, move and_displayeach_actor, and thensignal a camera torecordthe frame. The

existing design should support scripts that choreograph multiple actors with a _moving

camera or viewpoint. Production would be slow, but time increases should remain