Panning
Camera Forward and Backward
Now that you know about spinning and changing
camera view, wouldn't it be nice to move forward
and backward based on this view? Doesn't seem
too hard right? After all, we did both movement
and panning individually; how hard could it be
to put them together? Not toooo much, but it's
enough. There's that added complication of direction
of movement. Before, with camera movement, we
were always facing the same direction. Now, however,
the camera is facing other directions so no longer
would forward movement be associated with just
the z value. It will include z and x. How much
depends on the rotation of the camera, and getting
how much involves...you guessed it, more trig.
If you think back to the triangle and rotating an object based
on sine and cosine, what you are basically doing is moving an object from the
origin and placing it cosine of angle times radius spaces along the x and sine
of angle times radius spaces along the y, ultimately moving it all in that
instance in a diagonal.
What if you repeat that process without rotating the line any
further and just kept moving the shape by that x movement and that y movement?
What you would get is motion in the direction of that angle! As the angle
changes, so would the movement, but based on that shape's current position as
long as those values kept getting added on to its current.
Compounding the new movement onto the present location sets it
off to move based on the rotation or direction or positioning:
[ movement based on rotation ]
Now, just picture instead of that shape, you have an overhead
view of the camera in its 3D environment. Since the angle represents the
direction its facing, moving in that angle would mean moving camera forward in
the direction of the view. Reverse that direction and you're going backwards.
Easy, right?
The only thing is, since you've completely moved all the
objects in the scene in respect to the camera, new radius values would have to
be determined for each of those movieclips. With the trig functions learned
earlier, this won't be a problem.
Example 8: Moving the Camera With
Panning We'll go back to our figures from before and put a few in some simple
stationary positions within the 3D space. Then, using what was described above,
allow the user to move through the space using the arrow keys. Left and Right
will turn left and right respectively and Up and Down will move forward and
back.
[ moving and panning the camera
]
Steps to Create Animation
As always, create
your screen elements. Here, you got your ground and figures.
Next your basic
definitions of theScene movieclip, objectsInScene array and camera object
(along with focalLength). The camera now has x, y, z and rotation properties.
Here is the
dirty work in the display function. This function will 1) offset camera
position, 2) develop a new radius based on the new position using arc tangent
and the Pythagorean theorem, 3) develop a new position based on that radius
based on the angle with the camera rotation offset and finally, 4) make sure
the clip has a positive z before displaying it properly given those new
values. So really, all that's new is the rotation after camera movement
offset. All that entails is using basic trig rotation to properly derive a new
x and z value to reflect the rotation of the camera - basically a combination
of examples 4 and 6.
Then,
attach each figure. There will be 8 figures total lined up in 2 rows
(different x values for each row of 4), making sure to add each to the
objectsInScene array.
Finally the
function to make it all happen. This will base camera movement off of the
arrow keys and use
for the movement of the camera based on its rotation. That way, it will appear
to move forward based on the direction its facing. Loop through the
objectsInScene and you're done.
WARNING! Reminder:
Conflicting Depths
With this last example you are able to see, before
panning, that there are a few figures in the back that overlap
incorrectly. This is due to the previously mentioned issue of
conflicting depths where if one object tries to share the depth of
another, those depths will actually swap. Because the figures are lined
up the way they are with 2 rows of figures each sharing a similar z with
the figure across from them, each of those figures will therefore also
try to share the same depth. In doing this, the figures swapped last end
up swapping depths with the opposing figure currently at the depth it's
trying to occupy. That being the case, some figures will end up being
swapped back to their originally attached depth thereby causing them to
be above other correctly swapped clips.
To prevent this, you can just lay out such clips not to
share the same z to start, or just attach each clip at an appropriate
depth relating to where they might be when displayed on the screen. You
may, however, never have this problem and wouldn't then need to worry
about it in the first place. If it does happen, though, it may need to
be addressed.