Multiple cameras, viewports etc

[spydon]

Since we still had quite some ongoing discussion on #933 we'll move that discussion here and discuss how we should progress.

I'll quote some messages here:

@luanpotter -

I agree with this in parts. I think having the camera as a component that can have children makes a lot of sense. That allow for multiple cameras and hud elements can be out of the camera. however even hud elements should be subject to viewport. so I think it would look like this:

game (has a viewport)
         + -- "hud" components (not transformed by any camera)
         + -- camera 1 comp
         |        + -- components transformed by camera1
         + -- camera 2 comp
                  + -- components transformed by camera2

I don't think it makes any sense for a game to have more than one viewport. I don't see how that would apply (the viewport draws constraints on the screen, doesn't just translate stuff inside it).
so having that in mind I am not sure unifying camera and viewport would work for this structure. wdyt?

@st-pasha

A viewport is a rectangle (or some other shape) on the screen where a camera renders the world. The viewport's primary function is to clip the world (which is probably too large to fit on a screen anyway). The camera's function, on the other hand, is to move the world within the viewport, i.e. to choose the point within the world that the camera is currently "looking at". As such, a camera and a viewport are 2 parts of a single entity, and one cannot operate without the other.

For example, I'm currently making a demo game where there is a world that can be viewed normally on a screen, but also the ability to use a magnifying glass to look at some parts of the world more closely. The magnifying glass here is a separate camera (with its own custom viewport), which can be dynamically rendered on top of the main world. The magnifying glass even has some "hud" elements: the frame and the handle. These are bound to the viewport (i.e. move together with the viewport) but are not actually clipped by the viewport.

another one:

Yes, there are some components whose rendering logic might depend on the settings of the camera, such as zoom level, or the position of the viewport. For example, GoogleMaps gradually removes smaller details of the landscape as you zoom out. The Parallax is another example, where you have a large image and want to render only that portion of it which is visible through the viewport. In cases like these, when there are two cameras, the elements will want to render differently for each camera.

I can see two solutions here:

Add Camera argument to the render() method.
Add static variable Camera.current and then have each camera set/clear that variable during its render call.

The first approach is more robust, but also more disruptive to existing user code. The second approach is more conservative but is essentially a hack to pass down the camera via unorthodox means.

and another one:

If we have a world that is observed through multiple cameras at the same time, then we can't have the world to be mounted to all those cameras. While it is superficially possible to addChild(world) on multiple cameras, it would result in world not having a proper notion of a parent, and further unknown consequences caused by the fact that our component tree is no longer a tree.

A more sane approach would be for the camera to know about the world that it observes (via a property, similarly how in this PR the camera knows about the ComponentSet of its parent), but the world wouldn't actually be mounted to the camera. That way we wouldn't have to worry about duplicate update() calls either.

Note also that if we have a component within the world that cares about being observed, and there are multiple cameras looking at the world, then ultimately the component will have to be rendered differently even within the single render cycle.

Things we should think of:

• Implementing the possibility of multiple cameras shouldn't make the simple use-cases harded
• Multiple cameras should be able to render the same object
• Should a viewport be a part of a camera, or not

I had a quick look at how Unity and Godot is doing it.

• Unity has a "Normalized View Port Rect" in each camera so that you can set where and how much of the screen that the camera should render on: https://docs.unity3d.com/ScriptReference/Camera.html
• Godot builds it up in a tree so that a camera can be contained within a viewport: https://docs.godotengine.org/en/stable/tutorials/viewports/viewports.html

[spydon]

@flame-engine/flame-colab @st-pasha for visibility.