Vulkan: Glow emission does not show up if the highlight is too small

[Norrox]

Godot version

v4.0.dev.custom_build [bc2445d0e]

System information

Windows 10, GTX 1080 Ti, Vulkan

Issue description

Glow in the editor works but as soon as i try to preview or run the game the gamera does not pick up the silly ammount of glow i enabled. Another question, the glow fade out really close to the editor view, is that related to this?

Steps to reproduce

Add emissive mesh, add camera, test run

Minimal reproduction project

glowbug.zip

[Calinou]

It works if you resize the window to be larger (specifically on the Y axis, as camera FOV is vertical by default):

https://user-images.githubusercontent.com/180032/147893086-0fe17f8e-65a2-43fe-9f81-4eb5a690793a.mp4

This issue likely occurs in 3.x too, but it is not something that can be fixed as I explain below. High-quality glow mode also has no effect on this.

Another question, the glow fade out really close to the editor view, is that related to this?

I can't reproduce this here. It's expected for glow to disappear if the emissive surface occupies a surface that's too small or if it points away from the camera. This is a limitation of glow working on a screen-space basis :slightly_smiling_face:

In your particular use case, instead of relying on glow, I recommend using a billboarded unshaded Sprite3D with a flare texture on it. This performs better and it will give you more artistic control over the effect. You can still have glow enabled at the same time, although it will cause the effect to become even stronger.

There's a nice collection of flare textures you can use here: https://github.com/RPicster/Godot-particle-and-vfx-textures

[Norrox]

@Calinou I checked in 3.4.2 and this does not happen there, and the glow object can be alot further away :) But if it's not a bug in 4.0 then it's fine :) Thanks for the tip!

[Calinou]

@Calinou I checked in 3.4.2 and this does not happen there, and the glow object can be alot further away :) But if it's not a bug in 4.0 then it's fine :) Thanks for the tip!

Did you compare a scene with the exact same mesh and camera coordinates? The screenshot of the 3.x scene clearly seems to have a larger on-screen size for the glowing object when running the project.

[Norrox]

So they seems fairly similar, but i don't know, i just feel it's something different, tossed unity in the mix aswell :P

@Calinou I checked in 3.4.2 and this does not happen there, and the glow object can be alot further away :) But if it's not a bug in 4.0 then it's fine :) Thanks for the tip!

Did you compare a scene with the exact same mesh and camera coordinates? The screenshot of the 3.x scene clearly seems to have a larger on-screen size for the glowing object when running the project.

[Norrox]

Im using additive blend mode, so is this still screen-space ? :) is the design different from what ue and unity uses? Edit: oh i see those other issues is realted to this aswell, nvm the question then :)

[Calinou]

My guess is that UE4 and Unity have enabled smaller glow levels by default, while Godot doesn't. I have a pull request that enables smaller (more local) glow levels by default: https://github.com/godotengine/godot/pull/52227

[Norrox]

i have enabled the smaller glow levels and using screen as a blend mode, but this does not fix it, if they are further away or smaller the glow in none existent. if they are in the edge of the view the glow is greater :) Here are some pics

[Calinou]

if they are in the edge of the view the glow is greater :)

This is because the objects on the edges are closer to the camera in your example. Also, when using a widescreen aspect ratio, objects on the edges will appear noticeably larger on screen, even if they remain at the same distance. This is the nature of standard camera projections – this occurs in every engine.

[clayjohn]

I investigated this a bit, and it seems we can capture small objects better using a lower sigma gaussian (i.e. a gaussian that puts more emphasis on the center pixel), however, it makes objects flicker more in motion so it isn't a great tradeoff right now. More discussion here https://github.com/godotengine/godot/issues/57693

I have a feeling that UE and Unity do what most AAA game engines do which is downsample all mipmaps with a blur, and then upsample with a different blur. Doing so is roughly 2X as expensive as the blur we do, but gets much nicer results. I am just speculating though, I don't know exactly what UE and Unity use internally.

[Jamsers]

Having bloom react consistently even with pixel size emissive surfaces (instead of vanishing) makes the communication of luminosity to the eye much more grounded, rather than feeling like a post process effect.

Practical examples of this are things like lasers or sparks or tracer rounds, which with the current bloom behavior look more like random white lines on the screen (with ACES tonemapping) rather than glowing sources of light.

I'd also like to add that, depending on the scene or intent, sometimes flickering fireflies in bloom is desirable. Examples of this are when moving fast across an ocean scene looking down at the water - the way bloom flickers in that scenario closely mimics what your eyes or a camera would see. Ditto for moving over wet sand.

The current behavior is high quality and desirable in some cases (archvis scenes will fare much better with current bloom behavior) so I think the approach discussed in #57693 regarding giving the user a choice between flickering and temporal stability would be best.

[Norrox]

Just going to drop another example here, found it hard to make small things glow without losing their color , was easier in unity to get those tiny particles go glow nice without pushing the settings to the extreme :)

EDIT 2023-07-24, I did not want to unessesary bump this so i just update the last post i did with a screenshot that shows the problem again :P

[Novark]

While I'm sure this is already known, I just wanted to confirm that this issue still persists in the latest 2D-HDR implementation introduced in v4.2.dev3. It is currently not possible to achieve glow on small/thin 2D elements (things like bullets / streaks / projectiles, particles, various VFX, etc...) without cranking up the WorldEnvironment node settings to the point where everything else is totally blown out.

Hopefully a solution can be worked out to improve or resolve this issue, as well as the related #57693 issue (either by exposing the sigma parameter somewhere in project settings or the WorldEnvironment node, or by some other means).

52227 may also need to be revisited with the recent rendering changes.

[clayjohn]

@RPicster and I have been discussing some options to fix this. We have come close to something that appears like a good tradeoff. Hopefully we have some results to share soon

[veevoyel]

I have the same problem, so I did some investigation. As @Novark said, the problem is present in the 2D-HDR implementation: small and thin objects don't glow properly, and this is a big problem especially for pixel art projects.

Below is a comparison of the glow in Godot 3 and in Godot 4.2 dev 5 with 4 lines: 1x16, 2x16, 3x16, 4x16: You can see that in Godot 4.2 dev 5, the glow is not visible at all, while it's always visible in Godot 3. This example was made with the default parameters of Glow, except for Blend Mode which is set to Screen. You can find the projects here: Glow issue.zip

I tested many different settings:

• The parameters recommended in #52227 don't fix this.
• Insanely high values for Levels (>20), Intensity (max: 8), Strength (max: 2) in WorldEnvironment don't work.
• Insanely high values in the Modulate raw colors (20) of the objects don't work.
• Insanely high values in WorldEnvironment AND in the raw values of the object make the bloom appear a little, but it's really diffuse and unstable: zooming in a little makes the screen turn white.

Lastly, according to @RPicster who discussed a similar problem in #57693: using a sigma of 1.5 for the kernel values only fixes the "blockiness" of the glow, but not the lack of glow for smaller objects. You can see screenshots proving that in #57693.

However, the Bloom parameter of the Glow in WorldEnvironment is the only one that works well regardless of the zoom/size of the objects, here's an example (Godot 4.2 dev 5): But it's not really useable in our case since it affects all objects in the scene...

I also did a video to show that the glow appears only if we are really close to the objects:

https://github.com/godotengine/godot/assets/109180172/16800e09-cd83-45c0-9442-b481762fd59e

Stretch Mode was set to canvas_item so that the glow changes when resizing the window.

[RPicster]

I have been talking with @clayjohn a bit and we found several things - and we have addressed most of it. I still need to open a PR for the changes.