Planning the Spontaneous

It's more than just a blueprint.

Renderer: Camera

Posted by Robert Chow on 14/12/2009

Just slighty tricky.

Starting with the camera, there is always one, no less, no more.  Or so there should be.  So the way I’ve managed this is to let the Renderer component deal with it.

You have the scene graph, made of multiple nodes.  Attached to one of these nodes is the camera – the great flexibility of having a model like this is that the camera can be easily attached to anything.  Ask the Renderer to attach the camera to a node, and it will automatically attach the camera abstraction inside Renderer to that specific node.  This way, you do not have to worry about multiple cameras – there is only one, and this is being constantly moved if asked to.

With the camera attached to some node, we will have to traverse up to the rootnode, multiplying the current matrix by transformation per node, and then inverting the result.  The result is then loaded as the base matrix for the model view.  Doing this shifts the entire world model by -camera position, and therefore the scene should appear in the right place according to the camera.

It’s a little like this.

Imagine you can move the world.  Move the world right.  Everything in your view shifts right.

But that’s impossible.  You move left.  Everything in your view still shifts right.

Camera Vs. World Space.  From top to bottom:  the original picture – the darker area shows what the camera is currently seeing in world space;  model shifted right – the camera sees what is expected – the world to have shifted to the right;  camera shifted left – as far as the camera view is aware, this creates the same effect as the image in the middle.  You don’t quite get beaches like that in Manchester.

Going back to the scene graph, there is one major problem. What about, for example’s sake, the camera was attached, but we then removed the node it was attached to from the scene graph? Or it just wasn’t attached in the first place? We can still traverse up the nodes to find camera position – this will be happily done until there are no more nodes to traverse up. The main problem is recognising whether or not the last node traveresed is the root node of the scene graph. We do a simple equality test, but then what?

My supervisor’s been saying something a lot – fail fast.

That means whenever you know there is something wrong, fail the execution as fast as possible. As far as I’m aware, there are two ways of doing this is C#. This is Debug.Assert() and Exception throwing.
Debug.Asserts() are tests used to make sure the program is working – the test should always prove to be true during execution, but you can never be too sure.  Exceptions can be used for when something has been entered incorrectly client-side.

For example.

Client Side

Renderer.SetCamera(null);

Internally

public void SetCamera(Node node)
{
if(node == null)
{
throw new CameraCannotBeNullException();
}
camera = node;
}

So coming back to the original case, when we’re traversing up the nodes from the camera, we check to see if the final node is the root node.  If not, we throw an exception.  That way the client can handle this when it picks it up.  And failing fast also means the client can deal with it as soon as possible.

Advertisements

One Response to “Renderer: Camera”

  1. […] the concept of vertex buffer objects (drawing of the cube), the scene graph (rotating cube), the camera (viewing the cube, using the scene graph) and picking (turning faces on/off). But what about the […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: