• Advertisement
Sign in to follow this  

A question about where to store the Camera!

This topic is 1391 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

Hi, I'm building my own little renderer and there's a couple things that I get undecided about.

 

Where exactly do most of you store things like the Camera and Projection matrix?

I've seen and tried several different ways of doing so, but I'm not satisfied by any of them.

  • Save it in the renderer, pass them as parameters to the render functions - Probably the best way, but I don't want Parameters!
  • Make a singleton for the camera ( HORRIBLE! ) to access it anytime.
  • Make a static variable in the render objects that holds a reference to the camera and projection matrix.

 

I'm just a little curious at how others would do this minor little thing.

Share this post


Link to post
Share on other sites
Advertisement

I don't really have a problem with it.  I've just been turning into a clean freak lately when it comes to code and when I see methods with more than 1 or 2 parameters I'm like ARRRGGHH! But like I mentioned, I know it's probably the best way to go about it overall lol.

Share this post


Link to post
Share on other sites

I am storing the parameters in "camera"-classes which are modifying the view directly when they get called at the beginning of every drawing.

 

This allows easily to change the "active camera" when needed as well as supporting multiple-monitors, split screen, mirros and camera screens.

 

This is what object orientated programming is for that is why those languages were developed.

Those static parameters or the use of singleton is so often misused for OO-languages and this case is not an exception. Singleton is really the badest idea of all of them; static just destroys your OO-environment.

 

When you start thinking about how many ticks you can spare by using fewer methods calls and objects, you have already lost.

If this should be really a matter then you are using the wrong language for your task.

Edited by IceCave

Share this post


Link to post
Share on other sites

Depends on the game.

 

For some games, the camera is just another scripted game object. It has a component of Camera type, which specifies all the parameters. You can have many of them. Typically one is active at a time, but with split-screen or PIP you can have more than one active at a time.

Share this post


Link to post
Share on other sites

Depends on the game.

 

For some games, the camera is just another scripted game object. It has a component of Camera type, which specifies all the parameters. You can have many of them. Typically one is active at a time, but with split-screen or PIP you can have more than one active at a time.

 

See now this is something that I would be satisfied with!  I think this will be how I manage the camera/camera's.

 

I am storing the parameters in "camera"-classes which are modifying the view directly when they get called at the beginning of every drawing.

 

This allows easily to change the "active camera" when needed as well as supporting multiple-monitors, split screen, mirros and camera screens.

 

This is what object orientated programming is for that is why those languages were developed.

Those static parameters or the use of singleton is so often misused for OO-languages and this case is not an exception. Singleton is really the badest idea of all of them; static just destroys your OO-environment.

 

When you start thinking about how many ticks you can spare by using fewer methods calls and objects, you have already lost.

If this should be really a matter then you are using the wrong language for your task.

I agree with you, but this isn't about performance or OOP, well I guess it is about OOP... but It's all about writing clean flexible code. frobs described the EXACT thing that I've been looking for.

Share this post


Link to post
Share on other sites

I usually have Camera objects that are Nodes in my scene tree. Other nodes are Geometry, Lights, etc. By having the camera in the scene tree, they are in the scene hierarchy and their position can be relative to any object in the scene. Or I can animate the Camera, or whatever.

 

Then, in my renderer, I have an attribute that is the active camera, the one actually being shown in the screen right now. Whenever I want I can just pass the camera using a "setActiveCamera()" function to the renderer, and that's the one used.

 

Concerning the projection matrix, I store it in the Camera. Concerning the view matrix, it is just the transformation of the Node class...

Edited by Javier Meseguer de Paz

Share this post


Link to post
Share on other sites

From rendering perspective, there need be no camera, just a view matrix. Pass view and projection matrices into methods that do rendering (packed together if you like) then camera need only exist at the point where the view matrix is calculated (matrices are just local variables now).

 

For example, I tend to divide games into Modes (GameMode, MenuMode etc) and have an Application class that calls abstract methods on a BaseMode interface. Camera can now exist as member of the GameMode object and is used inside GameMode::render(GraphcisDevice&) to create the view matrix. Scene objects are then passed it via SceneObject::render(GraphicsDevice &graphics, const Matrix &view, const Matrix &proj) etc.

 

Camera can then be separately passed to Entity interfaces to update the camera to centre on the player or move it with the player's motion etc but this is entirely removed from rendering subsystem then.

Edited by Aardvajk

Share this post


Link to post
Share on other sites

The camera is a scene object like any other object in your game.  It exists as part of the scene graph and can attach to other objects as a child or have objects become a child of it.

You will typically have a “scene manager” which manages all the objects in your scene, and as such the camera would be registered with the scene manager.  Any number of cameras can be registered with the scene manager so you can do split screens, cuts, etc.

 

Cameras have projection and view matrices as members of their class.  These need to be passed to the rendering system once per scene render.

 

 

L. Spiro

Share this post


Link to post
Share on other sites

I am not a fan of cameras being a component or an entity.  I do make them using a class and have helper functions for culling etc but they live in thier own hierarchy outside of my object system.  I have found it's better for things to have a reference to a camera instead if they really must.  Now where the camera is created and stored will be specific to your game.  Create in your script perhaps and make it the currently active camera in the world is the simplest and may be enough for your game.  It's hard to say without seeing everthing and know the scope f the game.

 

The most important part of this question IMHO is the rendering part and I would say without a doubt it should be passed to the rendering functions.  I have a RenderJob I pass around and it's main purpose is for multi-threading but it does also hold a reference to the camera, lights, rendertarget etc.  This is more flexible for rendering objects.  I use the same render call with a different job to render an entity to a texture and use it in my ui as I do for rendering in the actual world.

Share this post


Link to post
Share on other sites

I like the idea of using the camera like a scene object, I never would have thought to use it like that. It makes everything go together smoothly and there isn't code in random places for the camera. To me a hierarchy beats having references all over the place any day. I guess it's all about preferences.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement