Why does the "Scene" have a camera

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Why does the "Scene" have a camera

      Evening,

      I've been browsing the source and was wondering why the Scene class contains a camera rather than a View onto the Scene having the camera? At the risk of over-analysing what was quite possibly a simplification just for the book, it feels to me like there is a layer missing.

      From what I've seen (so far - I'm still poking around), there's no way for different Scenes to reference the same scene-graph as the Scene constructor resets its root node. So, it looks like every camera has to have its own Scene (which feels rather inefficient) or the Scene's camera has to be changed for every view that is rendered (which may not work particularly well with multi-threading).

      Have I missed something? Is there a reason why a scene-graph should-not/cannot be shared?
      - Arm
    • I think you might be mixing up Scene (scene graph manager) and SceneNode (a node of the graph). I think youre saying that its inefficient that there is a camera attached to every node. Apologies if i misunderstand you.

      The Scene class has a special camera node, not in its list of children but as a class member. There isn't anything stopping you replacing this with a list of cameras instead of just one and switching between different views onto the 3D scene being rendered.

      As an example of this, In TeapotWars, the code can switch between a movement camera behind the players teapot and a debug camera that can roam freely about the scene (going from reading the book).
    • Morning,

      Sorry, mustn't have been clear enough... I did mean "why is the Camera attached to the Scene?" (as the manager of the scene-graph). Apologies for the slightly rambling post that attempts to explain:

      I've been doing more thinking about this and I think the scene-graph as implemented in the book is actually mixing two requirements: the first is to manage the spatial relationships between objects in such a way that they can be iterated over sensibly and the second is to manage the geometric (not sure what term to use here) relationships - the transform matrices, bounding volumes etc. required to render them.

      I had originally assumed that the Scene (and its tree of SceneNodes) was really there to manage the spatial relationships - and as such is just there as a convenient structure to hold the scene data.

      The scheme I'd imagined (and was alluding to in my original post) is that a "View" would contain the Camera and a Scene (instead of the Camera being held directly by the Scene). Then, several Views with different Cameras could share the Scene structure. I guess that this is essentially the same as having a list of Cameras in the Scene as you describe.

      I can't decide whether or not this is a good idea: by sharing the Scene you save memory overheads but force recalculation of the transformation matrices in the entire tree every time the scene is rendered with a different camera. I guess the recalculation has to happen anyway if the camera moves (and recalculation of parts of the scene-graph tree if objects in the scene move) so this might not be that bad. But, the Scene/SceneNode tree is likely to have a small memory footprint relative to the geometry/texture data. Sharing a Scene would also presumably force every View to have the same effects (barring any post-processing applied by the view) which might be undesirable in general.

      It has also occurred to me that this might not really matter from a performance/effeciency perspective - and it may well simply be a personal preference of software design...
      - Arm
    • IMO the camera exists as a special kind of object in the Scene - as if a real cinematic camera were really there. There's nothing wrong with mapping the camera's results onto a view, in my mind. In a co-op game this would happen - multiple cameras roving around a scene.

      But, as you point out, there are multiple ways to view this problem.
      Mr.Mike
      Author, Programmer, Brewer, Patriot