3rd Person Camera
I'm sure this has probably been asked before but could somebody please point me in the direction of a good 3rd person camera tutorial?
I have been trying to develop one myself and just can't seem to get it right. I have searched the net a small bit but can't really find what I am after. I am looking to implement it using C++ and DriectX9.0c.
Thanks
All camera's are basically the same, and serve the same purpose. A good design is to isolate the functionality you're thinking of into two distinct parts -- the camera itself, and a camera controller.
The "camera" is responsible only for maintaining properties related to the construction of the view matrix -- this can be suitably represented by a position and a quaternion. The camera provides the appropriate interface to manipulate the position/orientation quaternion in any unrestricted fashion.
The camera controller maintains a reference to a camera and can be used to supply constraints on the manipulation. The controller is what would provide you the notion of a "third person" or "first person" (et cetera) camera -- it would handle any motion smoothing, restrictions, zooming, orbits, et cetera.
As for the camera itself, the position aspect should be self-explanatory. The quaternion is used to represent an orientation of three local-space basis vectors (for example, (0,0,1);(0,1,0),(1,0,0) are fairly common basis vectors). To rotate or otherwise mutate the camera's orientation, you manipulate the quaternion. When it comes time to build a view matrix, you can extract the world-space basis vectors by multiplying each local-space basis vector constant by the current quaternion. Those vectors are used to build the matrix (or used to produce the parameters for whatever "look at" function you're using).
This is the general system I've used for years now, and it works very well.
The "camera" is responsible only for maintaining properties related to the construction of the view matrix -- this can be suitably represented by a position and a quaternion. The camera provides the appropriate interface to manipulate the position/orientation quaternion in any unrestricted fashion.
The camera controller maintains a reference to a camera and can be used to supply constraints on the manipulation. The controller is what would provide you the notion of a "third person" or "first person" (et cetera) camera -- it would handle any motion smoothing, restrictions, zooming, orbits, et cetera.
As for the camera itself, the position aspect should be self-explanatory. The quaternion is used to represent an orientation of three local-space basis vectors (for example, (0,0,1);(0,1,0),(1,0,0) are fairly common basis vectors). To rotate or otherwise mutate the camera's orientation, you manipulate the quaternion. When it comes time to build a view matrix, you can extract the world-space basis vectors by multiplying each local-space basis vector constant by the current quaternion. Those vectors are used to build the matrix (or used to produce the parameters for whatever "look at" function you're using).
This is the general system I've used for years now, and it works very well.
If you decide to use quaternions, you'll probably find this helpful.
jpetrie - I've seen some people that implement a camera using 3 vectors (like the code here). It looks like it's a much more useful representation because it makes certain operations very easy (pointing the camera towards a target, moving forward or side-ways), and it makes some useful information readily available (like the look-at vector). It's also much faster to convert to a matrix.
Quaternions allow you to do smooth interpolation, but you can always convert the 3 vectors to a quaternion, interpolate and convert back, which might be more efficient because it seems to me that interpolation isn't used much when controlling a camera (more for things like fly-throughs).
But still, I see many people that recommend using quaternions to represent a camera's or an object's orientation. Can you explain a bit why that is?
BTW, sorry if I'm hijacking this thread, but I think this will be useful to the OP as well.
Thanks in advance.
jpetrie - I've seen some people that implement a camera using 3 vectors (like the code here). It looks like it's a much more useful representation because it makes certain operations very easy (pointing the camera towards a target, moving forward or side-ways), and it makes some useful information readily available (like the look-at vector). It's also much faster to convert to a matrix.
Quaternions allow you to do smooth interpolation, but you can always convert the 3 vectors to a quaternion, interpolate and convert back, which might be more efficient because it seems to me that interpolation isn't used much when controlling a camera (more for things like fly-throughs).
But still, I see many people that recommend using quaternions to represent a camera's or an object's orientation. Can you explain a bit why that is?
BTW, sorry if I'm hijacking this thread, but I think this will be useful to the OP as well.
Thanks in advance.
Quote:
jpetrie - I've seen some people that implement a camera using 3 vectors (like the code here). It looks like it's a much more useful representation because it makes certain operations very easy (pointing the camera towards a target, moving forward or side-ways), and it makes some useful information readily available (like the look-at vector). It's also much faster to convert to a matrix.
These are essentially the same representations; recall I said the quaternion represented the orientation of the camera's local space basis vectors in world space, which is what the "three vector" approach is explicitly storing. The quaternion approach is thus more compact (four floats, versus nine).
As far as operational efficiency, that's rarely a huge impact on overall performance these days, but the quaternion's still -- if nothing else -- more efficient to physically write the operations for. Updating the quaternion alone is little cleaner and more sane than having to make sure all rotations update all three basis vectors correctly, which is usually done the same way the quaternion would be directly updated, followed by the typical q * v * inverse(q) method of rotating vectors to update the basis vectors -- a minor bit of extra work and book-keeping.
Overall a quaternion-only form might be slightly more computationally efficient on average because of this, since it defers the extra vector rotations until they are needed, if they are needed at all. It's definitely more space-efficient (although again, the actual amount of bytes saved is trivial in comparison to most other resources). But finally, and perhaps most importantly, it's more likely that you will write code to manipulate orientation in interesting ways more often than you will write the boilerplate code for computing view matrices, et cetera, so here it pays to have a suitable data structure for that sort of work readily available.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement