Switching To Third Person - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Game Programming Fundamentals (/forum-7.html)
+--- Thread: Switching To Third Person (/thread-5737.html)
Switching To Third Person - Nick - Mar 22, 2005 03:18 PM
I'm trying to figure out how to properly make a third person camera out of my current camera. It already has the capabilities (i.e. a function that rotates it around a point) but I can't figure out how to get the "look" right. It's going to be a third person shooter in similar fashion to Grand Theft Auto or Mafia or Driver 3.
I'm not sure if the code is necessary so I'll refrain. Let me know if I should post it. I'm mainly concerned with where the camera should be positioned, how it's position relates to the player, and where it points. Thanks for any help.
Switching To Third Person - JustinFic - Mar 23, 2005 05:26 AM
Threw some keywords into google (it's your friend, abuse it) and came up with this quick writeup.
It's the bare basics (doesn't account for obstructions or anything) but it should get you started. In a nutshell, take the camera you have now, and move it up & back (relative to player position and heading), and aim it at the player.
Switching To Third Person - Nick - Mar 23, 2005 11:51 AM
I've been trying things out and just can't get it even working right. The idea: I want a third person view that switches to first person when the player zooms in with a gun.
If anyone can help, IM or email me and I can send my Camera and Player class files to you. I just need some help making this all happen.
Switching To Third Person - Taxxodium - Mar 23, 2005 12:13 PM
In a previous project, where I used Shockwave 3D exclusively, I had a smilar problem. What I did was create 2 camera objects, and when I had to switch from one to the other I just transposed the movement and made a camera the current one.
I don't know if this is possible in OpenGL. If it isn't, then what you could do is have 2 invisible points that you could use as targets for your camera position.
Ofcourse this is pure theoretical, I'm really the last person to ask for help when it comes to 3D programming
Switching To Third Person - Taxxodium - Mar 23, 2005 12:17 PM
Hmm, rereading your post, the text I wrote above didn't quite answer your question. My apologies.
I would edit it, but I can't find the edit button. Oh well...
Switching To Third Person - hangt5 - Mar 23, 2005 01:25 PM
I would create two camera classes and switch between them. There are about a million camera class tutorials out there so i wont go into the details.
to answer the second part of your question: I read somewhere that the key to doing 'zoom' is to change the FOV, im not exactly sure what the right values are but im sure a little experimentation will answer that quickly.
Switching To Third Person - TomorrowPlusX - Mar 23, 2005 01:30 PM
I agree with Taxxodium here
In my situation I'm writing a 3rd person driving game, where you can switch from a driving view ( 3rd person ) to a gunnery/turret view ( I guess 1st person ). I maintain one camera, but I have different positioning rules, using object-relative transformations.
E.g., for the driving view I have the camera positioned backwards by about 5 meters and up a couple, looking towards a point about 100 meters in front of the car.
When you switch to first person, the camera is positioned to the left of the barrel by one meter, and looks in the same direction as the gun.
When you switch between the views I "tween" between the positioning for one view to the next, to give a smooth "swooping" effect, which is cool.
Switching To Third Person - tigakub - Mar 25, 2005 08:00 AM
Are you using gluLookAt. If not use it. I assume you have some kind of transform hierarchy. To use gluLookAt, you need the global position of your view point, the global position of the point you're looking at, and the up vector, which can be obtained by subtracting the view point from a point 1 unit directly above it. Let's say you have a view hierarchy as follows.
To find the global position of NodeC and NodeD (which correspond to the camera's position and the up point of the camera).
You can use a similar method to get the global position of the camera's target point.
So you can then use gluLookAt:
I typically put this code in my camera class and have three pointers in my camera class, one that points to the position node, one to an up node, and one to the target node. This way I can simply swap pointers to attach the camera to different objects.
Switching To Third Person - Nick - Mar 25, 2005 09:53 AM
Thanks for all the help. My camera is working fine now. I'm going to add some 'effects' to it later but the basics all work. Now I get to figure out how to get the character to rotate based on the mouse movement.
Switching To Third Person - lpetrich - Mar 31, 2005 12:14 AM
The trick I used in Aleph One, http://source.bungie.org was to calculate the position in three steps.
The first step was to find a target position -- a camera position offset from the player character's position. This I will call xt.
The next step was to give the camera some inertia, so it does not seem fixed on a pole. In Aleph One, I did that by doing a crude ordinary-differential-equation solution. The current value, x, I found from its two most recent values, x1 and x2 with:
x = (1 + c1 + c2)*xt - 2*c1*x1 - c2*x2
where c1 and c2 are constants that express the camera's inertia. Be careful about choices of c1 and c2, because the camera's position can become unstable with incorrect values. I'll defer discussion of that to the end of this message, because it is a bit long and technical.
The final step was to ensure that the camera will not go through walls. This was done by using the Marathon engine's projectile-motion code, moving the camera from the player-character position to x, and stopping if the camera hit a wall. This step also ensured that the camera would be in the proper map polygon to get the visibility calculations right.
How the camera behaves can be calculated by plugging in an ansatz or guessed partial solution for the camera's free motion:
x = w^2*x0
x1 = w*x0
x2 = x0
where x0 is an integration constant and the size of w determines the camera's behavior. If its absolute value is less than 1, it is stable, and the closer it gets to 1, the more borderline its stability becomes. An absolute value greater than 1 means instability. We can find w by plugging the x's into the above equation and ignoring xt:
w^2 +2*c1*w + c2 = 0
yielding w = - c1 +/- sqrt(c1^2 - c2)
If c2 < c1^2, then the camera will be overdamped. The stability condition becomes sqrt(c1^2 - c2) < 1 - |c1|, or c2 > 2*|c1| - 1.
But if c2 > c1^2, then the camera will oscillate. since the square root becomes imaginary: w = - c1 +/- i*sqrt(c2 - c1^2). In that case, c2 < 1 for stability.
If the camera is to have relatively noticeable inertia, then you will want it to have values of w close to 1. This means that c1 must be close to -1 and c2 close to 1. It might take some experimentation to find values of c1 and c2 that give nice-looking camera behavior, however.