Hejl Dawson tonemap is much darker on 3.5.x builds

[AL-97]

Noticed that starting from the previous stable release (GZDoom v3.5.0), Hejl Dawson tonemap makes the game much darker than before. Here are the comparison screenshots made with fresh installs of GZDoom v3.4.1 (brighter picture) and v3.5.1 (darker one) on the otherwise default settings (only the tonemap option has been changed from their default value):

Graphics hardware are RX 560 4gb running the 18.6.1 version drivers.

[dpJudas]

This is more or less an intended change. In the earlier versions it would brighten or darken the scene based on camera exposure (average light in scene) - now it just applies the tonemap directly. I didn't like the earlier effect and it generally made the scenes a lot brighter than intended.

[AL-97]

This is more or less an intended change. In the earlier versions it would brighten or darken the scene based on camera exposure (average light in scene) - now it just applies the tonemap directly. I didn't like the earlier effect and it generally made the scenes a lot brighter than intended.

Any chance of getting, maybe, a new tonemap with that effect from earlier versions? I actually did like how it looked.

[PixelWAD]

I agree, many scenarios worked out great in that mode.

[dpJudas]

I find it interesting that, when it comes to Doom light modes and alterations, someone always likes whatever effect is produced no matter how wrong it is.

My original intention with the tonemaps were to try increase the dynamic range of the scene in concert with the bloom pass, not to overall cancel out any darkness in the scene. In the end I ended up concluding the entire way I was doing it was plain wrong and I changed the tonemaps to do exactly what it says on the tin: apply a tonemap operator and nothing else. Honestly, I'm considering removing all of them except the palette one - leave it up to mods to apply a PP tonemap if they want.

I'm sorry if you enjoyed the original effect, but I don't want it back as it complicates certain things the post-processing code.

[Graf Zahl]

Welcome to Doom!
This is a realm where no such thing as an unwanted effect exists, someone will always find some unintended use for it.


So, regarding the postprocessing effects in general, I personally have them all off.
The tonemaps really don't do anything useful in my book, the lens distortion is mostly a gimmick, and while Bloom and SSAO are great on paper, the way they interact with the scene really makes them unusable in my book - unfortunately. The main problem with Bloom is that this tries to guess which parts are supposed to bloom instead of making this explicit during rendering and SSAO creates so much bad aliasing when being appied to distant geometry, that the bad overshadows the good. A mostly white map like Frozen Time really makes the problems stand out most.

For Bloom I think the only way to make this useful is to either declare sprite frames as "bloomy" and/or add a bloommap texture (which in many cases can just be the brightmap) but in any case, it must be the object being rendered that determines whether bloom is wanted or not, and not some heuristics being run over the entire scene.

[dpJudas]

For Bloom I think the only way to make this useful is to either declare sprite frames as "bloomy" and/or add a bloommap texture (which in many cases can just be the brightmap) but in any case, it must be the object being rendered that determines whether bloom is wanted or not, and not some heuristics being run over the entire scene.

I agree, but at the time I thought a heuristics approach could work as that's generally what various online articles about bloom did when bloom was new. However, since then I've come to really dislike games that rely on such behaviors, i.e. newer battlefield games, or Skyrim where camera exposure is constantly going up an down.

If I'm going to update the bloom pass at some point I'll probably alter it to do exactly what you describe here, but then I'm sure there will be people that would rather have used the old one. Especially for maps where there are no bloom maps available.

[Graf Zahl]

Of course. Do it wrong and some people complain. Do it right and other people complain.

Nevertheless, for some of the stock items in the game we can provide bloom information so it's not as dire as you make it out.

[PixelWAD]

Please keep the distortion effect. It's very helpful on ultrawide screens. Makes the sides of the screen easily visible. When i turn it off, my fov stretches too much

[GFD]

Would changing the [wiki=FOV]field of view[/wiki] directly not suffice for your needs here?
A better solution, of course, would be alternate projection methods better suited to wider displays. I always found stuff like Blinky very interesting, but I never see these sorts of things actually get implemented in any games. I don't know if it's made more difficult to use because graphics cards don't really work this way, or because developers just don't know or care to implement any alternate projection methods, or a combination of both.

[PixelWAD]

I tried blinky in the past and it was really cool!
It would be very nice to get it in gzDoom at some point, also to make 360 video recording of the gameplay.

As for FOV, past certain point, things just don't seem to feel right, or become smaller, FPP models starts to show things you should not see etc. So my sweet spot is FOV 100 with lens distortion on. Makes it more immersive for me, and feels like playing on curved screen.

[Chris]

For Bloom I think the only way to make this useful is to either declare sprite frames as "bloomy" and/or add a bloommap texture (which in many cases can just be the brightmap) but in any case, it must be the object being rendered that determines whether bloom is wanted or not, and not some heuristics being run over the entire scene.

Isn't the point of bloom to act dynamically on the scene? It's intended to cause over-bright pixels to bleed into neighboring pixels rather than simply clamp to the maximum value. Especially when you consider things like eye adaption (raising or lowering the overall scene brightness depending on the general scene brightness) and moving light sources, what should or shouldn't bloom isn't known to the object being rendered. At best an object could declare which parts of its texture are inherently over-bright, as if you used an HDR glow/emissive map texture, but the bloom itself should apply over the entire scene.

I realize the main problem with the original games is that the lighting/colors can't be made over-bright since they have non-additive fixed-range values. Although that's not really an issue when you add in dynamic light sources and various types of translucency as many mods do. And since GZDoom even comes with lights.pk3 to add dynamic lights to the stock games' maps (and the eye-adaption thing mentioned earlier), I don't think any special consideration needs to be made in that regard.

[Graf Zahl]

The problem is that GZDoom does not have overbright pixels to bloom. And as implemented the algorithm randomly picks up on things that mess up the entire result, like the blood on corpses that get affected by multiple light sources or totally changing the colors in bright skies etc.

As long as there is no reliable way to let the algorithm detect bright light it just can't work.

[Chris]

As long as there is no reliable way to let the algorithm detect bright light it just can't work.

Can't you render to a floating-point buffer, and high-pass values that are >1.0 for applying the blur? With brightmaps, dynamic lights, and eye adaption, even the stock maps should get results then.

[Graf Zahl]

Can't you render to a floating-point buffer,

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. The renderer was simply not made for this - when it was written there were no shaders and no floating point buffers - and the underlying map format doesn't really support these things.