## Question of the Week

Scripting 3D in Flash
by senocular

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

1. As always, create your screen elements. Here, you got your ground and figures.

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

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

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

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