Render editor viewport gizmos and UI on a separate render pass to prevent them from being affected by post-processing effects

[golddotasksquestions]

Describe the project you are working on

This applies to any 3D project I've worked on so far

Describe the problem or limitation you are having in your project

I can't see the viewport UI/gizmos clearly because the WorldEnvironment post processing is applied to the viewport UI/Gizmos as well. It drives me crazy.

This has been discussed before, but those issues have been closed. Why, I really don't understand.

https://github.com/godotengine/godot/issues/8140 https://github.com/godotengine/godot/issues/8485 https://github.com/godotengine/godot/pull/43896

"There is really no fixing to this, you can disable environment now in individual viewports, so closing this."

Disabling the WorldEnvironment is unfortunately not really an option because the WE is so substantial and intertwined to any 3D scene lighting. As level artist, environment artist, art director, game designer, and concept artist I cannot evaluate what I am doing/what needs to be done without WE on because the scene would look completely differently without.

If this really can't be fixed for the 3.X branch anymore, I really hope this will be fixed in 4.0, because working like this on anything visual is really frustrating.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

It would help me to see all the little things I have to constantly click and drag.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The viewport gizmos should look like the axis in the top right corner in the above screenshot, unaffected by the light and post processing of the game world. Unfortunately I'm not a 3D graphics programmer, so I don't know anything about the implementation.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Would be used by anyone working in 3D and who wants nice visuals.

Is there a reason why this should be core and not an add-on in the asset library?

It's a basic usability necessity.

[Calinou]

If gizmos are drawn on a separate render pass, then they won't be able to be occluded by the scene's geometry anymore. I'm not sure if this can be fixed.

A simpler way to fix this would be to have a toggle or editor setting to always disable glow, auto exposure and depth of field while in the editor. In 4.0, this is made easier for depth of field since it's part of the CameraEffects resource which you should define in the Camera3D node instead of WorldEnvironment.

[golddotasksquestions]

A simpler way to fix this would be to have a toggle or editor setting to always disable glow, auto exposure and depth of field while in the editor.

I really disagree strongly. This might be simple to implement, but it's definitely not solution. Glow, auto-exposure, bloom and DOF change the look of a scene drastically. Much more so when your project is stylized. Godot rendering is not great at realism, so people use it for stylized art first and foremost.

When I place an asset, create the detail of the scene, when I paint the splatmap, when I come up with the atmosphere, when I compose the layout of the environment ... I need to be able to see what the end result will look like as I am doing it.

Godot's post-processing UX already sucks tremendously, precisely because the Editor scene is always looks slightly different from the running scene and the intertwined WE setting result in super tight tolerances where 0.03 looks ok but 0.01 or 0.06 look terrible ... resulting in having to have to resort to editing those numbers numerically because the slider won't work in those fine details floating point position any more ... which is again: guesswork. Please let's not make this ordeal worse by further facilitating guesswork rather than fixing the issue properly (WYSIWYG)

[Jummit]

While I don't like your attitude to Godot's capabilities, I agree that at some point this problem has to be addressed. I don't think that it would be a huge problem if the gizmos wouldn't be occluded by geometry, I actually think this is how it works in UE4.

[Calinou]

I don't think that it would be a huge problem if the gizmos wouldn't be occluded by geometry, I actually think this is how it works in UE4.

It would look pretty strange for the grid and origin lines. We wouldn't even be able to partially occlude those (like we do for the new 3D selection box).

[Zireael07]

Grid/origin lines could stay as-is IMHO, the main problem is gizmos being affected by glow/what have you.

[golddotasksquestions]

@Jummit I'm using Godot exclusively and daily now since more than two years, full time. If I would not believe in Godots capabilities, I would not have spend all this time learning, using, and celebrating the community effort that this engine is. But just because I love this engine, and admire the people making, improving and using it, does not mean I've become desensitized to it's (sometimes glaring) flaws. Everyone has different usecases, I can only report on mine. I'm not criticizing the contributors who worked on an issue I'm reporting on (If that's why you mention "attitude"). My sole intention is to bring attention to what I consider a sizeable stumbling block on Godot's path to glory as well as an impediment to my own daily work.

[Jummit]

@golddotasksquestions I agree with most of your criticism, just not with how you express it. Anyway, I would like it if we could stay on-topic.

[alexfreyre]

I agree with this proposal because with post-process effects it is impossible to see the gizmos, a great example is desaturate completely the scene, the gizmo is almost indistinguishable.

[dueddel]

I know it's not really necessary to confirm that issue with more screenshots, but I can't help. I think the problem is even worse with DoF Blur.

These are some environment settings

This is what a simple Spatial node's gizmo looks like with above environment settings:

Blurred gizmo doesn't come in very handy when you need some overview of your scene (e.g. if you wanted to arrange some level assets):

However, I too would love to see a fix for that.

[Calinou]

I know it's not really necessary to confirm that issue with more screenshots, but I can't help. I think the problem is even worse with DoF Blur.

This has been solved in the master branch by moving DoF Blur settings to a separate CameraEffects resource, which is disabled in the editor unless you're currently previewing a camera node with a CameraEffects resource.

This can't be backported to 3.x because it breaks backwards compatibility. I see two ways to fix this issue in 3.x:

• Disable DoF Blur in the editor viewport unless a camera is being previewed (not particularly intuitive).
• Add a Preview Depth of Field checkbox to the Perspective menu at the top-left corner of the 3D viewport.

[atirut-w]

If gizmos are drawn on a separate render pass, then they won't be able to be occluded by the scene's geometry anymore

Maybe carry the depth map over to the gizmos pass?

[lentsius-bark]

@Calinou I'd like to chip in to say that adding a toggle that'd make blur, bloom and colour corrections game only, that way we could at least set things up, make sure they work and then toggle it.

I see DoF blur referenced a lot but let's not omit the fact that bloom, colour adjustments and colours can also make working with gizmos in 3D awry.

[Jaku-San]

Would be real nice QOL to be able to use gizmo when in overdraw mode, and other cases of course

[paddy-exe]

Chiming in here since the Colors of the Gizmos shouldn't be dependant on the Sky Background (current beta 16) either:

[mieldepoche]

Also worth mentionning that gizmos can be altered, wrongly colored, partially or even completely hidden in debug display modes:

simplescreenrecorder-2023-09-26_05.16.48.webm

[atirut-w]

At this point, I think it's proven that this should have at least medium priority, considering that gizmos are not supposed to be affected by post processing settings in the first place and that other engines seem to also draw gizmos in a separate pass.

Regarding gizmos occlusion, I stand by my suggestion to carry the depth map in the first pass into the next, unless it's impossible at the moment.

[Calinou]

Now that we have https://github.com/godotengine/godot/pull/81286, it should be possible to make all 3D gizmos ignore fog by adding the Disable Fog flag on their materials.

Edit: Done in https://github.com/godotengine/godot/pull/82413.

[Zireael07]

@Calinou Fog is only one of the problems. Blur and DOF are the other common offenders

[Nagasadri]

I'm just here to report volumetric fog is also affected, making the UI disappear into the fog with distance.

I vote in favor of the separate pass, if possible with occlusion. I understand it wouldn't be a small undertaking, but I think it would be worth it for the non-fog effects mentioned earlier some time down the line.

Now that we have godotengine/godot#81286, it should be possible to make all 3D gizmos ignore fog by adding the Disable Fog flag on their materials.

That sounds great, but how does one go about modifying the gizmo material to do that ? It might be worth considering flipping that flag on by default. I can't think of a use case where I'd want my gizmos to receive fog.

[marcinn1]

Now that we have godotengine/godot#81286, it should be possible to make all 3D gizmos ignore fog by adding the Disable Fog flag on their materials.

Great!! How about glow?

[Calinou]

That sounds great, but how does one go about modifying the gizmo material to do that ? It might be worth considering flipping that flag on by default. I can't think of a use case where I'd want my gizmos to receive fog.

This was done in https://github.com/godotengine/godot/pull/82413, which will be in 4.2.dev6.

Great!! How about glow?

This also requires drawing to a separate pass, as there is no way to exclude specific objects from glow. Glow only cares about how bright each pixel is to determine whether there should be visible or glow or not (it operates on the final color buffer).

[Xorblax]

Being able to change the gizmo material would be really great because all I need to do is make light gizmos ignore depth completely and my problem would be solved.

[damil42]

Gizmos should be completely unaffected by visual effects. I wonder how is this done or behave in other 3D programs like Unity, UE or Blender (EEVEE PostFx)? If I understand correctly, moving the gizmos into a separate pass, makes using depths of the scene impossible. It will be always drawn on top. Hmm...🤔 I don't want to install Unity or UE now to test the behavior. But I see in Blender, that the gizmos are not affected by post fx (e.g. bloom) or other things. The gizmos also use the scene depth. Not sure how this is implemented. Is it possible to have a material which don't care about shading or post fx? Or draw the gizmos at last with depth mask? Idk... It would be great if we find a solution. Otherwise, there are cases where you cannot use gizmos anymore and have to disable/enable fx all the time which is annoying. Toggle environment changes too much. Yes, sometimes you don't fx in your editor. But in general you want to see it while level design etc. And btw. in some display modes, the gizmos disappears which is not intended for sure.

[atirut-w]

Considering that Godot now have the ability to use hooks to insert post processing, inserting a render pass for gizmos might be a little easier now?

[darkhog]

From: https://github.com/godotengine/godot-proposals/discussions/9773

Currently the gizmos seem to be rendered in the same pass as the rest of the scene, meaning they're susceptible to several issues:

• Getting discolored due to the weird World Environment settings:
  
• Not being rendered properly with certain shaders (notice how the arrow showing the direction of the directional light gets cut out when the water is rendered, as if the arrow gets rendered under the water shader:
  

Having gizmos being rendered in a separate pass after everything else gets rendered would fix both of these issues as the gizmo lighting settings could get reset so that gizmos always have proper colors regardless of WorldEnvironment settings used and (due to it being a separate pass) the gizmos would always be rendered on top of everything else regardless of what shaders the developer uses.

ADDENDUM: It seems like the other icon gizmos gets hidden under the water - again, rendering gizmos on top of everything in the separate pass would prevent that issue. As for depth not being available to the second pass, I don't see it as an issue. The gizmos should be hidden based on distance from the camera anyway, and the transform gizmos should be visible regardless of distance or what's in front of them.

[Calinou]

• Getting discolored due to the weird World Environment settings:

This should be fixable in most cases by dividing the gizmo brightness by the current camera exposure value, essentially undoing the exposure/brightness change from the environment.

Not being rendered properly with certain shaders (notice how the arrow showing the direction of the directional light gets cut out when the water is rendered, as if the arrow gets rendered under the water shader:

That issue can be fixed by using opaque rendering for line gizmos, although some gizmos are transparent so it'd need to be toggled on a per-line basis.

Now that https://github.com/godotengine/godot/pull/75303 has been merged, a lot of gizmos will only be displayed as fully opaque (or not displayed at all), so we can probably change the transparency mode for a lot of line gizmos.

ADDENDUM: It seems like the other icon gizmos gets hidden under the water - again, rendering gizmos on top of everything in the separate pass would prevent that issue. As for depth not being available to the second pass, I don't see it as an issue. The gizmos should be hidden based on distance from the camera anyway, and the transform gizmos should be visible regardless of distance or what's in front of them.

This is fixed in 4.3 by https://github.com/godotengine/godot/pull/91174.

[ArseniyMirniy]

@Calinou It seems absolutely unclear right now regarding when these elements will be placed in a different pass? It isn't fixed in 4.2 and 4.3 (some issues are fixed) and the proposal isn't marked as 4.x at all. Can you specify at least briefly?

[Calinou]

@Calinou It seems absolutely unclear right now regarding when these elements will be placed in a different pass? It isn't fixed in 4.2 and 4.3 (some issues are fixed) and the proposal isn't marked as 4.x at all. Can you specify at least briefly?

There is no set milestone for this proposal, as nobody has started working on implementing this.

Also, there are ways to resolve this issue without using a different pass:

• For exposure and adjustments (color correction), compensate the scene exposure and adjustments in the gizmo colors.
  • Edit: It seems manual exposure is already compensated for in unshaded material rendering (which is what gizmos use). However, this does not affect autoexposure, which is likely a bug. Resolving it for unshaded materials would also resolve the issue for gizmos, and subsequently for glow (unless you have HDR Threshold below 1.0 or Bloom above 0.0).
  • Adjusting unshaded material for adjustments is more debatable though (it's sometimes desired to have adjustments modify those), so this would need a render mode or a new BaseMaterial3D property to be controlled.
• For depth of field, disable depth of field when a node is selected by default (unless a camera is being previewed).

For depth of field in particular, you can disable it in the editor only by putting the CameraEffects resource in the Camera3D node instead of WorldEnvironment. This is the recommended approach in the documentation. When doing so, depth of field remains visible when previewing the camera.

[jcostello]

DoF is not the only problem affecting gizmos. Glow also affects, color grading, etc. A different pass will be ideal so no even a custom shader will affect the gizmos.

Edit: Also debug modes also affect gizmos which is painful

[ArseniyMirniy]

@Calinou It seems absolutely unclear right now regarding when these elements will be placed in a different pass? It isn't fixed in 4.2 and 4.3 (some issues are fixed) and the proposal isn't marked as 4.x at all. Can you specify at least briefly?

There is no set milestone for this proposal, as nobody has started working on implementing this.

Also, there are ways to resolve this issue without using a different pass:

• For exposure and adjustments (color correction), compensate the scene exposure and adjustments in the gizmo colors.
• For depth of field, disable depth of field when a node is selected by default (unless a camera is being previewed).

For depth of field in particular, you can disable it in the editor only by putting the CameraEffects resource in the Camera3D node instead of WorldEnvironment. This is the recommended approach in the documentation. When doing so, depth of field remains visible when previewing the camera.

All of the above is like moving to another room when there's a fire in your room: not a solution, but a cover-up for the issue (and not even a usable one). The only solution is to move it into another pass.

[atirut-w]

Yeah, why are you guys so weirdly against putting gizmos on a separate render pass? Worst case scenario you literally just add a second camera that follows the main one and only renders the gizmos layer and composite it onto the main viewport. I've done a similar thing in the past in Unity to implement moon without editing the sky shader, it won't kill you.

[darkhog]

Yep, rendering them in a separate pass is the best way. It won't be too draining on the GPU resources (as those are just gizmos) and won't affect exported games anyway as gizmos are only visible in the editor.

[clayjohn]

I'd like to add a little bit of clarity here.

Yes, the suggestion to add gizmos to a separate render pass is good. However, before we do that, we need to add the ability to create and use separate render passes in the same viewport. Currently, Godot does only one render pass per viewport, so our options are to: A) render gizmos in a separate Viewport (and lose access to to depth information) or B) render the gizmos in the same viewport and workaround the problems.

Neither one of those options are great and frankly, both are bad enough that its not worth our time to work on them.

The only good option is to implement the ability to have multiple render passes and then move editor gizmos into a separate render pass. I would love if we had the ability to create multiple render passes in a single viewport already, but the Rendering team is very short on volunteers willing to take on big projects like that, so there has been no visible progress.

As always, the way it works with open source is that there is no progress until someone is willing to do the work.