Jump to content

  • Log In with Google      Sign In   
  • Create Account

Different approach to "Camera" design?

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 ATC   Members   -  Reputation: 551


Posted 26 October 2012 - 06:26 PM

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




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, 26 October 2012 - 06:31 PM.

CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine

Please visit our new forums and help us test them and break the ice!


#2 Radikalizm   Crossbones+   -  Reputation: 3964


Posted 26 October 2012 - 06:44 PM

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)

I gets all your texture budgets!

#3 Lauris Kaplinski   Members   -  Reputation: 841


Posted 27 October 2012 - 10:28 AM

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.
Lauris Kaplinski

First technology demo of my game Shinya is out: http://lauris.kaplinski.com/shinya
Khayyam 3D - a freeware poser and scene builder application: http://khayyam.kaplinski.com/

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.