Hejl Dawson tonemap is much darker on 3.5.x builds

[Chris]

That's already being done, but it's hard to get values > 1.0 if there's nothing creating such values in the first place.

Dynamic lights are additive, aren't they? With brightmaps that force texels to a certain base brightness, dynamic lights to add brightness on top of that, and eye adaption to raise the base brightness in dimmer scenes, I don't see it being that hard to get values > 1.0. There are probably ways it could be improved (HDR textures/brightmaps, new options for lighting ranges, etc), but even without that it should still be functional.

[Graf Zahl]

I have seen how the current algorithm fails. For example, I have seen the blood on a monster corpse bloom just because it got hit by several strong dynamic lights. It's impossible to reliably tell if a pixel is just brightly lit - and if so, if it's just bright or actually glaring. What this completely misses is material properties that might factor into the effect, that's where some special texture design or dedicated definitions come into play.

Such naive assumptions about lighting rarely work out in real world scenarios. They sound good on paper but when putting them to the test you'll quickly run into scenarios where your assumptions screw you over because in real life matters are more complex.

[Rachael]

IMO, the best way to do bloom is literally to only bloom the overbright parts of the scene.

That may be oversimplifying it, but it's possible to achieve >1.0 with material shaders quite easily. If you have, say, a street lamp, you can use a white texture with the bright parts of it and apply a hardware shader that pretty much does "return vec4(vec3(c) * 2.0), c.a);" and make sure, obviously, that the texture does not get diminished, and you pretty much nail it.

But that's just me, I guess. /shrug

[Graf Zahl]

IMO, the best way to do bloom is literally to only bloom the overbright parts of the scene.

If it was that easy... The main problem is that the only overbright stuff is what gets hit by strong dynamic lights. This completely leaves out bright sprites like the plasma projectile
Also, we were already talking about material properties to achieve this. What you suggest isn't really any different from what I was suggesting, i.e. tell the renderer in some way what parts are overbright or supposed to emit bloom. But I think doing it through a secondary render buffer gives better control without compromising the main image to get the info across.
[/quote]

[Gez]

It's kind of a chicken-and-egg problem. Using heuristics to add bloom where there isn't any is a good way to test that the system actually works. Then implementing a way to explicitly mark bloom sources and ripping away the heuristics makes sense.

[Chris]

As I understand it, the bloom effect is intended to simulate the effect of over-saturating the camera sensor. Light comes in through the camera lens and shines on the red, green, and/or blue sensor, and when the incoming energy is too high for a particular point, it's bleeds into the neighboring area. In such a scenario, the heuristic method is the only one that makes sense since it shouldn't matter the source of the light, just that the amount of light reflected into the camera is too high. Some kind of bloom map or over-brightening object property or something would just be a hack to work around the lack of HDR textures (a potentially useful hack, but a hack nonetheless).

I always play with bloom on, and haven't really noticed any glaring issues (pun not intended). It works great with the eye adaption feature as well, as you can be in a dim room with a full-bright texture peaking in from somewhere and that texture will be appropriately blown out, then when you move toward that bright area it comes into focus as the dim room becomes darker and harder to see details in. It can sometimes look a bit weird with sprites, but that's a quirk of sprites, since they're an unrealistically flat billboard texture that doesn't have the nuances of 3D geometry. Dynamic lighting in general looks weird on them, but IMO it's better than them being completely separate from the rest of the scene's lighting.

[GFD]

I do appreciate the "eye adaptation" feature from an accessibility perspective, as it makes it a lot easier to see for those with poor eyesight, and I find it looks a lot better than just jacking up the brightness or gamma. There's certainly value to it even aside from aesthetics.

[dpJudas]

As I understand it, the bloom effect is intended to simulate the effect of over-saturating the camera sensor. Light comes in through the camera lens and shines on the red, green, and/or blue sensor, and when the incoming energy is too high for a particular point, it's bleeds into the neighboring area. In such a scenario, the heuristic method is the only one that makes sense since it shouldn't matter the source of the light, just that the amount of light reflected into the camera is too high. Some kind of bloom map or over-brightening object property or something would just be a hack to work around the lack of HDR textures (a potentially useful hack, but a hack nonetheless).

One of the problems with this kind of logic is that nothing in a Doom scene is based on real physics. The scene light is ambient with a low dynamic range (0-255). The dynamic light fall-off is linear, not quadratic like real light. The diminishing light effect that makes things brighter close up is as far away from real physics as you can get. Basically none of the objects in the scene follows real physical properties.

I always play with bloom on, and haven't really noticed any glaring issues (pun not intended).

I have it on too and don't find the problem to be as big as other people seem to make it. Nevertheless, that doesn't mean that perhaps a more artistic approach with bloom maps couldn't have worked better. One more advantage of the bloom map approach is that the SSAO pass could tap into it and not shade the pixels that bloom.

By the end of the day I wonder which approach would have worked best for Doom. I'm just not motivated enough yet to actually test out the other way.

[Graf Zahl]

I always play with bloom on, and haven't really noticed any glaring issues (pun not intended).

I have. And when it happened it always ruined the look of a scene. The worst thing about it is that depending on where I look the same spot can look completely different. The worst thing is bright skies, they tend to bring out the worst in the Bloom algorithm.

A good spot to test this is Vengnce.wad, an old Doom 1 mod for Boom.
Just start the first level, go to the left, look out of the window and turn around a bit. The Bloom effect on the sky is all over the place, constantly changing. I have no idea why it is this inconsistent in picking up bright spots and applying bloom to them but since this is not an isolated occurence and once you have seen the effect it's impossible to un-see it, it renders the entire feature worthless.

[Chris]

One of the problems with this kind of logic is that nothing in a Doom scene is based on real physics. The scene light is ambient with a low dynamic range (0-255). The dynamic light fall-off is linear, not quadratic like real light. The diminishing light effect that makes things brighter close up is as far away from real physics as you can get. Basically none of the objects in the scene follows real physical properties.

I consider that to be a separate issue. The construction of the scene (how light is generated/applied to the surface) and the display of the scene (how the resulting intensities are shown to the user) are separate things, in my mind. It doesn't matter how or when a light value goes over 1, just that when it does, it gets bloom applied as a way to indicate it since a monitor can't display color intensities above 1.

I have it on too and don't find the problem to be as big as other people seem to make it. Nevertheless, that doesn't mean that perhaps a more artistic approach with bloom maps couldn't have worked better. One more advantage of the bloom map approach is that the SSAO pass could tap into it and not shade the pixels that bloom.

By the end of the day I wonder which approach would have worked best for Doom. I'm just not motivated enough yet to actually test out the other way.

I suppose my main problem with the artistic/bloom map approach is, I tend to prefer things like that to be a dynamic or emergent property. A bright color blows out part of the scene because that color happens to be really intense as a result of the light it's emitting and/or reflecting at a given angle or location, rather than because it was predetermined it would blow out the scene regardless of external factors.

Such a thing could be a useful workaround for the lack of HDR textures, or to add an occasional artistic touch, but it doesn't seem right to me to be the main way for bloom to work.

[Pixel Eater]

The problems with Doom's textures are more than their lack of HDR, it's because they're full of CRT. There are red column sprites in the same dynamic range as ceiling tech lights because of the darkness of the monitors used. Without remastering them and the palette there's no way I can imagine of separating the two into different ranges.

If I were forced to come up with a formula for faking HDR levels I'd toy around with 'Value x ( 1 - Saturation ) x 2' but I don't think it'd do a lot for the above example.

[Caligari87]

At risk of being the "stupid questions" guy, I have a couple stupid questions/suggestions. I make no pretense about these being good/workable/implementable, just dumping them as food-for-thought / discussion.

• How about two modes for bloom? 0 == off, 1 == Fake/LDR, 2 == true / HDR. 2 would only be applied on pixels that actually go above 1.0 brightness, as intended. 1 would work the way it does now.
• Unclamp dynamic lights so they can overbright. I think there was some talk about this in another thread about fog?
• Unclamp sector light levels so a whole sector can overbright. While this would be mostly for maps that specifically target such an effect, my work on DarkDoomZ has shown me it's pretty trivial to compress sector lightlevels across a map; I imagine it would be equally as trivial to write a mod that expands sector lightlevels into HDR ranges for stock/vanilla levels, if desired. Some sector environmental / diffuse light model might be needed here?