Make Bloom Effect Seperate (HUD-Weapons/World)

[XxMiltenXx]

As the title says, I want to request that you can set the bloom effect seperately for HUD weapons and other objects. While I do like it on world objects, on most weapon (esp. hands) it looks kinda silly IMO. That way it would be up to the user if he wants it for both or not.

[De-M-oN]

I'd like to +1 this, because it looks indeed strange if the arms of doomguy start to glow like a lamp.
It also looks like if the arms / weapon themself start to glow, while no light source being around. For example the weapon had strong bloom applied while the room was just a square with no single light source in it. Just a square sector with some barons in it for a test.
My question would be then: What causes the bloom to kick in? Just the brightnesslevel of the sector? Do lightsources have an additional effect, or no at all?
I couldnt see a reason on this squareroom with no sky and no lightsource where such a strong glow would come from?

Here an example with doomguy's hand

https://abload.de/img/gzdoom_2018_01_05_17_6lpwf.png

Its the worst case I could gather, but it looks also weird on the vanilla chainsaw and also every project brutality weapon or any weapon where an arm/hand is visible. They all glow. And skin really shouldnt glow.

So I would suggest as well to have an option to disable the bloom for weapons
and if the bloom kicks in just by the brightness of the sector it would be my suggestion to change it to the way that it just reacts on light sources alone like standing next to a lamp etc.

[Major Cooke]

This was already suggested and no'd. It's impossible to do. It takes the whole scene and applies the bloom. I.e. like taking a snapshot, then applying bloom and displaying just that.

[dpJudas]

It was no'd? It can be done, technically. It is just that I haven't found the time/motivation yet to fix it.

[Rachael]

It was no'd? It can be done, technically. It is just that I haven't found the time/motivation yet to fix it.

This was already suggested and no'd. It's impossible to do. It takes the whole scene and applies the bloom. I.e. like taking a snapshot, then applying bloom and displaying just that.

This was in reference to individual objects, not the player sprite, which is drawn after the entire scene and can, in fact, be separated from the scene itself for purposes of calculating bloom.

[Chris]

My question would be then: What causes the bloom to kick in? Just the brightnesslevel of the sector? Do lightsources have an additional effect, or no at all?
I couldnt see a reason on this squareroom with no sky and no lightsource where such a strong glow would come from?

Here an example with doomguy's hand

https://abload.de/img/gzdoom_2018_01_05_17_6lpwf.png

Bloom kicks in from the brightness level of a given pixel. Bloom is simulating an effect of over-exposure, where the intensity of the incoming light is so high that it saturates the pixel and bleeds into the surroundings. Consequently, I think the effect should be applying to the HUD weapons as much as it does to the world. If there's light hitting the player (point light, sector light, or both) it should light up the weapon, and if the light level is high enough the weapon should bloom like anything else.

At best maybe the threshold values could be tweaked, though even that should be done cautiously. Since Doom was designed for LDR rendering (where all the colors and light levels are made to stay "in range"), the threshold does have to be lower than would be typical for HDR rendering if it's to have any effect without modded lights.

[dpJudas]

The biggest problem is that Doom's diminished light is not natural at all. It causes a situation where the weapon and anything straight in front of you is a lot brighter than the rest of the scene. To make matters even worse, sprites are given a greater brightness than wall and floor, increasing the chance they will stand out and exceed the threshold.

Since it isn't really an option to fix the light model, the second best option is to disable it for psprites as they are always so much more bright than the rest of the scene.

[dpJudas]

Here's a fix that removes the bloom effect from the psprites: bloom_psprite_fix

[Nash]

Here's a fix that removes the bloom effect from the psprites: bloom_psprite_fix

That's a global fix, right? Then some weapons with intentional glowing parts attached to them won't bloom anymore... =P

[Chris]

FWIW, an 'std::function' requires a heap allocation to construct, which seems pretty wasteful to do every frame when you know where the call's going regardless. The way that's done feels like you're trying to have FGLRenderer depend on state it doesn't know about.

[dpJudas]

That's a global fix, right? Then some weapons with intentional glowing parts attached to them won't bloom anymore...

Yes, it is global, although it doesn't apply to 3D weapon models. I didn't make it an optional thing because nobody should really want the weapon to be constantly glowing. If you want parts of a custom weapon sprite to bloom, you can just bake the bloom directly into its sprite.

FWIW, an 'std::function' requires a heap allocation to construct, which seems pretty wasteful to do every frame when you know where the call's going regardless. The way that's done feels like you're trying to have FGLRenderer depend on state it doesn't know about.

The memory allocation will not affect performance - it is one allocation per frame.

My primary motivation for using a lambda there is that I want to keep the EndDrawScene logic in the GLSceneDrawer class. I know I could have passed 'this' and 'lviewsector' as arguments and then called the function directly (after making it public), but I wanted the reader of RenderViewpoint to see directly what PostProcessScene needed, as a hint to what is wrong with the design of this function.

[Nash]

Just to reconfirm; does this remove only bloom from psprites, or remove post processing completely? If it's the latter, then I don't think it'd look good with the various post processing shaders currently available. Just one example is the underwater view warp. It'd look weird if only the hands aren't affected.

Even if such weren't the case, I think world blooming not bleeding over the hands is weird. It'd look like the weapon sprite was just pasted on top of the screen, no?

[Pixel Eater]

One thing that could help is if the bloom ramped it's intensity down as the pixel's saturation increases.

I'd like to try that PSprite fix with FillSpectre whenever I'm back at my computer

[Nash]

This was [already in]

[Pixel Eater]

I've looked around but can't find what's needed to enable this. Is there a new term that can replace "beforebloom" in GLDefs or is it a console command?