Horde3D

Idea 1
Ok, so multiple cameras in a naive sense is moderately simple to implement:

a) Add a 'calcOrthoProjectionMatrix' which defines an orthographic camera
b) Add a <Camera> tag to the scene definition files, allowing named cameras to be attached to any node.
c) Add a <SwitchCamera> tag to the pipeline definition files, which sets the current camera by name.
d) Allow Render Buffers to be named as textures in material scripts.

This allows multiple viewports, 3D GUIs, and pretty much everything else the casual graphics program needs.

Unfortunately, while it is nice and simple, it doesn't really help the general case of an application which wants to control multiple cameras in software. Lets look at a program which renders impostors in the distance - it only needs to update a few impostors each frame, and the number is not fixed, so it needs to be able to dynamically setup cameras, render them to textures, and bind the resultant texture to a material.

Idea 2
To solve this problem, we need a little more complexity, and a system much like the Material Contexts. So lets dump the system I just outlined, and assume a 'Camera Context' - hereafter called a 'Pass' - instead.

Passes are defined in the pipeline configuration, and contain one or more stages. Each camera is associated with a named Pass, and it uses that pass as its pipeline when rendering (much like lights and materials).

Then we can define a default pass, which will be used by the main camera, and can do post processing and so forth, and an impostor pass, which can be used by the impostor rendering code (with no post proccessing most likely), a GUI pass for the Ortho camera, and so on...

I think this solves all the problems associated with multiple cameras, but please give some thought as to feasibility, better ways to do this, etc. - all comments welcome

Creating a pipeline manager supporting multiple pipelines would be another approach. Each camera could identify a pipeline (or series of pipelines) that it uses. The render function would be overloaded to define which camera to use for the render (and therefore which pipeline/s as well). The current pipeline just runs through processing its commands when the scene is rendered. A pipeline manager would almost the exact same thing (exceptions being identifying pipeline, executing it, identifying any pipelines to execute immediately afterwards, executing those, etc etc).

Major points of a pipeline manager (+ is good, - is bad):

+Emphasis on several smaller files instead of singular monolithic ones
+Eases spiffier special effects

Complete pipeline changes, AvP style vision modes or blueprint rendering
Temporarily appending a pipeline with another pipeline
Easier to specify and manipulate arbitrary user data to feed to shaders, such as an intensity variable for a blur

+Most likely friendlier to a multiple scene graph approach

You would probably want to do such if using imposters
+Places more application specific things to the discretion of the application
-What to do about <Setup></Setup> in a pipeline?
Similarities and total differences have obvious solutions but what about a difference in size for a render target with the same name?

I don't think any of this is explicitly in contradiction to your idea 2. You laid out more of an XML spec than a full on approach.

Orthographic projection and exposing the render targets to materials are almost complete 'musts' at some point.

Am I wrong to say that point 2 is somewhat already there, except that only one independent _scene_ is currently possible?

Can I have multiple independent scene graphs? This thread is a bit confusing because there is no mention that any of this had been implemented, but it seems that it is?

E.g. in a GUI pass, how could I make sure that nothing from other parts of the scene graph is displayed? I can now only imagine that I would have to toggle group node visibility to fit each camera...

Also I'm bit confused as to how to achieve the rendering of GUI on-top of a previously rendered 3D scene?

Multiple cameras, each with their own pipeline have been implemented - as far as I know, multiple scene graphs have not.
Ja, this would work - but I would be a bit wary of implementing a GUI in terms of Scene Nodes.
Turn off depth-testing for the GUI pass.

_________________
Tristam MacDonald - [swiftcoding]