Sign in to follow this  

Different approach to "Camera" design?

This topic is 1907 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was just considering what the implications of a different approach to designing a camera base class might be...

[source lang="csharp"]
// Traditional approach ::
class CameraTraditional
{
public Vector3 Up { get; set; }

public Vector3 Target { get; set; }

public Vector3 Position { get; set; }
};

// A different approach ::
class CameraDifferent
{
public Vector3 Position { get; set; }

public Quaternion Orientation { get; set; }
};
[/source]

The pseudo-code example says it all... Normally, we implement a "camera" object with the properties "Up", "Target" and "Position" for creating a view matrix. But what if we toss that notion out and go with something more akin to any other 3D game entity, which has a "Position" and "Orientation" rather than calculating everything in terms of what direction is up and where the target is...?

What problems might this pose in game design? What advantages might it have? I was just curious about this idea so figured I'd ask...

Regards,

--ATC--

EDIT:

Also, what is the easiest way to decompose a projection matrix to retrieve the fov, aspect ratio and near/far clipping planes? Edited by ATC

Share this post


Link to post
Share on other sites
To construct a view matrix you'll always require those three vectors, but you could very well construct them each frame by transforming the local unit axes for the camera by the orientation quaternion. There's no real gain in the method you proposed except for the fact that you use a little less memory in only storing a 3-vector and a quaternion instead of 3 3-vectors.

If I remember correctly a left-handed perspective projection matrix is laid out like this (don't shoot me if I get something wrong here):

X 0 0 0
0 Y 0 0
0 0 Z 1
0 0 W 0

Y = 1.0 / (tan(field_of_view*0.5))
X = Y / aspect_ratio
Z = far_value/(far_value - near_value)
W = -(near_value * far_value)/(far_value - near_value)

Extracting the field of view and aspect ratio is quite trivial, extracting near and far values might require some trickery (almost 3AM here, not in a mood to solve this now)

Share this post


Link to post
Share on other sites
I am usually constructing my cameras the second way - although instead of position + quaternion I use full matrix.

The motivation behind it is that now camera is completely "normal" 3D object (scenenode or whatever) and you can use all your standard object transformation and query methods on it. It has bounding box too - it is just the bbox of projection frustum.
Specific camera controllers are built on top of this basic camera and are modifying directly the camera matrix.

Of course in that case you will want to write handful of convenience methods to rotate your camera around target, query position and orientation etc.

Share this post


Link to post
Share on other sites

This topic is 1907 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this