Quote:I do have another question though, how would multiple cameras be supported in either of your systems? I can see that you would have one camera for the main players view, but you could also have a camera that renders to a texture and displayed within the view of the player. This would mean you would need to form some kind of list of active cameras or something? Same idea applies if you want to have multiple views on the one screen.

Right, you'd need a list of cameras, just as you said. Presumably the cameras would render in a fixed order, so that (e.g.) certain views will render over others if needed, and so that any render targets (e.g. for render-to-texture) will be available for use by subsequent cameras.

Parameters associated with each camera might include:

- Render order (relative to other cameras)
- Buffer-clearing options (e.g. whether or not to clear the color and depth buffers)
- Background clear color for color buffer clearing
- Projection parameters, including type (orthographic or perspective)
- Viewport parameters
- Render target (framebuffer, texture, etc.)

Another thing you have to consider is which objects will be included in the render passes for which cameras. For example, an 'in-game' camera might only render game entities, while the 'UI' camera might only render UI elements. You might also have objects that need to be rendered by multiple cameras. For example, a first-person 'player' camera and a security camera would probably render the same objects, just from different points of view. Or, imagine a little 'info' window that showed the player or some other entity, but nothing else; in that scenario, that entity would need to be associated with two cameras, while all other entities were associated with the main camera only.

One way to accomplish this is to give each camera an ID, and then assign one or more camera IDs to each renderable. Then, each renderable is rendered in the render pass for every camera with which it's associated.

Quote:But just to clarify - in the case of the security camera you might have an entity for example, "CameraStreamEntity" which associates itself with a "RenderToTextureCamera". Now, to determine if the renderer even needs to do any rendering with said camera, it would use a "Main Camera" to determine if the entity is in its frustum?

I think I understand what you're getting it. Basically, you're talking about skipping the rendering for the security camera if the 'screen' on which the security camera view appears isn't visible from any other camera, right?

If so, I don't have an answer per se, not having tackled that particular problem myself. It seems like the problem could become somewhat involved though. Imagine, for example, multiple security cameras, some of which might be able to 'see' the screens associated with other cameras. If any one of those screens were visible to a 'normal' camera (such as the one associated with the player), then you would need to render the camera view for that screen. If *another* screen were visible on the first screen, you'd need to render the view for that screen as well. And so on. I don't have a solution to that problem available off the top of my head, but maybe someone else has done something like what you describe and can offer some specific suggestions.

Quote:What confuses me is the "Main Camera" and what it gets associated with. I would assume it gets associated with the player? It would have to be managed as a special case compared to other cameras?

I would not think of any camera as being a special case, but maybe that's just because I haven't encountered a situation in which it was necessary to do so. Still, I can't think of a reason right off why a 'main' camera would need to be treated differently than any other camera.

First of all, my camera set-up is more or less the same as what jyk describes (I also jumped on the train of entity/component systems ;)).

Quote:Original post by jyk
If so, I don't have an answer per se, not having tackled that particular problem myself. It seems like the problem could become somewhat involved though. Imagine, for example, multiple security cameras, some of which might be able to 'see' the screens associated with other cameras. If any one of those screens were visible to a 'normal' camera (such as the one associated with the player), then you would need to render the camera view for that screen. If *another* screen were visible on the first screen, you'd need to render the view for that screen as well. And so on. I don't have a solution to that problem available off the top of my head, but maybe someone else has done something like what you describe and can offer some specific suggestions.

The solution I'm about to use: The renderables in the scene graph are filtered for those that are visible. They are collected in a queue of rendering jobs. The jobs are later sorted by the main renderer anyway. During this sort all jobs that require a render target other than the main one are detected and handled specially, i.e. by invoking the rendering process recursively, obviously with the altered camera set-up.