Jump to content

  • Log In with Google      Sign In   
  • Create Account

A question about where to store the Camera!


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
11 replies to this topic

#1 Muzzy A   Members   -  Reputation: 640

Like
0Likes
Like

Posted 29 March 2014 - 01:09 PM

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.



Sponsor:

#2 ApochPiQ   Moderators   -  Reputation: 15732

Like
4Likes
Like

Posted 29 March 2014 - 01:14 PM

What's wrong with passing parameters? That's what they're for.



#3 Muzzy A   Members   -  Reputation: 640

Like
0Likes
Like

Posted 29 March 2014 - 01:50 PM

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.



#4 Promit   Moderators   -  Reputation: 7190

Like
6Likes
Like

Posted 29 March 2014 - 01:51 PM

More parameters usually means less hidden state and less surprises. Embrace it (within reason).



#5 IceCave   Members   -  Reputation: 159

Like
2Likes
Like

Posted 29 March 2014 - 01:52 PM

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, 29 March 2014 - 01:54 PM.


#6 frob   Moderators   -  Reputation: 21318

Like
3Likes
Like

Posted 29 March 2014 - 02:45 PM

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.


Check out my personal indie blog at bryanwagstaff.com.

#7 Muzzy A   Members   -  Reputation: 640

Like
0Likes
Like

Posted 29 March 2014 - 03:03 PM

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.



#8 Javier Meseguer de Paz   Members   -  Reputation: 371

Like
0Likes
Like

Posted 29 March 2014 - 06:49 PM

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, 29 March 2014 - 06:52 PM.

“We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil” -  Donald E. Knuth, Structured Programming with go to Statements

 

"First you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer" - Ken Beck, Twitter


#9 Aardvajk   Crossbones+   -  Reputation: 5982

Like
1Likes
Like

Posted 30 March 2014 - 07:09 PM

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, 30 March 2014 - 07:13 PM.


#10 L. Spiro   Crossbones+   -  Reputation: 13599

Like
2Likes
Like

Posted 30 March 2014 - 07:47 PM

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


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#11 LoneDwarf   Members   -  Reputation: 263

Like
0Likes
Like

Posted 31 March 2014 - 09:29 AM

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.



#12 Muzzy A   Members   -  Reputation: 640

Like
0Likes
Like

Posted 31 March 2014 - 11:56 AM

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.






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.



PARTNERS