Multiple cameras break tonemapping / any post processing

[osmanlodzero]

Describe the bug

I'm trying to create a viewmodel camera that renders on top of the normal world camera. The arms render fine but they stomp the main cameras tonemapping ( make everything darker ).

To Reproduce

1. Create two cameras, one is main, the other is viewmodel ( priority 2 ).
2. Add a tonemapping component to the main camera and set the exposure compensation to a high value for testing purposes.
3. In the viewmodel camera, set the Viewport.X ( or y ) value to 0.5 to crop the camera in order to see the difference.

Notice how dark the viewmodel camera makes things.

Expected behavior

The transparant bits on the viewmodel camera should not affect anything.

Media/Files

Additional context

No response

[KingOfTheFBI]

Bump

[garrynewman]

Yep this fucked. We shouldn't have ever really advised people to do viewmodels this way IMO, it doesn't really work.. You see, what we're doing with the multiple cameras is creating different views, but if you're drawing a ViewModel you really want to be in the same view.

This is one of the most complicated parts of the engine that we haven't really managed to break down into something more manageable yet.

So what I suspect we should be doing is allowing you to mark a camera as a "child" of another camera. This might not need to be a camera at all tbh, it might just be a sceneobject that adds the right layers to the view. We should be doing this in the right place in the render pipeline, after transparent is written, but before post processing.

[Retroeer]

I'm assuming this means this isn't getting fixed for a while? 😔

[damienfamed75]

Still a problem, If I have a WorldPanel and want to keep it rendering over everything else I have to use another camera and that breaks the post-processing completely.

This makes me wonder if being able to apply shaders on the rasterized outputs from Cameras would help...

[osmanlodzero]

Yep this fucked. We shouldn't have ever really advised people to do viewmodels this way IMO, it doesn't really work.. You see, what we're doing with the multiple cameras is creating different views, but if you're drawing a ViewModel you really want to be in the same view.

This is one of the most complicated parts of the engine that we haven't really managed to break down into something more manageable yet.

So what I suspect we should be doing is allowing you to mark a camera as a "child" of another camera. This might not need to be a camera at all tbh, it might just be a sceneobject that adds the right layers to the view. We should be doing this in the right place in the render pipeline, after transparent is written, but before post processing.

What would you advise in terms of view-model. Unreal for example has chosen to not support a seperately rendered view-model and this has caused so many teams to have insane hacky solutions. I've seen situations where they manage 3 separate meshes, one for full-body shadow casting, one for the actual view model, and another for first person legs etc. And on top, not having separate FOV ( and/or being able to render the view-model last ) forces folks to either scale it to be super tiny, or use very hacky 'panini' shaders to squash the first person model etc etc. They all work, but feel incredibly dirty. I'd understand if this feature won't be supported, but I think it a lot of us would miss it.

[Retroeer]

Has there been any work on this? It's slowly becoming more frustrating trying to work around

[CarsonKompon]

Yep this fucked. We shouldn't have ever really advised people to do viewmodels this way IMO, it doesn't really work.. You see, what we're doing with the multiple cameras is creating different views, but if you're drawing a ViewModel you really want to be in the same view.

Has anything changed around this? HC1 is proudly using a 2nd Camera for the Viewmodel and looks/works great. They're just able to dodge a lot of the issues mentioned here by simply not using post-processing or any other complicated stuff on the viewmodel camera (which you'd definitely want to do at some point... as well as having post-processing that affects both the viewmodel AND game cameras)

There's surely got to be a nice way to easily use multiple cameras in scene while retaining the same View.

[DevulTj]

Yep this fucked. We shouldn't have ever really advised people to do viewmodels this way IMO, it doesn't really work.. You see, what we're doing with the multiple cameras is creating different views, but if you're drawing a ViewModel you really want to be in the same view.

Has anything changed around this? HC1 is proudly using a 2nd Camera for the Viewmodel and looks/works great. They're just able to dodge a lot of the issues mentioned here by simply not using post-processing or any other complicated stuff on the viewmodel camera (which you'd definitely want to do at some point... as well as having post-processing that affects both the viewmodel AND game cameras)

There's surely got to be a nice way to easily use multiple cameras in scene while retaining the same View.

HC1 does not use a second camera. It’s disabled.

[Nolankicks]

Yep this fucked. We shouldn't have ever really advised people to do viewmodels this way IMO, it doesn't really work.. You see, what we're doing with the multiple cameras is creating different views, but if you're drawing a ViewModel you really want to be in the same view.

Has anything changed around this? HC1 is proudly using a 2nd Camera for the Viewmodel and looks/works great. They're just able to dodge a lot of the issues mentioned here by simply not using post-processing or any other complicated stuff on the viewmodel camera (which you'd definitely want to do at some point... as well as having post-processing that affects both the viewmodel AND game cameras) There's surely got to be a nice way to easily use multiple cameras in scene while retaining the same View.

HC1 does not use a second camera. It’s disabled.

So everyone who uses a second camera is just fucked? I wish this would get fixed or the way that they are done is rethinked.

[Dudejoe870]

I suggest an alternative way of doing Post-Processing and Camera compositing, that may or may not work with the engine, I almost got it to work by doing it in C#. However performance wise I was foiled by #6170 Also it was a little buggy and didn't have time to fix it during this game jam (but I probably could of). My solution is, essentially taking every Camera that is marked to be rendered to the screen, and rendering them to their own textures. Then in the main rendering loop, you take each Camera sorted by its priority, and create a Quad with a Z index based off of the priority. The Quad can be rendered with a Shader that has two options for blending, normal transparent blending (if you need it for any reason, it can be apart of the CameraComponent settings, and also maybe the SceneCamera settings, if the compositor is that low-level. It'd be a little slower but might be useful for certain effects), but by default, just regular alpha clipping (basically, if the alpha is less than one, the pixel is discarded, and the Quad for the Camera under it is visible). Post-processing however, I think should be split into two things. First a "Global" post-processing component that allows you to apply post-processing to everything after the compositing has happened... and the current way of doing post-processing per-Camera. Which would allow you to isolate Cameras to do certain post-processing effects only on certain Cameras. All of this would allow you to composite Cameras on top of each other using transparent Clear Colors, with proper Post-processing. One caveat that you may need to think about however, is the Depth Buffer. Different Cameras can have different ZNear and ZFar values. So just also compositing the Depth Buffers might cause issues. I think that perhaps that's what you should do though, as effects that use Depth (like Ambient Occlusion), could just be applied per-Camera instead of globally; preventing any issues with your Viewmodel gun causing a weird ambient occlusion effect around itself. This is a fairly important thing to be implemented, as Viewmodels are very common, and should be easy to make. Post-processing is also very common. This should allow for both of those things to work properly, without much breaking either (the one added thing, Global post-processing, would just be a separate component that'd mark an object that when it had post-processing effects applied to it, it'd be applied to the composited frame, instead of an individual Camera).

[garrynewman]

So, I think there's two different requirements of multiple cameras.

1. Camera stacking - you want to render a camera inside another camera's viewport. vewmodels, cockpits etc..
2. Viewports - you wnt to overlay another camera render on the screen.. splitscreen, rearview, maps etc..

What we have right now is 2. We don't support camera stacking.. so when you try to make a ViewModel using this method it's fucked.

[ScoutWozniak]

With the new render layers system, it seems like you can get viewmodels to render over most of the world and it doesn't break post processing. This might be a good substitute for the camera stacking ability at least for now

[timmybo5]

There is a hack workaround to allow post processing applied to the view model camera, if you enable the color buffer for just 1 frame it allows the view model camera to deal with all the post processing stuff.

https://github.com/user-attachments/assets/2bee0942-5ba4-4f60-bf58-c08d446e9e8f