Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CanvasItem Modulate values above 1.0 are clipped #75153

Closed
Novark opened this issue Mar 20, 2023 · 4 comments · Fixed by #80215
Closed

CanvasItem Modulate values above 1.0 are clipped #75153

Novark opened this issue Mar 20, 2023 · 4 comments · Fixed by #80215

Comments

@Novark
Copy link

Novark commented Mar 20, 2023

Godot version

v4.0.stable.official [92bee43]

System information

Windows 11 [Vulkan]

Issue description

Adding glow to particles (CPU/GPU are both affected) via the WorldEnvironment node appears to not be working correctly in Godot 4.0.

Setting the particle's modulate property to a color which exceeds the 1.0 HDR threshold does not result in any glow being applied to the particles.

Steps to reproduce

  1. Create a CPUParticles2D (or a GPUParticles2D) node
  2. Set it up to emit maybe 1000 particles or so in a radial pattern (or something that would allow glow to be seen)
  3. Create the WorldEnvironment node, set the mode to Canvas, enable glow (basically just set up the simple configuration that creates glow on anything with an HDR threshold > 1.0 - nothing out of the ordinary to how this has always been done)
  4. Go to the particles node and change the modulate property to have a raw color value > 1.0 (the HDR threshold)

Following these steps, it can be observed that the particles do not glow. However, they will glow if you crank up the particle count to something like 100,000 for some reason - despite the raw color value being less than the HDR threshold. For some reason this behaviour seems incorrect for color values in the [0 < x < 1.0] range, and is simply ignored for raw color values > 1.0.

Minimal reproduction project

Reproduction is quite straightforward and quick to set up, and probably doesn't warrant adding a reproduction project.

@Calinou
Copy link
Member

Calinou commented Mar 20, 2023

The same optimization is also used in 2D rendering as of 4.0, which is why setting Modulate above 1 on any 2D node looks the same as modulate = 1.

Note that even if overbright modulate could be used in 2D, glow in 2D isn't expected to work unless you decrease HDR Threshold below 1.0.

@Calinou Calinou changed the title WorldEnvironment node does not appear to take the GPU/CPUParticles2D modulate property into consideration when calculating glow CanvasItem Modulate values above 1.0 are clipped Mar 20, 2023
@Novark
Copy link
Author

Novark commented Mar 20, 2023

The same optimization is also used in 2D rendering as of 4.0, which is why setting Modulate above 1 on any 2D node looks the same as modulate = 1.

Note that even if overbright modulate could be used in 2D, glow in 2D isn't expected to work unless you decrease HDR Threshold below 1.0.

A couple questions / comments:

  1. In the thread for Sprite3D Modulate won't respect raw color values over 1 #75083, you proposed a temporary workaround using a custom shader. Do you have any proposed temporary workarounds for the 2D equivalent of this problem?

  2. As noted in some other discussions, this seems to be a pretty significant feature regression in regards to how many people used the WorldEnvironment node in Godot 3.x to achieve target glow on a per-asset basis. The current approach in Godot 4.0 to make the node work in a "True HDR" fashion is great, as it lets developers take advantage of newer HDR displays, however, there definitely needs to be some further work done to bring back some form of targeted direct control over HDR/glow. Over-driving color values beyond a 1.0 HDR threshold was fairly intuitive, so hopefully something similar can be re-introduced in an upcoming 4.x version.

Feel free to close this bug / mark as duplicate for #62110.

@Calinou
Copy link
Member

Calinou commented Mar 20, 2023

  1. In the thread for Sprite3D Modulate won't respect raw color values over 1 #75083, you proposed a temporary workaround using a custom shader. Do you have any proposed temporary workarounds for the 2D equivalent of this problem?

The same workaround should be usable in 2D.

HDR glow is planned to be readded in 2D at some point, but it needs to be rethought to support HDR displays (so we can't use the same approach as 3.x, which was too limited to provide this). This will most likely involve having an option to perform 2D rendering like 3D, with tonemapping and linear texture inputs.

Feel free to close this bug / mark as duplicate for #62110.

The documentation aspect for CanvasItem modulate and CPUParticles/GPUParticles color ramp is still relevant (in both 2D and 3D), so I'll leave this open.

@clayjohn
Copy link
Member

clayjohn commented Apr 12, 2023

This is the same core issue as #62110

The problem is that 2D rendering is always in LDR.

Copying Reduz' explanation here:

This probably deserves a better explanation. What we have as 2D HDR in Godot 3 is not really HDR, as it still mixes color in sRGB space.
Given HDR displays (and displays with higher contrast) are becoming common place, the idea in Godot 4 is that 2D HDR is actual, true HDR that can be perceived as such. This feature makes it possible to have things such as user interfaces combined with 3D rendering while doing HDR output (which is not possible using the method we use in Godot 3).

Of course, this requires a bit more work and it means that, if HDR is enabled, hint_albedo needs to do the proper conversion of textures from sRGB as well as sRGB happening later. Its a good amount of work and we did not make it to 4.0 because there are so many other things that need to be worked on, so it will happen after its released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants