   ownership of cameras
  Hi,I have a question concerning the ownership of a camera class.I've got my character running around the level, and need to know what should have access to the camera.Previously, I had one camera as a singleton. The renderer then read this camera and used it to calculate a view matrix. The renderer was also a singleton. so was everything else....However, I'm now recovering from the effects of singletonitis, and want to put my camera control somewhere else.Assuming each human player needs a separate camera, should I:1) Allow my character manager class to pass the camera of the player being watched to the renderer2) Allow the renderer access to each human player and let it choose which camera control to use when calculating a matrix.3) embed with camera control within the renderer itself. Let the renderer calculate a matrix depending on the direction a character is facing.4) Have a vector of camera each linking to a human player, and accessible globally.Thanks for any opinions on this.   
  There's still a "the" Renderer?Assuming you don't want to change that, try having it ask players for their camera. Or, have the player make the request to the renderer "draw what I can see", passing its camera as an argument.   ;Quote:Original post by ZahlmanThere's still a "the" Renderer?Assuming you don't want to change that, try having it ask players for their camera. Or, have the player make the request to the renderer "draw what I can see", passing its camera as an argument.There isn't, as you put it, a "the" renderer, but rather I only create one. Because in SDL you are only able to have one opengl display surface, technically its limited to one, but I could have other renderers running at the same time. I have tested it with multiple surfaces running, but I got an error code when I ried to start up the second one.When the opengl 3.0 comes out I'll be running two renderers, so that I can test my code for the new version against the results of the old one.I think I'll take your first suggestion, getting the renderer to ask players for their camera. Is that what you do?;  In my engine everything that moves has a function GetTransform(), my scene contains camera's that have the ability to track any transform in either a follow mode or a fixed mode.So it's basically like//fps cameraengine->FindCamera("MainCamera")->TrackTransform(player1->GetHeadTransform(), Camera.Fixed);//3rd personengine->FindCamera("MainCamera")->TrackTransform(player1->GetHeadTransform(), Camera.Track);//cinematic, returns pointer to new cameraengine->ActivateCamera("corner1")->TrackTransform(player1->GetHeadTransform(), Camera.Follow);When the engine renders the scene it feeds the renderer->RenderScene() a PassDetails structure with the current scene camera (along with other details about the detail of the render). This PassDetails structure gets bounced and modified through recursive calls to the ____Pass() functions for instance reflection, depth, and post processing passes.   ;  I think #3 is the best choice, but keep in mind that while the camera itself is part of the renderer, control of the camera is not. The player character and the camera should be independent of each other for a few reasons:The camera could conceivably point at something other than the player.There may be several cameras.A camera may have several different kinds of behavior or controls.In this case, the camera would know about the player (so it can follow it around), but the player would not know about the camera. The one drawback is that generally you want control of the player to be camera-relative and that could create a circular dependency.   ;Quote:Original post by JohnBoltonThe one drawback is that generally you want control of the player to be camera-relative and that could create a circular dependency.So perhaps separate out the control of the player:Player - Has a position/orientationCamera - Basically a matrix with some sort of behaviour (follow the player)Renderer - Maintains a list CamerasPlayerController - References a player and a camera (if it needs view-relative movement) and will update the player's matrix;  Control and ownership of the camera should be part of the UI system, IMO.   ;  I thought of another system, which I like, that is similar to #3. It uses the following classes:playercharactercharacter managerrendererviewportcameraThe renderer owns several "viewports" each of which owns a camera control. The character manager then uses exposure methods to access these viewports, and then updates the camera accordingly. It associates each viewport with one player slot only.Viewports themselves will be unaware of any graphics library. Thus, so will anything which uses a viewport. If I later decide to learn a new graphics library, only the core of the renderer need be recreated, and the viewports do not need to be modified. Its important to note that I already abstracted characters and players; characters are just robots, responding to commands from a player. Players either use AI or KB/mouse input to pass commands to their character.When the server starts up there are, for example, 2 players and space for 8. It also has a vector of characters.Each player is linked to a character which they control, and the game commences.  The character manager is then free to use any algorithm I choose to track players with cameras. If a player dies, the character manager can do something else with his or her camera until a new character is spawned for that player.(n.b. I'm looking for a new metaphor for players and characters. I'm not sure that it makes sense as it currently stands);Quote:Original post by shotgunnutterEach player is linked to a character which they control, and the game commences.  The character manager is then free to use any algorithm I choose to track players with cameras. If a player dies, the character manager can do something else with his or her camera until a new character is spawned for that player.What if later on you want to do a sceneric shot? Track an object? Do a trombone shot on a corridor? Allow replays? Camera work doesnt belong with character management. The View is an UI concept.