Pfhortran version 0.3 introduced camera control to the language. Version 0.4 introduced paths that can be used for creating camera animation. Though creating and using cameras and paths is not difficult, the approach differs slightly from the rest of Pfhortran and therefore requires a little bit of explanation.
To use cameras in a script, you must first tell Pfhortran how many you will need. The Init_Cameras instruction does this, and it must be called (preferably in the init procedure) before any other camera instructions are used. Each camera must then be set up by first selecting the camera and then setting it's positional values. A camera may be selected using the Select_Camera instruction. To set the position of a selected camera, three instructions are necessary: Set_Camera_Poly , Set_Camera_Pos , and Set_Camera_YP .
Set_Camera_Poly sets the polygon the camera is to reside in. This is just the polygon number as available in Forge or in the Aleph One positional information (displayed by hitting F10 during the game).
Set_Camera_Pos sets the x, y, and z location of the camera. The easiest way to get this info is to use Aleph One's positional information display.
Set_Camera_YP sets the yaw at pitch of the camera. The yaw is how many units the camera is rotated to the left or right, and the pitch is how angled the camera is up or down. Again, look to the positional information display to get these values.
Once the values have all been set, you can activate the selected camera using the Activate_Camera command. To activate a camera that is set up but not currently selected, use the Use_Camera command. The default camera is 0 (the player's perspective) and it can be referenced using either the number 0 or "default_camera".
Here is what an example cut-scene script might look like:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
|
_procedure init
Init_Cameras 1
Select_Camera 1
Set_Camera_Poly 8
Set_Camera_Pos 0.506, -2.8, 1.6
Set_Camera_YP -148.359, -21.094
end
_procedure idle
Use_Camera 1
wait_ticks 300
Use_Camera default_camera
script_end
end
|
Once you have mastered static cameras, animating cameras by placing them on paths is very easy. A path is a string of points in space, and each point contains the same information as a camera: x y z position, resident polygon, and yaw/pitch values. Paths are built by initializing several points and then connecting a camera to the path. The camera will follow one point to the next, making it possible to create complex fly-bys and other camera animations.
Let's construct a simple two point path.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
_procedure init
Init_Cameras 1
Init_Paths 1
New_Path 1, 2
Select_Path 1
Set_Path_Move_Speed 100
Set_Path_Roll_Speed 75
Select_Point 0
Set_Point_Pos -5.893, -17.170, 2.6
Set_Point_Poly 5
Set_Point_YP 121.641, 0
Select_Point 1
Set_Point_Pos -16.323, -16.020, 2.6
Set_Point_Poly 1
Set_Point_YP 42.188, 0
Select_Camera 1
Start_Camera_On_Path 1
end
|
First of all, notice that this script takes place entirely in the init procedure. This script executes an intro fly-by using two path points. Let's look at this code line for line.
Line 3 is familiar... we are simply initializing our custom cameras. In this case, we only need one custom camera, the one that will follow our path. Line 4 initializes the number of paths we will use in this script... 1. Line 6, the New_Path instruction, initializes how many points we will have in a given path. In this case, we are initializing path 1 to have two points.
Now that the path is initialized, we can select it (line 8). Once it is selected, we can modify variables specific to this path and select individual points within the path. Lines 10 and 11 set the movement and roll speed for this path (roll speed controls how quickly the yaw and pitch values change). Note that these speed values are actually how many frames Pfhortran should take to complete the animation. In this case we have asked Pfhortran to break the movement and rolling between two points into 100 frames and 75 frames respectivly. Note that less frames means faster movement, so smaller numbers here would produce quicker animation.
On line 13 we select the first point, point 0. From this point on we do exactly the same things we would with a static camera: initialize the polygon, position, and yaw/pitch values for the point. Line 19 selects the second point in the path and lines 21 through 23 set it's respective values.
Finally, our path is complete. All we need to do now is link a camera to it. To do this, we need to first select the camera we plan to link, and then tell it which path to link to. Lines 25 and 26 do this, and since this is all in the init procedure, animation will start immediately with the first frame of the game.
Also note that custom cameras can be used in conjunction with the "Hide_Interface" and "Show_Interface" commands. These commands hide the player's HUD by making the game full screen. They will also zoom in a bit, so you may have to experiment with it before you get the effect you are looking for.
Note: Occasionally, round-off errors will cause the camera view to be slightly different from what you expected. I will try to change this in the near future, but for the mean time may just have to try slightly different angles until you get what you want.
Second Note: Care must be taken when choosing a roll speed for a path. As stated above, rolling speed measures how many frames it will take to move the yaw and pitch from the first point to the second point. Unfortunately, Marathon uses short integers to save the yaw/pitch data, which means that it can't deal with numbers less than one unit (no fractions). This means that when you choose a roll speed, you must consider how far apart the yaw and pitch between the two points really are, and make sure that the difference, divided by your chosen speed, is greater than or equal to 1. For example, take a look at the yaw values for points 0 and 1 in the example above, 121.641 and 42.188. The difference between those two values is 121.641 - 42.188 = 79.453. That value divided by our movement speed, 75, is equal to 1.059, which is greater than 1. This means all is well and our animation will execute correctly. If our movement speed had been greater than 75, say for example 150, Pfhortran would conclude that it should move .529 units per frame, which would probably be rounded by Marathon to zero, resulting in no yaw movement whatsoever. Marathon will round decimals to the nearest whole number, so you have a little margin of error: if we put 100 for our roll speed, the resulting movement value (.794) would be rounded up to 1 and would animate correctly. I understand that this is a horribly annoying problem that limits the power of animated cameras, but I have yet to find a work-around that still looks good (and believe me, I spent the better part of three weeks trying).
|