Compositing multiple cameras to layer objects at vastly different distances

itinerant · March 6, 2025, 10:51am

Godot Version

4.4

Question

Hi all,

I’ve been trying to solve a problem neatly for quite some time now and, despite attempting various different approaches, I’m drawing a blank.

I’m building a game where planetary travel is possible, and I wanted to be able to render stars, planets, moons, etc in the correct places in the sky while standing on the ground. I also need to be able to render local terrain close to the player and distant terrain that could be many kilometers away. I have earth-size (and bigger) planets which do work and you can traverse them, but rendering terrain that can be 10s or 100s of kms away with varying LODs while also rendering objects only cms away is a challenge. Using floats I need to keep the numbers within ranges that aren’t going to overflow anything.

I originally built my own rendering engine to handle this but then switched to Godot at the beginning of 2024. My engine did something pretty basic, it had a number of cameras using different scales (eg, a local camera rendered everything at 1m = 1.0 unit to the camera, a distant camera rendered terrain using 1000m = 1.0, then I had a 1AU:1 camera and a 1LY:1 camera for the planets and stars).

So I would just render each camera in turn starting with the 1LY camera, then clear the depth buffer, then render 1AU to bring nearby planets into the scene, clear the depth buffer, render the 1KM camera, etc. In reality there weren’t four cameras, I just had one camera and moved it between each stage of the rendering process.

When I switched to Godot it seemed like the way to do something similar was to use viewports. I got it working using this, where I’m rendering 4 full-screen viewports, one on top of the other with a transparent background enabled for each one.

It does work but the problem I’m finding is it means I can’t do stuff like FSR, which disables the transparent background, and also it’s adding quite a bit of memory overhead to my project. I’m using about 5gig of RAM to load everything at start. When I add the viewports into the equation this jumps to around 8. My feeling is that I’m doing something ‘hacky’ with the viewports that maybe they weren’t intended to be used for, and having a separate texture for each viewport seems wasteful when I used to be able to render everything to the same surface in one hit.

I’ve been looking for other solutions, but this is where I’m getting stuck. What I really want to do is part way through rendering the scene, clear the depth buffer, switch cameras, and keep rendering - but that doesn’t seem possible. I keep recoding this part of my system and not getting anywhere.

I thought maybe I could at least get FSR working if I took the output of each viewport and added it as a texture to a full-screen quad that appeared underneath the objects in the next viewport in the chain (so, feed the output of one viewport into the background of the next viewport). I thought then the topmost viewport wouldn’t need a transparent bg and FSR could be enabled. This kind of worked, of course it didn’t fix the memory concerns, but more than that I got weird graphical issues when moving the camera to extreme positions.

Is there something obvious I’m missing? With the rendering compositor, can I force the viewports to all render to the same texture or something like that?

Maybe I should settle for using the viewports the way I’ve currently got it working, but every time I set up my 1m camera to use FSR, the result looks so much better it makes me spend more time trying to find a way to ditch the viewports

Thanks, any ideas thoughts greatly appreciated,

Chris.

itinerant · March 6, 2025, 2:58pm

Having written the above, I’ve now found the following:

github.com/godotengine/godot-proposals

Support using multiple cameras in a single viewport

opened 12:13AM - 29 May 20 UTC

Mantissa-23

topic:rendering topic:3d

**Describe the project you are working on:** A first-person shooter, making use… of first-person viewmodels that are separate from third-person/worldspace models. **Describe the problem or limitation you are having in your project:** Godot currently only supports rendering one camera per viewport. This makes the following use-cases difficult to implement: - Secondary camera with fixed FOV for consistent viewmodel appearance despite changes to primary camera FOV - 3d "skybox" implementation where distant/background objects are rendered at a smaller scale in a separate scene. **Describe the feature / enhancement and how it helps to overcome the problem or limitation:** Allowing multiple cameras (with different render masks) to render to the same viewport would overcome this problem. For each use case: - A primary camera is used to render the world, with player-changeable FOV. A secondary camera is used to render viewspace objects, such as gun viewmodels, hands, grenades, etc. - A primary camera is used to render near objects; a secondary camera is used to render far objects which are stored in a separate 3d render layer. This is a feature that is present in both Unreal and Unity, and is used for similar reasons. **Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:** Cameras will have a `depth` field, which determines the order in which they render; pixels that reach the background of one camera (i.e. are not rendered) at a higher depth will be rendered by the next lowest camera. I don't have an understanding of Godot's rendering pipeline, and understand it is in flux for Godot 4.0. I have C++ experience, and with some pointers I'd be willing to implement this myself for 3.2.2 or 4.0. **If this enhancement will not be used often, can it be worked around with a few lines of script?:** I believe these can currently be implemented using a screen-space ViewportTexture and Viewport nodes, however, I haven't tested this, and I imagine the performance would be worse than rendering to the same, default Viewport from multiple cameras. If the performance would be similar, go ahead and close this issue. That being said, I do believe using ViewportTextures is still less _intuitive_ than having multiple cameras rendering to a single Viewport. **Is there a reason why this should be core and not an add-on in the asset library?:** This requires a change to the Camera node as well as how it interfaces with the rendering pipeline. I also cannot imagine it being a large change, either code-wise or size-wise.

Which makes me think what I’m after doesn’t really exist at the moment!

Cheers,

Chris.