Planning the Spontaneous

It's more than just a blueprint.

Posts Tagged ‘Camera’

MultiOpenGlControl Demo

Posted by Robert Chow on 16/04/2010

I’ve managed to grab some video capture software and also produce a small demo of using multiple SimpleOpenGlControls.  Each screen has it’s own camera, focusing on to the same scene.  Using lighting and picking, clicking a face of the cube will change the scene, and thus be reflected in all of the cameras.

I did have a little trouble with the picking at first – when I picked, I forgot to change the current camera, so it would register the mouse click on one screen whilst using the camera of another.  With that fixed, it was nice to be able to play around with Renderer again.

True, the videos not suppose to be a hit, but at least it’s showing what I want it to.

Advertisements

Posted in Computing, Placement | Tagged: , , , , , , , , , | Leave a Comment »

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.

Posted in Computing, Placement | Tagged: , , , , | 1 Comment »