Animating widgets in the interViews toolkit - Springer Link

Animating Widgets in the InterViews Toolkit Bruce H T h o m a s 1'2 and Paul R Calder 2 Advanced Computing Research Centre School of Computer and Information Science University of South Australia The Levels, SA Australia 5095 mabht~graceland.Levels.UniSA.Edu.Au 2 Computer Science Flinders University Bedford Park, SA Australia 5034 [email protected]

A b s t r a c t . Current graphical user interface toolkits, by and large, provide widgets that have a static appearance. The focus of this paper is to outline some additions that we have made to a toolkit to support animated widgets, such as menus that open smoothly, buttons that bounce and slide when pushed, and animated labels. The animations that underly these new widgets rely on straightforward applications of well-known techniques for cartoon and computer animation. Our concern in this paper is to describe how we packaged the techniques into a form that application programmers could readily use. In particular, we describe extensions we made to the InterViews 3.1 toolkit. K e y w o r d s : Graphical user interfaces, toolkits, animation, widgets, InterViews

1

Introduction

Most current applications with graphical interfaces change abruptly from one static appearance to another: windows snap suddenly open, dialog boxes pop suddenly into view, scrolled views j u m p suddenly into place. We are building tools that help application p r o g r a m m e r s create applications that change more gracefully. 1.1

Animation

in I n t e r f a c e s

Other workers have shown the value of animation in interfaces. For example, Card [9] showed t h a t smooth 3D animation allowed users to keep track of large d a t a sets, even though much of the d a t a was hidden at any one time, and Sukaviriya and Foley [11] showed that animation helped convey information more quickly and accurately in the context of on-line help systems. We have considered how the principles of animation can be applied in the context of familiar application interfaces. We have argued elsewhere [12] t h a t animation can be used to improve the prosody of the standard components, called widgets, that interface toolkits provide for common interaction tasks. We are

27 currently considering how similar techniques can strengthen the direct manipulation metaphor that underlies many current graphical interfaces [13], [14]. This paper describes the techniques and components that we used to implement a set of animated widgets in the InterViews toolkit [8]. Our concern here is not with the principles of animation (we use standard techniques developed by cartoon and computer animators [7, 6]). Rather, we are concerned with techniques to package the animations in a way that application programmers (and toolkit designers) can use to incorporate animations into their code. 1.2

The Prosodic Interfaces Project

This work is part of the Prosodic Interfaces project, an ongoing project that aims to provide a set of tools and techniques that can improve the prosody of human computer interfaces. In addition to animation, the Prosodic Interfaces project is concerned with sounds and gestures. Audible cues can improve engagement with the interface and strengthen the sense of direct manipulation. Gestures can provide a smoother and more expressive way of issuing commands and specifying operations. Together, the three techniques will extend the repertoire of tools that interface programmers can use to enrich their creations.

2

Animated Widgets in InterViews

We chose the InterViews toolkit as a platform for our experiments because of its familiarity, because it allowed us to test our components in the context of real applications, and because of its powerful graphics model.

2.1

Widgets in InterViews

InterViews widgets are created by an object factory called a WidgetKit. Applications programs call kit methods to create standard widgets such as menus, buttons, and scrollbars. This approach insulates the application from the detailed implementation of the widgets, and it gives it a degree of independence from the specific look-and-feel of the components. For example, an application might call the WidgetKit PushButton method to create an instance of a push button widget. In general, the application does not care whether the object returned is a Motif-like push button or an OpenLooklike push button; it just incorporates the component into the structure of the interface. Indeed, the InterViews mechanism provides several types of Widget Kit, each producing widgets that conform to a different look-and-feel standard, and it allows the choice of the type of push button created to be deferred until run time. The user can specify the look and feel of the application in a preferences file or even as a command line argument. This indirect way of creating widgets provided us with an easy way to incorporate animation into existing applications; we simply created a new type of widget kit and made it available as another run-time look-and-feel choice. This

28 approach allowed us to try out our new animated widgets in existing InterViewsbased applications without needing to modify the application code in any way. 2.2

An Animated WidgetKit

Our new kit differs from the existing kits in two key ways: it provides animated versions of standard components such as menus and buttons, and it provides new kinds of widgets that make sense only in the context of animation. We have used our animated widgets to explore several different kinds of effects, although our emphasis to date has been on the implementation of the effects, not their success as interface elements. One idea that has proved promising is to provide menus that smoothly grow to full size instead of suddenly snapping open. For example, Figure 1 shows several frames from the animation of a pull down menu that appears to grow smoothly out of the menu bar when the menu is activated. The animation is brief; typically it spans considerably less than a second. Nevertheless, it adds a sense of smoothness to the interaction.

Fig. 1. A growing menu

Another idea is to provide buttons that use movement to suggest their response to interaction. For example, we have built push buttons that appear to bounce when pushed, toggle buttons that slide to the side when activated, and

29 choice items that appear to flip over to expose their reverse side, as on the left side of Figure 2 . We have also used short cartoon sequences as animated labels on buttons. For example, Figure 3 shows an animated check box where the check mark appears gradually, as if the stroke were drawn with a pen.

1 @ i'-:'~i!~:%~--"::' "

Ir

a

i,., k., ,, l

O "': m m m

Ill

lU ~

:

.

~.':' &.:..'::$:~.

"f~

~

. ~ .

~ ~::~:.&.::~:

~.::.~

Dl

"'" ~

W /%je"

m mJa

a,E

~,,vj

!ram ilm

"t(,b EB -'r

i:::: Fig. 2 . 3 D path animation

We have experimented with menus that rely on 3D-like effects to compactly display more choices than could comfortably fit in a conventional menu. Our approach is to group the choices in panels that are arranged as if on the sides of a prism. Normally, only one side of the prism is visible; the hidden sides can be brought to view by smoothly rotating the prism around its long axis. For example, the right side of Figure 2 shows a menu that includes 56 patterns, grouped into 4 panels of 14 and arranged as if on the sides of a tall rectangular prism. The left-hand frame shows the menu with one panel visible and the other 3 hidden. If the desired pattern is not visible, the buttons on the

30

Fig. 3. Check box animation

top of menu labeled with "" bring other panels to view by smoothly rotating the menu around its vertical axis. In the figure, the menu rotates towards the left to bring to view the panel that was previously hidden on the right.

3

Supporting Animation in Toolkits

Toolkits that support animation need to pay particular attention to two things: the ability to specify the appearance of graphical objects, and the ability to specify how that appearance changes over time. Furthermore, the requirement for smooth-looking animation places great demands on the graphics performance of the toolkit objects. If the performance is inadequate, the effect of the animation will largely be lost. Indeed, rather than making a change appear smooth, the effect of sluggish animation will be to draw attention to the change and make it seem awkward and ponderous. 3.1

Specifying A p p e a r a n c e

Many current generation graphical interfaces toolkit provide only a simple model for specifying appearance. For example, many toolkits are restricted to specifying appearances using only simple shapes such as lines, rectangles, and circles, combined with fixed-size screen-aligned images and text. Such simple graphics are likely to be inadequate for interfaces that use animation. For example, an animation that displays a button flipping over to expose its underside requires that the button label text be drawn at arbitrary angles and sizes, and a menu that smoothly grows in size requires that items in the menu also change size. Many animation systems use high-end 3D graphics systems, often with hardware support, to provide adequate graphics models. For example, the Inventor toolkit[10] allows animation designers to specify the positions, sizes, and orientations of components with complete freedom. This technique leads to naturalseeming movement since users are familiar with the 3D motion of everyday

3] objects, but such systems are computationally very expensive and are generally unavailable on run-of-the-mill graphics workstations. Fortunately, the full power of 3D graphics systems is not needed for the kinds of animations that are appropriate for widgets in familiar applications; we have found that a simpler scheme is sufficient for such purposes. Our approach is to use a 3D coordinate system for specifying the geometry of objects, but to map the 3D transformation matrix into an equivalent 2D matrix for rendering. With certain restrictions on the kinds of effects possible, our approach combines the flexibility of the 3D coordinate system with the efficient rendering of a 2D system. Section 5.1 describes the approach in detail. Of course, our approach would not be possible if the graphics model underlying the toolkit did not support 2D transformations. We rely heavily on the InterViews graphics model, which allows arbitrary 2D transformation of all its objects, including text and images. 3.2

Specifying C h a n g e

Animation, whether in cartoons or on computers, is achieved by rapidly displaying still images that are each slightly different from their predecessor. The overall effect is of smooth movement if the rate of presentation of the images is high enough, and if the positions of moving objects are appropriately chosen. The basic requirements for animation in a user interface, then, are to be able to specify positions that change over time, and to be able to display the images rapidly. Animators typically use two techniques for specifying changing images: keyframe animation and frame-by-frame animation. -

-

Keyframe animation is specified by defining the positions and sizes of objects at key points in the animation, then automatically calculating the in-between frames by interpolating between the key frames. The process works best if the movement in the animation can be described mathematically, for example by geometric transformation of objects in the scene. Frame-by-frame animation is more general than keyframe animation because each frame in the animation is hand-crafted. However, it requires more work because all of the frames must be individually created. Frame-by-frame animation is appropriate where the changes in the objects in a scene cannot be represented by simple transformations.

Animators routinely use a range of techniques to improve the realism of their work [7]. For example one important rule, often called slow-in slow-out, is that moving objects should move more slowly at the beginning and end of their movement than in the middle. We apply the slow-in slow-out principle in calculating the positions and sizes of intermediate frames in animations. For example, when an animated menu grows to full size, it grows slowly at first, quickly in the middle, and then slowly again as it approaches full size. The effect is to make the menu action seem smoother without increasing the overall duration of the animation.

32 4

Components

that

Support

Animation

In support of our new animated widgets, we added components that provide three kinds of animations to the InterViews toolkit: animation by transformation, animation by flipbook, and animation of resizing windows. This section describes the new components in terms of their functionality and programming interface. Section 5 describes some of the issues we encountered in implementing the components. InterViews is implemented as a library of C + + classes [1]. Chief amongst these classes is the glyph, which is the base class for a hierarchy of graphical objects that specify the appearance of InterViews-based applications. Glyph subclasses include simple graphical objects (such as rectangles, images, and characters) that define the elements of the interface, and composite objects that arrange other glyphs by tiling, overlaying, or stacking. An InterViews widget, itself a glyph, is composed of other glyphs that specify its appearance. The new animation components that we have defined modify or transform glyphs. In this paper, we use the C + + class interfaces to describe the objects. 4.1

A n i m a t i o n by T r a n s f o r m a t i o n

The C § 2 4 7classes we implemented to support animation by transformation of glyphs are Path, Path_Animator, and Face. The animation by transformation process is a form of key framing. A Path defines a series of keyframes for the animation. Each keyframe consists of a 3D transformation that defines the position and orientation of a glyph for a part of the path, together with timing information for the subpath. A Path_Animator calculates the in-between frames for a Path animation by interpolating between the keyframe transformations. A Face displays a pseudo-3D projection of a glyph transformed by a 3D transformation matrix. Path_Animator uses a Face to display the transformed glyph as it is animating the Path. Two examples using these classes for animation are shown in Figure 2. P a t h A path consists of an initial 3D position and orientation (specified by a DDDTransformer, a 3D transformation matrix) and a series of tuples that define the path keyframes. Each keyframe tuple, called a PathItem, contains a step count, time duration, and transformation relative to the last keyframe specified. Figure 4 shows the Path and PathItem class interfaces. The constructor for the Path class specifies the start matrix and information to describe the subpath from the starting point to the first key frame. The append method adds additional key frames to the animation. The total_duration method returns the sum of all the durations contained within the list of path items, and the total_steps method returns the total number of steps. Finally, the cycle method sets the cycle state to true or false: if true, the animation continues after the last path item is finished by resetting the path to its initial conditions.

33 class PathItem

public: PathItem(DDDTransformer *, float duration, int steps); DDDTransformer * matrix(); float duration(); int step();

class

Path

< public: Path(DDDTransformer * s t a r t , DDDTransformer * f i n i s h ~ float duration, int steps ); void append (PathItem *); float total_duration(); int total_steps(); void cycle(boolean);

Fig. 4. Path and Path_Item class interfaces

P a t h _ A n l m a t o r The Path_Animator class coordinates the animation of a giyph according to the information specified by a Path. The major responsibility of a Path_Animator is the calculation of the in-between frames for the key frames specified by the Path. The Path_Animator calculates a transformation matrix for each in-between frame based on the percentage of time between key frames and an interpolating function. These calculations are described in more detail in Section 5.2. A Path_Animator can control multiple paths. Typically, the paths represent different trajectories for a glyph. For example, one path might specify the transformation of a glyph representing a button from an "off" to an "on" state, and another might specify the transformation, perhaps by a different trajectory, back to the "off" state. Figure 5 shows the class interface. The append_path method adds a new path to the list; the flip_to method begins the animation of a specified path. Currently, Path_Animator uses an interpolating function that results in a simple "slow-in/slow-out" transition between the keyframes. We are investigating ways to specify different interpolating functions that give greater control over the interpolation. For example, it may be necessary to control the position and orientation of an animated glyph independently, perhaps by using different interpolating functions.

34 class Path_Animator { public: Path_Animator(Glyph *, Path *); void flip_to(int index); void append_path(Path *ne._path); } Fig. 5. Path_Animator class interface

Face The Face class displays a glyph in pseudo 3D. By pseudo 3D, we mean the drawing of a 2 dimensional graphical object with 3 dimensional transformations and an orthographic projection. The constructor has two parameters: the glyph to be displayed in pseudo 3D, and a 3 x 4 transformation matrix describing the 3D placement. 3 Figure 6 shows the class interface. The current transformation matrix can be obtained using the current_dddtransformer method, and the transformation matrix can be changed with the update method. The visible method returns true if the front of the glyph is visible; glyphs facing away from the screen are not drawn. The draw and pick methods determine if the glyph of the Face is visible before performing the drawing or picking. A description of the calculations required for the Face class are in Section 5.1.

4.2

Deck_Animator

The Deck_Animator class is used to build flip-book style animations, where the frames in the animation are each specified by a separate glyph. The animated check box in Figure 3 is an example of using the Deck_Animator class. The class works by modifying a Deck, an InterViews composite glyph that arranges its components like a stack of cards, with only the topmost glyph visible. Figure 7 shows the interface. The constructor is given a Deck containing all glyphs in the correct order. The duration method sets the total number of seconds for the animation, and the steps method sets the total number of images. The default number of steps is the number of items in the deck minus one. The flipper method causes the animation to proceed to the given end index. If the end index is less than the current index in the deck, the animation is performed "backwards." That is, it starts at the given index and moves down to the final index. a Since only orthographic projections axe supported, a 3 by 4 transformation matrix can fully specify a three dimensional transformation. See Foley [4] for a full description of orthographic projections.

35

class F a c e : public MonoGlyph { public: Face(Glyph *, DDDTransformer * = nil); void update(DDDTransformer *); DDDTransformer * current_dddtransformer(); boolean visible() const; virtual void draw(Canvas *, const Allocation ~) const; virtual void pick(Canvas *, const Allocation R, int depth,

Hit ~) ; virtual void request(Requisition R) const; virtual void allocate(Canvas *, const Allocation ~, Extension ~);

}; Fig. 6. Face class interface class Deck_Animator : public MonoGlyph

{ public: Deck_Animator(Deck *); virtual "Deck_Animator(); virtual void duration(float); virtual void steps(float);

void flipper(GlyphIndex end_index);

}; Fig. 7. Deck_Animator class interface

4.3

Window_Animator

The Window_Animator class allows for the animated opening and closing of a window. Currently, the class supports animations that can be described by rescaling the window (and its contents) to fit a specified rectangle. We are investigating ways of specifying and implementing other kinds of opening and closing animations, including more kinds of transformations and other visual effects. Figure 8 shows the interface to the Window_Animator class. The constructor takes the Window to animate. The start method begins an animation that is described by a starting and ending rectangle, a duration, and a number of steps. The boolean parameter specifies whether the animation goes forward (opening the window) or backward. At each step, the contents of the window are resized so that they fill the rectangle.

36 class Window_Animator { public: Window_Animator(Window *); void start(boolean in_forward, Rectangle start, Rectangle end, float duration, int steps); };

Fig. 8. Window_Animator class interface

Because drawing resized images is potentially slow, Window_Animator stores the resized images for future use. The first time the animation is performed, it will proceed relatively slowly; subsequent animations will run at full speed because the stored images can be displayed rapidly. 5

Implementation

Issues

This section describes some of the more interesting implementation issues we faced in building the animated widgets in InterViews, and it provides the basic algorithms to reproduce these results in other windowing toolkits. In particular it describes the algorithms for the drawing of the Face class described in Section 4.1 and the calculation of the in-between matrices for the Path_Animator class of Section 4.1. 5.1

C a l c u l a t i o n s for the Face Class

The Face class takes a 2D object described in the (x,y) plane and transforms it using a given 3D transformation matrix. The transformed object is then orthographically projected back on to the original plane for displaying. Under these conditions, a 3D transformation matrix can be replaced with an equivalent 2D transformation matrix. Appendix A describes how to compute the equivalent matrix~ 5.2

I n - B e t w e e n i n g C a l c u l a t i o n s for P a t h _ A n i m a t o r

As described in Section 4.1, t h e Path_Animator class calculates transformations that specify the in-between frames which make up the animation sequence for a Path object. To allow for the slow-in/slow-out effect desirable in animations [3, 5], we use a mapping function based on a third order Bezier curve [2] to calculate the amount of change for each of the in-between matrices over time. This section describes the calculations for the mapping function and the inbetween transformation matrices.

37 B e z i e r C u r v e F u n c t i o n Figure 9 shows an example of a Bezier curve. The curve is defined by the 4 control points xl, x2, x3, and x4. The curve has the desirable "slow-in~slow-out"effect, where dB/dt is small for t close to 0.0 and 1.0. In other words, the rate of change will be small near the beginning and end of the interpolation. Appendix B shows the computation in detail.

B(t, xl, x2, x3, x4)

x3

/

1.0

x4

/

o.o

_

xl

x2

t

1.0

Fig. 9. Example Bezier Curve

I n - b e t w e e n T r a n s f o r m a t i o n M a t r i c e s The interpolation process provides in-between matrices for two given matrices; the initial transformation S and the final transformation F. Figure 10 shows an example of an initial and final transformation matrix displayed as vectors along the axes. A transformation consisting of a translation, set of rotations, and scaling is applied to the graphics in the coordinate system defined by S, to produce graphics rendered in the coordinate system defined by F. The interpolating function needs information about change in scaling (S), rotation (R), and translation (T). Given S, F and the interpolation function, B, we calculate nine quantities defining the amount of change for each step of the animation.

z ~ S x , z ~ S r , Z~Sz z~Rx , ZiRr , A R z

A T x , ATr , ~ T z

38 y,

Scale

Y

ation

z, /

v S

Translati F

Fig. 10. Example of two coordinate systems

The translation components, AT, are calculated by finding the incremental difference of the distance between the origins of each axis of S and F. The scaling components, AS, are determined directly from ratios of the magnitude of the axis vectors of S and F. The columns of the first three rows of a transformation matrix form the orthogonal X-Y-Z axes of its coordinate system. A change in the magnitude of these axis vectors produces a scaling along that axis. Finally, the rotation components, AR, are determined by calculating, for each of the transformation matrices S and F, a set of rotation angles that bring the axes described by the matrix S into alignment with the axes described by the matrix F. There are an infinite number of combinations of rotations to perform this alignment. We compute the angles in the following way. The rotation about the Y Axis is calculated first. This rotation brings the S Z Axis into the the F Y-Z Plane, as shown in Figure 11. The second angle of rotation calculated is about the X Axis, as shown in Figure 12. This rotation brings the S Z Axis in alignment with the F Z Axis. The final rotation angle about Z Axis is calculated to bring the 8 Y Axis in alignment with the F Y Axis. Figure 13 shows the final rotation. Once the 9 components have been calculated for the interpolation matrix, the interpolation matrix is constructed by the following transformation operations: 1. scale ASx, ASy, ASZ; 2. rotate Ry; 3. rotate Rx; 4. rotate Rz; and

39 Y

Y

2

2

s z~a~

/l x_axis rotation /

i\

~.

\

x a x i s rotalion /

:~ X 1

Fig. 11. Rotation about the Y Axis

~

\

>

x1

Fig. 12. Rotation about the X Axis Y

2

[\ x_axis rotation /

\

>

x1

3

Fig. 13. Rotation about the Z Axis

5. translate A T x , Z l T y , A T z . Appendix B describes the detailed calculations for the components of the matrix.

6

Conclusion

This paper has described how we extended an existing graphical user interface toolkits to support animated widgets. The components we added supported animation by transformation of glyphs, animation by flipbook, and animation by resizing windows. The paper describes the new components in terms of the C + + class functionality and programming interfaces, and it discusses some of the more interesting algorithms.

40 The paper makes three key contributions: 1. It highlights the importance of powerful graphics models in graphical user interface toolkits. 2. It presents a way of drawing 3D-like graphics using only 2D drawing and transformation techniques. 3. It describes a procedure for interpolating 3D transformation matrixes. The importance of the graphics model is demonstrated by the need for a powerful model in generating the appearance of animations. The task of providing animation was made much simpler in this work because InterViews supports the notion of arbitrary transformation of toolkit components. The pseudo-3D drawing technique allows the flexibility of expression afforded by 3D geometry specification, but does not require special hardware support. This work represents only the beginning of our investigation of animation and its application to graphical interfaces. In the short term, our aim is to apply our results to other aspects of the interface. For example, we are investigating how animation can help strengthen the illusion of direct manipulation that underlies many interfaces. In the longer term, we hope to define a set of tools and techniques that interface programmers can use to add such effects to their creations.

References 1. AT&T. C-f-I- Language System Release 2.1, Product Reference Manual. 2. Richard H. Bartels, John C. Beatty, and Brian A. Barsky. An introduction to the use of splines in computer graphics. University of waterloo TR CS-83-09 / UC Berkeley TR UCB/CSD 83/136, Unversity of Waterloo and University of California, Berkeley, 1985. 3. Bay-Wei Chang and David Unger. Animation: From cartoons to the user interface. In Proceedings of the A CM SIGGRAPH Symposium on User Interface Software and Technology, pages 45-55, 1993. 4. James D. Foley, Andries van Dam, Steven K. Feiner, and John F. Hughes. Computer Graphics: Principles and Practice. Addison-Wesley Publishing Co., Reading, MA, 1990. 5. Scott E. Hudson and John T. Stasko. Animation support in a user interface toolkit: Flexible, robust, and reusable abstractions. In Proceedings of the ACM SIGGRAPH Symposium on User Interface Software and Technology, pages 57-67, 1993. 6. John Lasseter. Principles of traditional animation applied to 3D computer graphics. In SIGGRAPH '87, pages 35-44, Anaheim~ CA, July 1987. ACM, ACM Press. 7. Kit Laybourne. The Animation Book. Crown Publishers, Inc., New York, NY, 1979. 8. Mark A. Linton, John M. Vlissides, and Paul R. Calder. Composing user interfaces with InterViews. IEEE Computer, pages 8-22, February 1989. 9. George G. Robertson, Jock D. Mackinlay, and Stuart K. Card. Cone trees: Animated 3D visualizations of hierarchical information. In Proceedings of ACM CHI'91 Conference on Human Factors in Computing Systems, pages 189-194, 1991.

44 10. Paul S. Strauss. Iris inventor, a 3D graphics toolkit. In Andreas Paepcke, editor, OOPSLA '93, pages 192-200, Washington D.C., October 1993. ACM, ACM Press. 11. Piyawadee Sukaviriya and James D. Foley. Coupling a UI framework with automatic generation of context-sensitive animated help. In Proceedings of the A CM S I G G R A P H Symposium or* User Interlace Soj~ware and Technology, pages 152166, 1990. 12. Bruce H. Thomas and Paul R. Calder. An animated widget kit for interviews. In OzCHI 94 Proceedings, pages 203-208, Melbourne, Australia, November 1994. 13. Bruce H. Thomas and Paul R. Calder. Using animation to enhance look and feel. Technical Report CIS-94-014, School of Computer and Information Science, University of South Australia, September 1994. 14. Bruce It. Thomas and Paul R. Calder. Graphical feedback for direct manipulation of simple polygons. Technical Report CIS-95-007, School of Computer and Information Science, University of South Australia, February 1995.

A

3D and 2D Transformation Equivalence

If a 3D graphical transformation,

M =

rll r12 r13 0 1 II r21 r22 r23 0 /

/,'31

r33 0 /

(1)

1] is applied to an object that lies entirely in the plane z -- 0, and the transformed object is viewed along the z axis under orthographic projection, then the transformation can be replaced by an equivalent 2D transformation, D - - |r21 r22

(2)

Lt~ ty To see why, consider the equivalent 3D transformation matrix, M ~, that is the result of multiplying the transformation matrix M with the orthographic projection matrix

o =

00 [ ]10 00

(3)

00 Thus

M I=MO=

0 ~] F| rrll2 1 rr12 220 |r31 r32 0

(4)

o Since the object to be transformed lies within the plane z - 0, all points on the object are of the form P -- [ x y 0 1 ] and all points on the transformed object are of the form P~ = P M I = [ x I yt z' 1 ], where

42 x ' = r l l . x + r 2 l . y + r 3 1 . 0 + t=

y' = r12 9x q- r22 9y + r32 90 + t~ z' = 0 . x + 0 . y + 0 . 0 + 0 Note that, as required, the z component of the transformed object is zero (the object lies in the z = 0 plane), and that the z and y components of the transformed object do not depend on/'31 or /'32 since the z component of the original object is zero. Finally, note that this result is identical to that obtained by the 2D transformation r l l r12 ! ]

P'=PD=[xyl]

|r21r22

=[~'r

1],

(5)

kt= ty where x t = r l l 9 x + r21 9 y + t= y ' -= r12 . x + r22 . y + t y

(6) B

In-Betweening

B.1

Calculations

for Path_Animator

Bezler Curves

We use a recursive formulation of the Bezier construction to calculate the interpolation coefficient.

6(t, Zl, z2, z3, z4) =

I B ( 2 - t , xl, I x~, f x3, I x4) I

where # X 1 --- X l

z4

if

t < 0.5

B(2 (t - 0.5), ~1, " " z" ~2, ~, ~ ) if t > = 0.5

(zl + 3 z 2 + 3 z 3 + z 4 ) / 8

and

= (~1 + 3~2 + 3~3 + ~4)/8 z2 = (z2 + 2z3 + z4)/4 9 ~'

]!

X~ ~ X4

(7)

43 B.2

In-between Matrices

The components of a matrix that interpolates a start matrix S and finish matrix F are calculated as follows. The translation components, AT, are calculated by finding the incremental difference between the translations of each axis of S and P. The following equations show the calculations: ATx = (F41-S4~).B

z~Ty : ( F 4 2 - S 4 2 ) " ~ J ATz= (F43-S43).B

(8) (9) (10)

The scaling components, AS, are determined as follows: aSx

= (Sx, - Sx~) . t3

(11)

nSr

= (Sr,

asz

= (sz~ - S z D

(12) (13)

-

sr~ ) . t3 .s

where Sx = x / r n 2 + r212 + r312

(14)

S r = x/r122 + r222 + r32 ~

(15)

SZ ---- X/rl32 -b r232 q- r332

(16)

Finally, the rotation components, AR, are determined by calculating, for each of the transformation matrices S and F, a set of rotation angles that bring the axes described by the matrix S into alignment with the axes described by the matrix F. The rotation about the Y Axis is calculated first. This rotation brings the S Z Axis into the the F Y-Z Plane, as shown in Figure 11. The angle of rotation is calculated as A R y = y_axis. B.

(17)

where

y_azis =

- 1 2 . aresin(rzl/dl) if r33 > = 0.0 180.0 + (arcsin(r31/dl)) otherwise

(18)

and dl = x/rz3 2 + rzl 2

(19)

The second angle of rotation calculated is about the X Axis, as shown in Figure 12. This rotation brings the S Z Axis in alignment with the F Z Axis. The calculation of this angle of rotation is calculated as AIRx = z_azis . B.

(20)

where x_axis =

arcsin(r32/d2) if r33 > = 0.0 180.0- (arcsin(rz2/d2) otherwise

(21)

44 and

(22)

d2 -- v/r332 + r32~

The final rotation about Z Axis brings the 8 Y Axis in alignment with the F Y Axis. Figure 13 shows the final rotation. The calculation of this rotation is in two parts. First an intermediate Y Axis is calculated by rotating the S Y Axis y_axis, Eq 18, and x_axis, Eq 21. The transformation matrix T = RAy_axis)R~(x_axis)

(23)

is used to calculate the intermediate axis, [r12 r22 r32 1] T = [Yl Y2 Ya 1].

(24)

With this new axis, the final angle of rotation, A R z , about the Z Axis is calculated as

A R z = z_axis. I3.

(25)

arcsin(yl/d3) if y2 > = 0.0 z_axis = [ is0.0 - ( a r c s i . ( y l / d 3 ) otherwise

(26)

where

and d3 -- ~r

2 4- y22 + y32,

(27)

The final matrix for the in-between frame of the animation can be determined as follows

M =

ASy 0 0 ASz o o

RyR~R~

1

0

0 1 A T x ATy a T z

(28)

where Ry is the matrix that rotates by A R y about the Y axis, R~ is the matrix that rotates by A R x about the X axis, and R~ is the matrix that rotates by A R z about the Z axis