Published:
March 25, 2007
Last Updated: October 26, 2007
By Richard G. Baldwin
Alice Programming Notes # 900
This document serves as an appendix to a series of programming tutorial lessons that are designed to teach you how to program using the Alice programming environment under the assumption that you have no prior programming knowledge or experience.
The purpose of this appendix is to explain and to illustrate the behavior of the twenty primitive methods that belong to all, or at least most Alice objects.
I recommend that you open another copy of this document in a separate browser window and use the following links to easily find and view the figures, listings, and tables while you are reading about them.
Once you have mastered Alice, I recommend that you also study the other lessons in my extensive collection of online programming tutorials. You will find a consolidated index at www.DickBaldwin.com.
The purpose of this document is to provide reference material explaining and illustrating the behavior of the twenty primitive methods that belong to all, or at least most Alice objects. Before doing that, however, I will need to provide some general background information about the construction of programs in Alice.
Computer programs accomplish what they accomplish by performing operations on data. For example, a banking program performs operations on a variety of different kinds of data such as account balances, deposits, etc.
The primary kinds of data that are used in Alice programs are the following:
(If I omitted any important kinds of Alice data, please send an email telling me what I omitted.)
|
In a manner similar to the way that animals are subdivided into dogs, cats, tigers, bears, etc., data is subdivided into types. The primary types in Alice are:
A class is a blueprint or plan from which one or more identical objects can be constructed. This is similar to constructing several condominiums from a single set of blueprints or plans. Frequently a condo starts out being identical to other condos in the project. However, you can customize your condo if you choose by painting it a different color, putting down different carpet, etc.
In a similar manner, even though all objects constructed from a given class start out being identical, you can customize them by causing their property variables (such as the color property) to have different values.
The Local Gallery and the Web Gallery in Alice contain perhaps a thousand or more different classes that can be used to construct objects. Those classes describe things like penguins, flashlights, parking meters, etc. In addition, you can extend or customize those classes to create new classes of your own design.
In object-oriented programming jargon, an object is an instance of a class. In other words, a single object is the product that results from constructing a single instance of the thing that the class (blueprint or plan) describes. For example, a condo is a single instance of the blueprint that is used to construct several initially identical condos.
Any number of identical instances (objects) can be constructed from a single class. Once an object has been constructed, it can be customized by assigning different values to the object's property variables.
Just like plants and animals, objects have behavior. A method is the mechanism by which the program sends a message to an object asking it to execute one of its behaviors. For example, the method named move, when executed on an Alice object, will cause the object to move a prescribed distance in a prescribed direction in the 3D world represented by an Alice program.
Just like newborn babies, when a new object is created, it already has a set of behaviors that it knows how to execute when asked to do so. Figure 1 contains a list of the twenty primitive methods belonging to all (or at least most) Alice objects.
Figure 1. Alice primitive methods.
Alice primitive methods
|
A shortage of documentation on primitive methods
As of the date of this writing, I have been unable to find a single document that explains the behavior of these primitive methods anywhere on the web. The main purpose of this appendix is to explain, and in most cases to illustrate, the behaviors that these primitive methods impart to the object to which they belong.
Method names are important but not sufficient
In some cases the method names clearly indicate the imparted behavior. However, in other cases, the method names are ambiguous with regard to imparted behavior. For example, the differences in behavior imparted by the methods named turnToFace and pointAt are very subtle. Sometimes, either method will suffice for a particular purpose, but sometimes that is not the case.
The method named moveAwayFrom
Similarly, the behavior imparted by the method named moveAwayFrom is also ambiguous. We can surmise that this method will cause one object to move away from another object, but in what direction? Will the object move forward, backward, or sideways? If sideways, will it move to the right or to the left? You will find the answers to many questions like this in this appendix.
The method named turn
At first glance, the method named turn seems straightforward enough. However, when you write code to cause an object to turn, you must select one of the following method parameters:
Experienced programmers can probably figure out what it means to turn LEFT or RIGHT but that is not necessarily true for an aspiring programmer with no programming experience. Even an experienced programmer may have some difficulty figuring out what it means to turn FORWARD or BACKWARD since those two terms have a different meaning with regard to the Alice turn method than they typically have in everyday life.
The turn method versus the roll method
As another example, what is the difference between telling an object to turn RIGHT or to roll RIGHT? Once again, an experienced 3D graphics programmer could probably figure this out, but an experienced programmer whose programming background is mainly in the business and database area may have some difficulty with this one.
Take the mystery out of the methods
In this appendix, I will take the mystery out of the behavior of the twenty primitive methods. Be aware, however, that because I haven't found any real documentation on the primitive methods, the information that I will provide in this appendix will be based solely on my experimentation. This experimentation may fail to identify some of the subtleties in the behavior imparted by some of the methods. If you discover that any of my explanations are inaccurate or incomplete, please send an email message advising me of that fact.
In addition to the primitive methods, some of the classes in the Local Gallery provide custom methods. For example, an object constructed from the Penguin class has the following custom methods in addition to the primitive methods:
There are subtleties in the behavior imparted by some of the custom methods as well, but I won't attempt to explain custom methods in this appendix. For example, what is the difference between the method named walk and the method named walking? Maybe that will be another task for another day.
In addition to the primitive methods and the custom methods, it is also possible for you as the programmer to add your own new methods to an object. I mention this here only for completeness, as that is a topic that will not be addressed in this appendix at all.
|
A method parameter (sometime called a parameter variable) is the mechanism by which you provide information to the method when you send the message to the object asking it to execute the behavior imparted by that specific method. We commonly refer to this as passing a parameter to the method.
Required parameters
A review of the Alice development screen reveals that all but one of the primitive methods requires one or more parameters to be passed to the method when it is called. Typical parameters are directions, amounts, etc. (The method named standUp doesn't require any parameters, but there are default parameters even for this method.)
Default parameters
Default parameters are those parameters for which default values are already established, but for which you may provide values that are different from the default if you elect to do so. Each primitive method has several default parameters. Each default parameter has several allowable values. (See Table 1 for an example.) Obviously, I won't be able to explain how they all impact the behavior of a primitive method in this document, but I will try to explain some of the most commonly used default parameters.
Specifying default parameter values
Figure 2 shows a (cropped and somewhat reduced) screen shot showing the mechanism by which default parameter values are specified.
Figure 2. Screen shot showing default parameters.
|
|
To specify a default parameter, you click on one of the little triangles that point down in the program instruction. This causes a cascade of popup menus to appear from which you make your selection. For those cases where the parameter value is a numeric value and the value that you need isn't one of the visible choices, you can select a menu item labeled other. This will pop up something resembling a calculator keyboard, which you can use to specify any numeric value.
The behavior imparted by many of the primitive methods causes the object to take some action relative to Alice's 3D world, and the 3D coordinate system that describes that world. Therefore, in order to understand the behavior of many of the methods, you must first understand the coordinate system.
I discuss these issues in much more detail in another lesson titled "Learn to Program using Alice, Objects in 3D Space" (see Resources). Therefore, the material on this topic in this appendix will primarily be a recap.
What happened to the X, Y, and Z coordinate system?
Historically, programmers working in 3D space have considered 3D space to be described by three orthogonal axes, typically referred to as X, Y, and Z. However, the developers of Alice have gone out of their way to avoid this nomenclature. The 3D space in an Alice program is still represented by three orthogonal axes, but directions in Alice are commonly described as RIGHT, LEFT, UP, DOWN, FORWARD, BACKWARD, etc.
|
Just about everything in Alice, including the world is an object. Every object in Alice has a center point and has its own set of three orthogonal axes. The center point is the single point in or near the object where the three orthogonal axes cross. This would be referred to as the origin in other programming environments.
Moving and rotating an object
When you move an object, you move its center point. All three of its orthogonal axes come along for the ride. When you rotate an object around one of its axes, the orientation of that axis stays the same but the orientations of the other two axes change.
Illustrate the axes with pictures
I will illustrate the Alice coordinate system using a series of pictures. I don't know of any way to directly display the axes that describe the world, but it is relatively easy to display the axes of any other Alice object. All you need to do is to select the object in the object tree while operating in the scene editor mode (as opposed to code editor). However, there is an indirect way to display the axes of the world, and the result is shown in Figure 3.
Figure 3. The axes of the world.
|
|
Figure 3 shows a world where the ground is covered with snow. This is convenient because I needed a white background to show you what I need to show you.
Displaying the ground object's axes
For Figure 3, I called the primitive method named setPointOfView on the ground object to cause its viewpoint to be aligned with the viewpoint of the world object. In other words, I caused the center point of the ground to match the center point of the world, and caused the ground to have the same orientation as the world. Then I selected the ground in the object tree to cause its three axes to be displayed. The three axes shown in Figure 3 overlay the three corresponding axes of the world.
The red, green, and blue axes
Even though it may not seem to make sense in some cases, every Alice object has a front, back, right, left, top, and bottom. The blue axis shown in Figure 3 always points in the direction looking out from the front of the object (the direction that the headlights on an automobile shine).
The red axis in Figure 3 always points in the direction looking out from the right side of the object (the direction that you point if you extend your right arm directly out from the right side of your body).
The green axis always points in the direction looking out from the top of the object (the direction that I look when I look out of the sun roof of my car).
In the more conventional notation used in other 3D programming systems, I believe we would say that red equates to X, green equates to Y, and blue equates to Z.
Does the ground have a front and a back?
If we stand on the ground and look around in the real world, we would probably agree that the ground has a top. Does it have a bottom? It doesn't make a lot of sense in the real world to talk about the right side, left side, front, back, and bottom of the ground. Nonetheless, the ground is an object in Alice. Those concepts apply to the ground (and all other objects) in Alice and the coordinate system for the ground is based on those concepts.
A flashlight aligned with the world
To get a little closer to something that makes more sense in the real world, Figure 4 shows a flashlight for which the viewpoint of the flashlight has been aligned with the viewpoint of the world.
Figure 4. A flashlight aligned with the world.
|
|
With the flashlight, the concept of the front and the back makes a lot of sense, but since a flashlight is typically a cylindrical tube, the concept of the right side, left side, top, and bottom doesn't necessarily make sense. Once again however, they exist for the flashlight in Alice and the coordinate axes for the flashlight shown in Figure 4 are based on those concepts.
Where is the bottom half of the flashlight?
Note that the flashlight shown in Figure 4 is half buried in the snow. This is because the center point of the ground (the snow) is at the surface of the snow. The center point for the flashlight is in the middle of the flashlight. Therefore, once the viewpoints of the two objects are aligned, half of the flashlight is on the top of the ground and the other half is protruding from the bottom of the ground. (The ground in Alice is a very thin sheet with open 3D space underneath.)
What about the yellow lines?
At this point in the discussion, you should simply ignore the faint yellow lines in Figure 4 and Figure 5. They have no bearing on this discussion but I had no way to eliminate them from the images. I will explain what they are later.
Flashlight moved and rotated
Figure 5 shows the result of first driving a stake through the original center point of the flashlight to serve as a visual reference, and then moving and rotating the flashlight.
Figure 5. Flashlight moved and rotated.
|
The flashlight was moved forward, to the right, and up by one-half meter in each of those three directions. Then it was rotated to the left (around the blue axis) by 45 degrees.
Note first that the center point of the flashlight, along with the three axes, moved along with the entire flashlight. Note also that the orientation of the blue axis did not change, but the red and green axes were both rotated around the blue axis by 45 degrees. This moving and rotating of the flashlight was accomplished by calling the move method three times in succession followed by calling the roll method once.
Two more pictures regarding the coordinate system
I have two more pictures to show you to help clarify the concept of an object having a front, back, right, left, top and bottom. Figure 6 shows a penguin standing on the ground where the viewpoints of the penguin and the ground have both been aligned with the viewpoint of the world.
Figure 6. Penguin aligned with the world showing ground's axes.
|
In Figure 6, the ground was selected in the object tree to cause its axes to be visible. As you can see, the blue axis points out in front of the penguin (along the surface of the ground), the red axis points out to the right of the penguin, and the green axis points up and out of the top of the penguin's head.
Now display the penguin's axes
Figure 7 shows the same world, but with the penguin selected in the object tree to cause its axes to be displayed.
Figure 7. Penguin aligned with the world showing penguin's axes.
|
Although they are more difficult to see because they are shorter, the red, green, and blue axes belonging to the penguin overlay the red, green, and blue axes belonging to the ground. Both of those sets of axes also overlay the corresponding axes belonging to the world, but we have no way to show that. (They overlay only because the viewpoints of all three objects were aligned.)
A penguin's belly is in the front
A penguin does have a front, back, right side, left side, top, and bottom, so in the case of a penguin (unlike the case of the ground and the flashlight), those concepts make very much sense in terms of what we know about the real world. However, the important point is that even if it doesn't seem to make sense in terms of what we know about the real world, every object in Alice has a front, back, right, left, top, and bottom. Every object also has a red axis, a green axis, and a blue axis, and they point in the directions of right, up, and front respectively.
The center point for the penguin
Note the center point for the penguin is not actually inside the penguin. Rather, it is half way between the penguin's feet at the level of the soles of the penguin's feet. (This is the point in 3D space where all three axes meet.)
What about the yellow lines?
This will also be an opportune time to provide a little information about the yellow lines that I mentioned earlier. As you may be able to see in Figure 7, they form the edges of a rectangular 3D box. This box is often referred to as the bounding box for the object, and its size is such as to enclose the entire object. The box has a height, a width, and a depth. These values can be accessed on any object using program code.
If you go back and look at Figure 5, you will note that the bounding box is much larger than the flashlight. That is because the flashlight object also includes a cone shaped light beam that extends far out in front of the flashlight and becomes very wide at a point at some distance from the flashlight lens. However, the light beam isn't very bright and can't be seen against the white background in Figure 5. The light beam is included in the bounding box for the flashlight.
In the following sections, I will explain and illustrate the behavior of the twenty primitive methods that belong to all, or at least most Alice objects.
|
Will provide sample code
In many cases, in addition to providing a verbal explanation of the behavior, I will also provide the source code for one or more short programs that you can write to see the behavior in action. I have also provided a zip file containing the Alice a2w files for each of the sample programs (see Downloads). You can download those files and run them in your Alice 2.0 environment.
Also, in some cases, I will walk you through a series of manual interactive method calls that demonstrate the behavior of the method being discussed. (See setPointOfView for example.)
Creating your worlds
In some cases, I will also explain what you need to do to create the world necessary to write the program, such as which objects to place in the world, before you begin writing code. However, in most cases, that should be obvious so I will omit the setup instructions in most cases. In those cases, if you can't figure out how to create the world, you can download the program and open it in your Alice environment.
Houston, we have a problem!
My objective is to make it possible for you to reproduce my results exactly. Therefore, I normally won't ask you to make manual adjustments to the size, orientation, or position of an object simply by dragging the mouse. However, there is one situation that can cause us to get different results over which I have no control.
The lens angle slider
When the Alice development environment is in the Scene Editor mode, it is possible to expose a slider near the upper right corner of the screen labeled "lens angle." If you change the position of that slider, you will get a different view of the world.
If we each play the world without having that slider in the same position, the objects on your screen will be either larger or smaller than the objects on my screen. In addition, our two cameras will have different field widths. This is essentially a manual zoom control. As far as I know, there is no way to control this zoom factor under program control, so there is no way to guarantee the repeatability of the visual aspects of a program.
Just so you will know, I normally operate my system with that slider about one-eighth of the way from the left end and keep the slider hidden so that I won't accidentally change it. However, if your objects appear larger or smaller than mine, try adjusting that slider to see if you can cause them to be approximately the same size.
The order of the method descriptions
For your convenience in using this document as reference material while writing your Alice programs, I have arranged the explanations of the methods in the same order that they appear in the methods tab of the details panel in the Alice development environment. This is also the order that they appear in the Table of Contents.
However, that isn't necessarily the best order for you to study the behavior of the methods. Also, that isn't necessarily the best order for me to write the explanations. I will write the explanations in a different order than the order in which the methods appear in this appendix. This will result in the figures and the listings not necessarily being in numeric order. However, you will find an index to all of the figures and the listings here. That index is in numeric order.
You will find an index to all of the methods in the order that they appear in the methods tab of the Alice details panel here. Just select a method name and click on it to jump to the section of the appendix in which the method is explained.
You will also find an index to all of the methods in the order that I recommend that you study them (the recommended study trail) here.
The recommended study trail
To help you in your efforts to study the material in this appendix, I have marked out my recommended trail through the various sections that explain the methods. I refer to this as the recommended study trail. At the end of each section that explains a method, I have provided a hyperlink to the method that I recommend you study next. At the beginning of each section that explains a method, I have provided a hyperlink back to the previous lesson on the recommended study trail.
Of course, you should feel free to study this material in whatever order works best for you.
The points on a compass
One way to think about the Alice 3D world is to think of the plane described by the red and blue axes as the surface of a flat earth, with the green axis pointing straight up into the sky.
If we think of it that way, then the blue axis points toward the south and the red axis points toward the west. This makes it a little easier to talk about and to explain what we are doing in some cases.
The front of the world faces south
Given this convention, it can be shown through experimentation that he "front" of the world faces south, whatever that means.
However, what it means becomes clearer when we align the viewpoint of another object with the viewpoint of the world. The front of the new object will also face south.
The penguin is facing south
When considered in this manner, the penguin shown in Figure 6, (whose viewpoint was aligned with the viewpoint of the world), is facing south. If he were to raise his right wing, it would be pointing west.
Feel free to jump around
You should feel free to jump around and study the explanations of the methods in whatever order makes the most sense to you. Be aware, however that unlike a true documentation package (such as the Java API documentation from Sun) the descriptions of the methods in this document are not independent of one another. In other words, the discussion of a particular method will frequently refer back to, or perhaps depend upon a previous discussion of a different method and those discussions are not intended to stand alone. Therefore, you may get more out of the material if you follow my recommended study trail and study the method descriptions in the order that I recommend, at least during your first pass through the methods.
|
I will be using the method named setPointOfView extensively from the beginning of the discussion so that would be a good place for you to begin studying the behaviors of the primitive methods. Therefore, I recommend that your first stop on the recommended study trail be the section that explains the method named setPointOfView.
This section contains a link to the explanation of each of the primitive methods in the order that I recommend that you study them.
Recommended study trail: Return to the explanation of the method named setPointOfView.
Brief description: A method to cause an object to be moved in a specific direction by a specific distance.
A fairly simple method
The move method is one of the simplest of all the primitive methods, particularly if you don't change any of the default parameter values.
Because of the simplicity of the method, it will provide us with a good opportunity to illustrate changes in two of the default parameters and to discuss a third default parameter. Those three default parameters are:
Writing the program named move01
The source code for my version of a program named move01 is shown in Listing 1 near the end of the lesson. You can also download a completed version of the program.
Create a new world
To write your own version of the program, create a new world, select the snow template, add a penguin from the Animals subsection in the Local Gallery to the world and save the world as move01.
The main method
Change the name of the default startup method to main. All of the code in the program will be contained in the main method.
Six lines of comments
The program begins with six lines of comments. I placed those comments in a doInOrder construct so that I could collapse them into a single line during editing to save space and eliminate congestion on the edit screen.
Initializing the viewpoints of the objects
Most of the code in this program is used to initialize the viewpoints of all the objects to known repeatable viewpoints. This should make it possible for you to replicate the program and have it produce the same results.
Initializing the viewpoint of the camera
The next major block of code is the code in the block under the comment that reads "Set viewpoint of the camera." That block of code sets the viewpoint of the camera. I also placed this code in a doInOrder construct for the same reason given above. You will see that I almost often do this.
The camera code begins by calling the setPointOfView method to cause the viewpoint of the camera to be aligned with the viewpoint of the world. The purpose for making this method call is to cause the camera to start off with a known viewpoint. As I mentioned earlier, this causes the camera to be facing south. Assuming that the center point of the camera is at the center of the lens, it also means that half of the lens will initially be buried below the surface of the ground. This is because the center point of the ground, which will later be aligned with the viewpoint of the world, is at the surface of the ground.
Required parameters for the move method
The move method requires only two parameters:
The allowable values for the direction parameter are:
|
If you want to cause the object to move in some direction that is not included in the above list of allowable values, you must make either two or three separate moves, the result of which will resolve to the desired direction and distance. Note however that because of the doTogether construct provided by Alice, the fact that you have specified three separate moves to accomplish a single move won't necessarily be apparent to the viewer.
|
Allowable values for the amount
The allowable value for the amount can be anything you want it to be as long as you can express the amount in meters or fractional parts thereof. You can even specify a negative value for the amount, which will effectively reverse the specified direction of the move. (In some cases, negative values for the distances can be used to reduce the required number of instructions in a program.)
The duration parameter
This will be an opportune place to discuss the parameter named duration. This is one of the default parameters mentioned earlier. You will see a value of 0 for that parameter being passed to the setPointOfView method in every one of the method calls in the block of code that was used to set the viewpoint of the camera in Listing 1.
A default value of one second
This parameter has a default value of one second. That means that if you don't specify the value of this parameter when you make the method call, the method will require one full second to complete, even if the computer can complete the action much more quickly.
Animation speed is often lower than computer speed
When we make method calls to animate an object, we often slow the action down to the point that a human observer will be able to see and understand what is happening. The intended purpose of the duration parameter is to allow us to control the elapsed time for every action that we ask an object to perform. We can set the value of the parameter to any amount of time in seconds, including fractional parts of seconds or zero. (Negative values seem to be treated the same as 0.)
Don't want to slow down the initialization of the viewpoints
Since the method calls that were made on the camera object are there for the sole purpose of setting the initial viewpoint of the camera, we would like for them to be completed as quickly as possible. Therefore, the value of the duration parameter was set to 0 for every method call that was made on the camera. This means that the action will be performed and the method will return as quickly as the computer is capable of performing that action.
Think about the viewpoint of a camera
Now think for a moment about the viewpoint of a camera. If you are taking pictures and your subjects are facing south, the camera needs to be facing north. In other words, the front of the camera needs to be facing the subjects (even if the subjects are not facing the camera). Also, the camera usually needs to be several feet above the ground, and several feet away from the subjects. The remaining four method calls that were made on the camera in Listing 1 were designed to accomplish those two purposes.
Calling the turn method
The statement that calls the turn method with one parameter value of LEFT and a second parameter value of 0.12 revolutions causes the camera to rotate to the left around its green (vertical) axis by 45 degrees. This causes the camera to be facing toward the southeast. (I will have much more to say about the turn method in the section that explains that method.)
Move forward, turn again, and raise the camera
The call to move the camera FORWARD by 20 meters does just that. It moves the camera without changing its orientation.
The call to turn the camera to the LEFT by 0.5 revolutions causes the camera to end up facing towards the northwest.
The call to move the camera UP by 2 meters causes the camera to be elevated above the ground by 2 meters without changing its orientation. (Obviously, this is not the only way, or even the most compact way to set the initial viewpoint of the camera.)
The camera has a known viewpoint
At this point in the program, the camera has a known viewpoint. In a more complicated animation program, this known viewpoint can serve as the starting viewpoint for the camera. The camera's viewpoint may be adjusted many times during the remainder of an actual animation program. However, because the camera starts with a known viewpoint, the program can use that known viewpoint in conjunction with the known values of all subsequent viewpoint adjustments to know exactly what the current viewpoint of the camera is throughout the remainder of the program execution.
Play the world
If you download this program and play the world, you will see this camera movement taking place very quickly, but not quickly enough to make it invisible to a viewer. In fact, the camera motion can be somewhat annoying to the viewer.
|
In addition to causing the initial viewpoints of the objects to be set very quickly (by setting the duration parameter value to 0), it is also a good idea to set the isShowing property value of all the objects to false (make them invisible) before executing this initialization process for setting the viewpoints. Otherwise, you will probably see some undesirable flashing on the screen.
Set viewpoints of the ground and the penguin
The next two statements in Listing 1 call the setPointOfView method twice in succession for the purpose of aligning the viewpoints of the ground and the penguin with the viewpoint of the world. Once again, the value of the duration parameter was set to 0 in both cases to cause this to happen very quickly.
Now begin the animation
In an actual animation program, this is the point in the program where I would start making objects visible and calling methods on them to control their behavior (to animate the objects). In this program, the animation is very simple. The penguin is moved RIGHT by 10 meters with a duration of 2 seconds. Then the penguin is moved LEFT by 10 meters also with a duration of 2 seconds. When the program ends, the penguin is back at his initial position.
Using the style parameter
However, the second movement is not simply the reverse of the first movement. Another default parameter named style is used to control some of the fine details regarding the movement in each direction. This parameter specifies how the object will start and end the motion. The allowable values are:
Option 1 is the default value
When the penguin moves to his RIGHT in Listing 1 without me having set a new value for the style parameter, the movement behaves according to the first option in the above list of allowable values.
Try option 4
The fourth option was specified for the style parameter when the penguin moved back to his LEFT in Listing 1.
Can you see the difference?
If you download and run this program, you should see the penguin move to his RIGHT and then move back to his left. It will be interesting for you to see if the motion in one direction looks any different from the motion in the other direction on your computer. On my computer, (which is fairly slow), the motion is not very smooth in either direction, so it is difficult for me to tell the difference between the two styles. You might try changing the value of the duration parameter in both statements to see if that makes the difference between the two styles easier or more difficult to see.
A case where the different styles can be seen
The situation where I have noticed that the style has the greatest visual effect is where one motion leads directly into another motion and it is desired that the two motions fuse together to look like a single smooth motion.
With option 1 or 3 (END_GENTLY) for the first motion, or option 2 (BEGIN_GENTLY) for the second motion, you can sometimes see what appears to be a slight undesirable pause at the end of the first motion and the beginning of the second motion. This is a case where ending the first motion ABRUPTLY and beginning the second motion ABRUPTLY seems to work best.
|
The asSeenBy property
There is another default parameter named asSeenBy, which comes up often, and which can be used to create very interesting effects. I believe that the default value for this parameter is normally <None> but the allowable values are all of the objects in the world, including the world, the camera, and the light.
For example, there are two calls to the move method at the end of the program named move01 as shown in Listing 1. The first call tells the penguin to move to its RIGHT (the direction of its red axis) by 10 meters. The second call tells the penguin to move to its LEFT by 10 meters. When you play the world, you see the penguin move first to its right followed immediately by a movement to its left.
|
If you were to modify those two method calls to set the value of the parameter named asSeenBy to the camera, and leave the directions of movement the same, you would see the penguin move first to its left (which is the camera's right), followed by a movement to the penguin's right (which is the camera's left).
A little more on the parameter named asSeenBy
Many of the primitive methods support the default parameter named asSeenBy, and the effect of setting the value of this parameter to some object other than the object on which the method is being called will depend on the specific behavior of the method involved. However, I want to give you one more explanation in an attempt to help you to envision the effect of this parameter. I will do this by describing an animated scene. I recommend that you actually create this scene and observe its behavior as you read my description.
A description of the world
Begin with a new world containing the ground, the light, the camera, and an ice skater. Align the viewpoint of all the objects to the viewpoint of the world. Then turn the camera to face north, move it to a position that is about twelve meters to the south of the center of the world, and move it up about one meter above the ground. At this point, the blue axis belonging to the camera will be parallel to the ground pointing due north across the center of the world and the center of the ground.
Turn the ice skater to face due east, and move her west by three meters. At this point, she will be on the left side of the scene as viewed by the camera, facing due east. Her blue axis will be pointing due east across the center of the world and the center of the ground.
Two different animation scenarios
We will consider two different animation scenarios. For the first scenario, the ice skater will simply glide six meters east, ending up on the right side of the scene, still facing east. On the second scenario, she will do the same thing, but in addition, she will turn a flip in the air as she traverses the middle two meters of the trip.
The first scenario
For the first scenario, the animation could consist of a single statement causing the ice skater to move forward for six meters. However, for reasons that will become more obvious later, we will write three statements, each one of which will cause her to move forward by two meters. To make the motion look smooth, we will use the style parameter to cause an abrupt transition between the three segments of motion.
A very important point
Although we could accomplish each segment of this motion by causing the ice skater to move FORWARD, simply accepting the default value for the asSeenBy parameter, we could also accomplish exactly the same thing by causing the ice skater to move RIGHT asSeenBy the camera. Optionally, we could accomplish the same thing by causing the ice skater to move LEFT asSeenBy the ground.
The easiest way to accomplish this motion would be to simply accept the default value of the asSeenBy parameter which is what we will do. This will cause the skater to move forward relative to herself, or more technically asSeenBy herself.
The second scenario
In the second scenario, we want the ice skater to turn a flip in the air during the second two-meter segment of the trip across the ice. (Now you will see why I broke the trip into three segments, each two meters in length.) We don't need to modify the behavior of the ice skater during the first and third segments, so we can leave that code alone and modify only the code that describes the behavior of the ice skater during the middle two-meter segment.
How to turn a flip in the air
Causing the skater to turn a flip in the air is a relatively simple thing to do. All we need to do is to cause the skater to turn (rotate) FORWARD around the middle part of her body and to keep moving forward at the same speed while rotating. Because we want the two actions to happen concurrently, we will need to enclose the code to rotate and the code to move forward within a doTogether block.
|
Simply add a turn Forward statement
Let's begin by placing the existing move statement for the second segment in a doTogether block and add a turn FORWARD statement to cause the skater to turn forward asSeenBy her skirt (which is one of the component objects that makes up the ice skater near the center of her body). This will cause the skater to rotate forward around the center of her body. (Note that this is another important use of the asSeenBy parameter.)
|
What's wrong with this picture?
When you cause an object to move forward asSeenBy itself, you cause it to move in the direction of the blue axis belonging to the object. Therefore, the existing statement that causes the skater to move forward for two meters during the middle segment of her trip causes the skater to move in the direction of the blue axis belonging to the skater.
How does the skater's blue axis behave?
What happens to the orientation of the skater's blue axis as the skater is rotating around the center of her body? If you could see the skater's blue axis while she is rotating, (see the sidebar regarding an Axes object) you would see that the blue axis also rotates much like the big hand on a clock. In fact, it starts out pointing east, makes a complete rotation pointing to each of the numbers on the face of an imaginary clock, and ends up pointing east again.
What happens to the skater's eastward motion?
Because the skater moves in the direction in which her blue axis is pointing, her eastward progress is stymied while she is rotating. In fact she moves down (toward the 6 on the face of the clock) a little, moves west a little, moves up a little, etc. When viewed as an animation, she actually appears to stop moving east while rotating around her skirt and then starts moving east again once the rotation is complete.
Newton would not be pleased
According to the laws of physics, we know that if she is moving forward when she begins her flip, she will continue to move forward as the flip progresses. We will need to do something to guarantee that she continues moving east regardless of the fact that her blue axis is rotating like the big hand on a clock.
And the solution is...
Fortunately, the solution to this problem is relatively simple. Rather than to cause the skater to move FORWARD asSeenBy herself during the middle two-meter segment of her trip, we can cause to the skater to either:
With the first option, she will continue to move in the direction of the red axis belonging to the camera. With the second option, she will continue to move in the opposite direction of the red axis belonging to the ground. Since neither of these axes will change their direction while she is doing her flip, her eastward progress won't be impeded by the fact that she is doing a flip.
More on the asSeenBy parameter later
We will see more interesting applications of the parameter named asSeenBy in conjunction with the discussions of the roll and turn methods later.
Other default parameters
Unless I made an error in compiling it, Table 1 shows all of the optional values for the two required parameters and the four default parameters belonging to the move method. The two required parameters and the four default parameters are shown in boldface. The various optional values for the different parameters are shown in regular typeface.
Table 1. Parameters and their options for the move method.
|
Note that other primitive methods may have fewer default parameters, more default parameters, or different default parameters than those shown for the move method in Table 1.
Wrap-up for the move method
Now you know how to use the method named move. You also know to use the duration, style, and asSeenBy parameters, which are common to many of the 20 primitive methods.
The next stop on the recommended study trail
You also learned a little about the turn method, but there is much more to learn about that method. The turn method and the roll method are very closely related. I recommend that you study the roll method next because it is a little simpler than the turn method.
Recommended study trail: Return to the explanation of the method named roll.
Brief description: A method to cause an object to either rotate around its red axis or its green axis, or to rotate around the red axis or the green axis belonging to another object.
|
The turn method and the roll method are very closely related. If you have studied the material on the roll method, you know this to be true because it is possible to call the roll method and get results normally considered to be the purview of the turn method. Similarly, as you will see in this explanation of the turn method, it is possible to call the turn method and get results normally considered to be the purview of the roll method.
I elected to discuss the roll method before discussing the turn method because the roll method is somewhat simpler than the turn method. At least, the turn method has fewer allowable values for its first required parameter.
Brief description of the turn method
As you learned in the discussion on the roll method, if you call the roll method on an object, and you don't specify some other object as the value for the default parameter named asSeenBy, the object will rotate around its own blue axis.
Similarly, if you call the turn method on an object and you don't specify some other object as the value for the default parameter named asSeenBy, the object will either rotate around its own green axis or rotate around its own red axis. The choice depends on the value that you pass as the first required parameter.
Required parameters
The turn method has two required parameters plus a variety of default parameters. The two required parameters are:
The allowable values for the first parameter are:
Specifying either of the first two parameter values given above will cause the object to rotate around its green axis (or the green axis belonging to another object). This is similar to turning a corner in an automobile.
Specifying either of the last two parameter values will cause the object to rotate around its own red axis (or the red axis belonging to another object). This is similar to an airplane flying along straight and level and then diving straight into the ground or climbing up toward outer space.
Allowable values for the amount parameter
You can specify any numeric value for the second required parameter named amount. This parameter specifies the amount of rotation to be executed. The value is given in revolutions or fractions thereof.
Three important aspects of the turn method
I will illustrate three important aspects of the turn method in this section:
The program named turn01
Let's get started writing (or downloading) the first program named turn01. I will explain things as we go along.
Create a new world, select the snow template, and save the world as turn01. Get a ToyPlane object from the Objects section of the Web Gallery (not the Local Gallery). Add the object to the world and rename it airplane.
Position is not critical
You can place the airplane anywhere in the world that you choose, because we will set its initial viewpoint with program code. Figure 8 shows an example of a raw world containing an airplane before the program starts running.
The red, green, and blue axes are visible
If you look carefully at Figure 8, you can see the blue axis protruding from the front of the airplane. You can also see the red axis protruding from the right wing, and the green axis sticking straight up from the cockpit.
The behavior of the turn method
As explained earlier, the default behavior of the turn method causes the object to rotate around its own red axis or its own green axis, depending on the value that you specify for the first required parameter.
Another option is to cause the object to rotate around the red or green axes belonging to another object. When the corresponding axes of the two objects are not parallel, the first object will rotate around the second object in a very complex way.
Description of the program
In this program, the airplane crosses the field of view of the camera moving from right to left. At first, the airplane flies level as shown in Figure 21. (This airplane object has a natural tilt when it is flying level.) Part of the way across the screen, the pilot pulls the control stick back causing the airplane to rotate BACKWARD around its red axis. This causes the airplane to climb. During the remainder of the trip across the screen, the airplane climbs as shown in Figure 22. (I will show you a much better way to do this later in conjunction with the method named moveAtSpeed. See Figure 50.)
Two screen shots of the running program
Figure 21 and Figure 22 show two screen shots taken while the program named turn01 was running.
Figure 21. Screen shot near the beginning of the program named turn01.
|
Figure 22. Screen shot near the end of the program named turn01.
|
Source code for the program named turn01
Listing 5 shows the source code for the program named turn01.
A relatively simple program
As you can see, this is a relatively simple program. Most of the code is used to initialize the viewpoints of various objects. You have seen lots of code like this before.
First call to the turn method
The first call to the turn method occurs in the section of code identified by the comment "Set viewpoint of the camera and the ground." As you can see, this method call causes the camera to rotate to the LEFT by one-half a revolution around one of its axes. Do you know which axis it will rotate around?
The green axis
The camera rotates around the green axis as a result of this method call. (This is part of the viewpoint initialization and not part of the actual animation that will be presented to the viewer.). The airplane will be flying from east to west, and the camera will be south of the airplane's path. This method call is necessary to cause the camera to face north so that it can see the airplane as it passes by.
Set viewpoint of the airplane
The next call to the turn method occurs in the block of code identified by the comment that reads "Set viewpoint of the airplane." This instruction to turn RIGHT causes the airplane to rotate around its green axis. The purpose of this method call is to turn the airplane to face the west. Then it will be moved backwards to the east side of the screen to get it ready to be animated.
Perform animation
The next and last call to the turn method in this program occurs in the block of code identified by the comment "Perform animation." Do you know which axis the airplane will rotate around as a result of this instruction to turn BACKWARD?
The red axis
If your answer was the red axis, you were correct. This method call causes the nose of the airplane to pitch upward, which in turn causes it to climb during the remainder of the trip across the screen.
Three sections of animation code
Note that this animation code is broken into three sections. The first section causes the airplane to move from right to left across the screen for a distance of one meter. This section of the trip occurs during a three-second interval and ends abruptly.
The second animation section comprises the code in the doTogether block, which causes the airplane to perform the following actions concurrently:
Note that both the turn and the move in this section begin and end abruptly and the move in the previous section ended abruptly. This causes the motion in the second section of code to fuse smoothly into the end of the motion for the first section. If those motions were caused to begin and end gently, there would be a noticeable pause at the interface between the two motions.
Once the turn has been completed, the airplane's blue axis is pointing up at an angle. The last section of animation code causes the airplane to move forward along the blue axis, which causes the airplane to appear to climb.
The program named turn02
This program illustrates the behavior of the turn method where one object rotates around the red axis belonging to another object and the two red axes are perpendicular to one another.
The airplane and the blimp
We will return to the scenario of the airplane and the blimp, which you have seen earlier. In this program, a small blimp is positioned directly beneath the initial position of the airplane. The airplane is facing due south, causing its red axis to point due west. The blimp is facing due east, causing its red axis to point due south.
Figure 12 shows the airplane and the blimp before they are moved into their initial viewpoints by the program code.
Convert a turn into a roll
To make a long story short, after initializing the viewpoints of the objects, the animation section of the program instructs the airplane to turn FORWARD around the red axis belonging to the blimp. However, if you use the source code in Listing 6 to write this program (or download it) and then play the world, you will see the motion more closely resembles a roll than a turn. The airplane flies forward along the blimp's red axis, rolling around that axis in a spiral fashion during the entire trip.
Screen shot near the end of the program named turn02
Figure 23 shows a screen shot of the airplane as it coming out of its last roll moving in a clockwise direction, getting ready to level out and fly over the camera.
Figure 23. Screen shot near the end of the program named turn02.
|
Source code for the program named turn02
The source code for the program named turn02 is shown in Listing 6.
This is also a relatively simple program, with most of the code being used to initialize the viewpoints of the various objects.
The initial viewpoints of the camera, the airplane, and the blimp
The initial viewpoint of the camera is at the center point of the world, facing due north, with an altitude of 20 meters.
The initial viewpoint of the airplane is ten meters north of the camera, facing due south with an altitude of 20.3 meters. Its red axis points to the west.
The initial viewpoint of the blimp is also ten meters north of the camera. The blimp's altitude is 20 meters, which is 0.3 meters below the airplane. The blimp is facing due east (see the call to the turn method in Listing 6) which causes the blimp's red axis to point due south (into the camera lens).
Skip down to the animation section
The call to the turn method in the animation section near the bottom of Listing 6 instructs the airplane to turn FORWARD for two revolutions in 15 seconds asSeenBy the blimp. In other words, this is an instruction for the airplane to rotate around the red axis belonging to the blimp.
Convert a turn to a roll
As you learned in an earlier discussion of the roll method, under certain circumstances, the roll method can turn a roll instruction into a turn. In this program, the motion of the airplane more closely resembles a roll than a turn. Thus, the circumstances of this program cause the turn method to produce a roll instead of a turn.
Why do I say that the behavior more closely resembles a roll than a turn? The airplane's nose doesn't pitch up or down in a direction that is perpendicular to the length of the wings, and the airplanes wing does not rotate around the airplane's green axis. Those are the characteristics of a turn. Rather, the airplane's left wing tilts downward and its right wing tilts upward, causing it to fly a spiral pattern around the blimp's red axis. This is what we would typically call a roll, not a turn. The airplane ends up flying directly over the camera at the end of the specified two revolutions.
The program named turn03
This is a long and rather complicated animation program that illustrates various aspects of the turn method. To set the stage, please take a look at Figure 24.
Figure 24. Setting the stage for the program named turn03.
|
|
As you might guess from Figure 24, this animation is a story about five penguins and a Zamboni® Ice Resurfacing Machine.
The program begins with three penguins standing in a line facing the front of a zamboni and two penguins standing on either side of the zamboni facing the other three penguins.
Description of the animation
To make a long story short, the zamboni starts moving toward the three penguins in the line. Only the middle penguin is in danger of being run over. The zamboni will fit between the other two penguins in the line. The middle penguin dives head first, burrowing into the ice (an obvious impossibility) and the zamboni passes above him without injury to life or limb.
Safe and sound
After the zamboni passes over the penguin, he emerges from the ice and stands back up. Shortly thereafter, all three of the penguins in the line turn to watch the back of the zamboni as it moves away from them.
A camera on a news helicopter
While all of this is happening, the camera is circling above the zamboni much in the fashion of a modern news camera mounted on a helicopter.
As you can tell from the description, there is quite a lot of action in this animation. Much of that action hinges on the use of the turn method.
Penguin diving for cover in the program named turn03
Figure 25 shows the middle penguin in the group of three penguins diving for cover in front of the zamboni. (Note the almost prone position of the middle penguin at this point in the animation.) The other two penguins in the group are far enough off to the side to be out of danger of being run over by the zamboni.
Figure 25. Penguin diving for cover in the program named turn03.
|
|
Note that the apparent orientation of the scene in Figure 25 is different from that in Figure 24. This is because the camera is mounted on a news helicopter, which is capturing the images from different viewpoints as the execution of the animation progresses.
In Figure 24, the two penguins were to the right of the line of three penguins in the camera's viewfinder. In Figure 25, the viewpoint of the camera has swung around to approximately on the other side of the scene. The two penguins are now to the left of the line of three penguins in the camera's viewfinder. Also, the zamboni was facing to the left in Figure 24 and it is facing to the right in Figure 25.
Penguin emerges from the ice
Figure 26 shows the penguin emerging unscathed from the ice after the zamboni has passed safely overhead. Once again, note the different viewpoint of the camera relative to the previous two figures. The penguin on one end of the line of three penguins is hidden behind the zamboni, and one of the penguins in the group of two penguins is almost completely out of range of the viewfinder on the left side.Figure 26. Penguin emerges from the ice in turn03.
|
And they all lived happily ever after
Figure 27 shows the three penguins back in their line, having turned to watch the runaway zamboni move away from them. The camera viewpoint in Figure 27 is very close to the camera viewpoint in Figure 24. Note, however, that the camera has made two complete revolutions around the zamboni by this point in the animation. Also note that the zamboni is once again facing to the left, and has moved almost to the left edge of the camera's viewfinder.
Figure 27. And they all lived happily ever after.
|
Source code for the program named turn03
The source code for the program named turn03 is shown in Listing 7. To write this program using the source code in Listing 7, you will need to create a new world containing a zamboni and five penguins with a snow template. You can also download the program.
Skip down to the animation section
There are several calls to the turn method in the early portions of the program that initialize the viewpoints of all the objects. You are already familiar with the use of the turn method for viewpoint initialization, so I will skip all the way down to the section of code identified by the comment "Perform animation." The first significant new use of the turn method occurs immediately thereafter.
Make the camera pointAt the zamboni
Note that the block of code immediately before the "Perform animation" comment calls the method named pointAt on the camera to cause the blue axis of the camera to point directly at the zamboni. (I explain the pointAt method in a different section of this document.) Therefore, when the animation code begins executing, the zamboni is in the center of the camera's viewfinder, as shown in Figure 24.
|
The structure of the animation code is a little complex in Listing 7. In particular, all of the animation code is contained in a doTogether block, which begins with an instruction to the camera to turn right, two revolutions in ten seconds, asSeenBy the zamboni. Therefore, rather than to rotate around its own green axis, the camera will rotate around the green axis belonging to the zamboni.
An analogy
Consider attaching your new battery-operated digital video camera to the end of a long pole, with the lens of the camera (the blue axis) pointing along the length of the pole. If you extend that pole directly in front of you, stand in one spot, and spin around, the camera will continue taking a video of you even though you are spinning. The items in the background will appear to be zooming by as the video progresses.
In this case, the rotational motion of the camera is matched to your rotational speed. As a practical matter, it will look like you are standing still and everything behind you is moving. That will be true even if you are standing on a moving sidewalk while you are spinning. You will continue to appear in the center of the viewfinder of the camera and will not appear to be spinning.
What if you don't spin with the camera?
Assume that you can come up with some sort of a mechanism that will cause the camera to circle around you on the same path without a requirement for you to spin. In that case, the video will make it appear that you are spinning and the items in the background will be moving also. Again, that will be true even if you are standing on a moving sidewalk and you cause the video camera to circle around you at the same rotational velocity, maintaining the same distance from you as you move. You will continue to appear in the center of the camera's viewfinder and you will appear to be spinning.
Similar to this animation
That is the case in this animation. The camera is circling the zamboni while the zamboni is moving forward. The zamboni is not spinning. However, the zamboni remains in the center of the viewfinder during the execution of the doTogether block in Listing 7 and appears to be spinning as you watch the animation.
The penguins and the horizon also appear to be spinning, but because the zamboni is moving while they are standing still, their orbits around the zamboni are not circular. For example, because the camera is tracking the forward motion of the zamboni, the two penguins that were originally standing beside the zamboni appear to be closer to the camera as they come into the foreground during each revolution.
Some actions must be performed in sequence
Continuing with the discussion of the animation code in Listing 7, even though the circular camera motion needs to occur concurrently with everything else in the animation, there are other actions that need to happen sequentially. For example, the penguin shouldn't be emerging from the ice at the same time that he is diving into the ice. Therefore, the doTogether block is subdivided into several sequential code blocks each of which is inside a doInOrder block.
Move the zamboni forward
The first block of sequentially executed code simply causes the zamboni to move forward by five meters over an interval of 2.5 seconds beginning gently and ending abruptly. The purpose of this statement is to move the zamboni closer to the three penguins that are standing in a line. The penguins don't do anything during this interval.
Make zamboni run over penguin
This is followed by a block of code identified by the comment that reads "Make zamboni run over penguin." This block contains three statements that are executed concurrently. The first statement causes the zamboni to move forward by 7.5 meters in 3.75 seconds, beginning and ending abruptly.
The second statement, which is executed concurrently with the first, causes the penguin to turn FORWARD by 0.25 revolutions, effectively causing him to lay face down on the ice. (See the position of the middle penguin in the group of three penguins in front of the zamboni in Figure 25.)
Rotate around the right foot
Note that this turn action causes the penguin to rotate around the red axis belonging to his right foot, (by virtue of the value of the parameter named asSeenBy) instead of rotating around the center point of the entire penguin.
|
Sometimes this can make a big difference, but in this case, it doesn't matter very much. This is because the red axis of the right foot is parallel to and very close to the red axis belonging to the entire penguin. (The center point of the penguin is between his feet at the level of the soles of his feet.) However, I wanted to illustrate that a turn action can not only be made relative to an axis belonging to a completely different object, it can also be made relative to one of the component objects that make up the object on which the method is called (a foot, a hand, or a head for instance).
Sink into the ice
The third statement in this doTogether block in Listing 7 causes the penguin to sink into the ice by 0.3 meters, effectively protecting his backside from the mechanism on the bottom of the zamboni that resurfaces the ice.
Penguin recovers, zamboni keeps going
The next block of code that is executed in sequence is identified by the comment that reads "Penguin recovers, zamboni keeps going."
|
This block of code also contains three statements that are executed concurrently. The first two statements essentially reverse the process described above. These statements cause the penguin to rise back up out of the ice and to stand up by calling the turn method with a value of BACKWARD for the first required parameter. Again, the turn is made relative to (asSeenBy) the penguin's right foot.
Keep that zamboni moving
The third statement in this doTogether block causes the zamboni to move forward by another 5 meters. At this point, the runaway zamboni runs out of fuel and stops.
All penguins turn to face the zamboni
As the zamboni reaches the end of its trip, the three penguins in the line all turn to face the back of the zamboni. (I explain the turnToFace method elsewhere in this document.) It is important to note that the camera is still circling the zamboni when this happens, and the zamboni is still in the center of the camera's viewfinder.
Pan the camera to the middle penguin
When the camera completes the two revolutions around the zamboni, one additional statement identified by the comment that reads "Make camera pan to penguinA" causes the camera to point to the middle penguin in the group of three penguins. This moves them to the center of the camera's viewfinder and causes the now-parked zamboni to move toward the left side of the viewfinder.
And they all lived happily ever after
The penguin was saved from destruction by a runaway zamboni, and they all lived happily ever after.
The next stop on the recommended study trail
The program discussed above calls both the pointAt method and the turnToFace method, which are explained elsewhere in this document. These two methods have similar behavior, but there are significant differences. I recommend that you study the method named turnToFace next.
Recommended study trail: Return to the discussion of the method named move.
Brief description: A method to cause an object to rotate around its blue axis, or around the blue axis of some other object as specified by the asSeenBy parameter.
Closely related methods
The roll method and the turn method are very closely related, but the roll method is the simpler of the two, so I will begin with it. One of the best ways that I have found to explain the roll method is to use an airplane as an example.
Three important aspects of the roll method
I will illustrate three important aspects of the roll method in this explanation:
The program named roll01
Go ahead and get started writing (or download) the program named roll01. I will explain things as we go along.
Create a new world. Select the snow template. Save the world as roll01. Get a ToyPlane object from the Objects section of the Web Gallery. Add it to the world and rename it airplane.
Position is not critical
You can place the airplane anywhere in the world that you choose, because we will set its initial viewpoint with program code. However, you should try to place it in such a way that you can see the red, green, and blue axes for the airplane when the program is not running. Figure 8 shows an example of my raw world before the program starts running.
Figure 8. Raw world for the program named roll01.
 |
The red, green, and blue axes are visible
If you look carefully at Figure 8, you can see the blue axis protruding from the front of the airplane. You can also see the red axis protruding from the right wing, and the green axis sticking straight up from the cockpit. Remember, blue for front, red for right, and green for top.
The behavior of the roll method
In a word, the default behavior of the roll method causes the object to rotate around its own blue axis. Another option is to cause the object to rotate around the blue axis belonging to another object.
When the blue axes of the two objects are not parallel, the first object still rotates around the second object, but in a very complex way. I can't explain the rules that govern that rotation. However, the three programs that we will develop in this explanation of the roll method will illustrate all three possibilities.
Required method parameters
The roll method requires two parameters:
The direction of rotation
To help you understand the meaning of the direction of rotation, if the airplane object rolls to the right around its own blue axis, the right wing will tilt downward and the left wing will tilt upward. (The simplicity of that explanation is why I like to use an airplane to illustrate the roll method, and some other methods as well.)
Default parameters
In addition to the required parameters, the roll method also has several default parameters including duration and style. Both of those default parameters will be used in this program.
Description of the program
When this program starts running, the airplane is quite a distance away from the camera, facing the camera when it first becomes visible.
The airplane flies in the direction of the camera rolling to the right around its own blue axis along the way.
Because the altitude of the airplane is slightly higher than the altitude of the camera, the airplane does not collide with the camera. Rather, the airplane would fly over the camera if I allowed the program to run that long. However, I caused the animation to stop just before the airplane completely passed over the camera so that I could get a screen shot of the airplane's tail section as it passed over the camera.
Some "stills"
About 100 years ago, I worked as an usher at a movie theatre. Whenever the movie that was showing was replaced by another movie, it was my job to change the letters on the marquee. It was also my job to replace the "still shots" of the movie in the glass cases at the front of the movie theatre so patrons could get a look at some of the scenes in the movie before purchasing a ticket. We called those photographs "stills."
Three "stills" from the animation
Figures 9 through 11 show screen shots taken at three different points during the running of the program. These three screen shots illustrate how the airplane is rolling around its blue axis and getting closer to the camera at the same time.
Figure 9. The roll01 program shortly after startup.
 |
Figure 10. The roll01 program about midway through the run.
 |
Figure 11. The roll01 program at the end of the run.
 |
Source code for roll01
Listing 2 shows the source code for the program named roll01. All of the code is in the main method.
Quite a lot of familiar code
If you followed the discussion of the code in the program named move01, in the description of the move method, much of the code in this program will be very familiar to you. Therefore, I will either skip over that code, or mention it only briefly.
|
Make the objects invisible while setting their initial viewpoints
Unlike the earlier code in the program named move01, this program makes all of the objects invisible before moving them around for the purpose of setting their initial viewpoints. This is accomplished by setting their isShowing property value to false using program code. The objects are all made visible later once the initialization of the viewpoints is complete and it is time for the animation to begin.
Initial viewpoint for the camera
In this program, the camera is allowed to remain at the center point of the world. It is rotated by 180 degrees so that it will be facing north. It is raised above the ground by two meters without changing its orientation.
Initial viewpoint for the airplane
The initial viewpoint for the airplane is 15 meters due north of the center of the world, facing south (facing the camera). The initial altitude of the airplane is 2.3 meters, which is slightly higher than the camera.
The airplane flies due south
When the animation is run, the airplane moves forward by 14 meters and stops slightly above and slightly to the north of the camera. Ten seconds are required for the airplane to complete the trip, which begins and ends abruptly.
|
During the first 9.8 seconds of the trip, the airplane rolls to the right, around its own blue axis, completing two revolutions during that period. The roll begins and ends gently, with the airplane leveling out at the end of 9.8 seconds. Motion stops at the end of 10 seconds with the airplane's tail section still being in view of the camera. (See Figure 11.)
Write (or download) the program and play the worldI highly recommend that you either write or download this program and play the world. This should give you a good feel for the default behavior of the roll method.
The program named roll02
This program illustrates the behavior of the roll method when the object rotates around the blue axis belonging to another object and the two blue axes are parallel. In this program, a small blimp is positioned directly beneath the initial position of the airplane, with both objects facing due south. Therefore, the blue axes of the two objects are parallel.
The airplane and the blimp
Figure 12 shows the airplane and the blimp before they are moved into their initial viewpoints by the program code.
Figure 12. The airplane and the blimp.
 |
You saw the red, green, and blue axes for the airplane earlier in Figure 8. You can see the red, green, and blue axes for the blimp in Figure 12.
Airplane, please make your move!
Once the initial viewpoints of the two objects are established and the animation begins, a message is sent to the airplane asking it to move forward 14 meters in 10 seconds, beginning and ending abruptly. The airplane is also asked to concurrently roll around the blue axis belonging to the blimp (asSeenBy the blimp), completing two revolutions in eight seconds, beginning and ending the roll gently.
Then fly straight and level
Because the rolls are completed in less time than the time required to complete the 14-meter trip, the airplane ends up flying straight and level at an altitude that is slightly higher than the camera.
Let's see the stills
Figures 13, 14 ,and 15 show screen shots at three points during the running of the program.
Figure 13. Program roll02 shortly after startup.
|
Figure 14. Program roll02 about midway through the run.
|
Figure 15. Program roll02 near the end of the run.