Bloom and Tonemap

Advanced OpenGL source port fork from ZDoom, picking up where ZDoomGL left off.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Wiki] [Repo] [Bugs&Suggestions]

Moderator: Graf Zahl

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Bloom and Tonemap

Post by dpJudas »

Pull request: https://github.com/coelckers/gzdoom/pull/65

I've finished my bloom and tonemapping changes. That makes the pipeline roughly look like this:

render scene -> scene texture -> bloom -> bloom down/upscale textures -> moar bloom! -> scene texture -> tonemap -> 2D/hud texture -> hud/menu drawing -> hud texture -> present -> back buffer

The various parts of the pipeline can be disabled in the menus. For example if bloom is disabled it skips those parts entirely. Likewise, if there is no tonemap mode enabled it leaves out the 2D/HUD texture entirely and draws the 2D parts directly on top of the scene. If render buffers are disabled entirely (via gl_renderbuffers 0) it renders the scene and 2D directly to the back buffer.

Because the scene texture is in the RGBA16F floating point format we are technically doing HDR rendering now - we can do lights beyond 1 (light level 255). As tonemap operators aren't really needed unless we go beyond this range (they map things down to 0-1) it opens the question whether we should try extend Doom in ways that allow for more fancy lighting. For example maybe we could allow sector lights beyond 255? I'm not sure what possibilities we have here - maybe gzdoom already supports it.

I've added a gl_exposure cvar that works like the exposure control/shutter on a camera. At 1.0 anything above 1 in the scene begins to bloom. At 2.0 anything above 0.5 blooms and, if tonemap is enabled, this range is mapped to 0-1. If it is set to 0.5 you need something above 2.0 in the scene before it starts to bloom and so on.

There's also a gl_bloom_amount cvar that controls how much gaussian blur is being done, and a gl_bloom_kernel_size that sets the blur kernel (3x3, 5x5, 7x7, etc.). I could imagine some modders would find it interesting to be able to set light values above 1, along with changing the exposure and which tonemap operator (if any) should be used. For now, I've made it so that if exposure is set to 0 (the default) the code automatically calculates an exposure based on the view sector. If you stand in dark areas the more bright areas begin to bloom.

The pull request also addresses the OpenGL 2 issue we talked about in the gamma thread. It now should work with all versions as long as shaders aren't completely disabled. I tried to make the patching share a little code with FShader although not completely.

Phew! That's about it I think! :D
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Bloom and Tonemap

Post by Graf Zahl »

Please do me one favor and take out all those effects stuff out of gl_scene.cpp and put it in a separate file. That one's already a bit too large for comfortable debugging.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Bloom and Tonemap

Post by dpJudas »

Sure, no problem. Moved them to Renderer/gl_postprocess.cpp.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Bloom and Tonemap

Post by Graf Zahl »

Can you please check all your code? I just noticed while testing the Bloom stuff that multisampling no longer works, also in the version that just uses a render buffer.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Bloom and Tonemap

Post by dpJudas »

Can multisampling be enabled from the menus or do I have to do this from the console?

In any case, it isn't working because the scene texture isn't a multisampling render buffer. I'll add a fix for this tomorrow.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Bloom and Tonemap

Post by Graf Zahl »

There's the gl_vid_multisample CVAR. It's not in the menu because it currently requires an engine restart. If you make the render buffer multisampling capable, could you do it in a way that can reset it without a restart when the CVAR changes? Then it could be fully exposed to the menu.
_mental_
Developer
Developer
Posts: 259
Joined: Sun Aug 07, 2011 13:36

Re: Bloom and Tonemap

Post by _mental_ »

I have a suggestion.

It will be really helpful if such complex pull request will be split upon several smaller ones. Or at least, keep the single PR but make each commit as small as possible.
Let's say: OpenGL 2.x compatibility for render buffer, compatibility for present shader, bloom, tone mapping (the last two can be probably split onto a few commits), etc.

There are 4 commits in the given PR, the last one is updating your own changes. The remaining three combine bunch of features in a quite obscure way.
As an example, I pushed compatibility commits to this branch. And this is even without extension check flags which were not used yet.
As a side note, those flags should designate presence of features instead of declaring absence of them IMHO. But it's a minor thing.

You are doing the great job. Although the changes aren't small and separated. I think it's very important to commit them one by one.
In case of any problem, it will be much more simple to bisect linear history of small and self-contained commits.

Of course, it's solely on Graf's discretion as I'm only expressing opinion of mine.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Bloom and Tonemap

Post by Graf Zahl »

Smaller commits would definitely be better, but on the other hand, adding such complex stuff often necessitates adjustments throughout the code, making the commits larger than ideal.
_mental_
Developer
Developer
Posts: 259
Joined: Sun Aug 07, 2011 13:36

Re: Bloom and Tonemap

Post by _mental_ »

Graf Zahl wrote:Smaller commits would definitely be better, but on the other hand, adding such complex stuff often necessitates adjustments throughout the code, making the commits larger than ideal.
Sure if it's no possible to have compile-able and working version using smaller commits.
But it's definitely possible to split the given PR on at least five self-contained commits.

By the way, using compatibility part of these changes I mentioned above (with a very small adjustment) I was finally able to get rid of old cruft in macOS back-end and to use code common for all platforms.
I must admit that everything is in place. Thanks for your work, Magnus!

EDIT: While checking the pull request I found out that the blur effect requires GLSL 1.30 because textureOffset() function isn't available in earlier versions.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Bloom and Tonemap

Post by Graf Zahl »

I just pushed the bloom and tonemap stuff. Can you add your changes as well?

I'm now just waiting for the multisampling fix. If this was all that was coming it might be a good time to do a new release next month, I think.
_mental_
Developer
Developer
Posts: 259
Joined: Sun Aug 07, 2011 13:36

Re: Bloom and Tonemap

Post by _mental_ »

Graf Zahl wrote:I just pushed the bloom and tonemap stuff. Can you add your changes as well?
Done. BTW it doesn't compile on Linux/macOS out of the box because of the recent ZDoom changes. I made pull request with the fix.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Bloom and Tonemap

Post by dpJudas »

Graf Zahl wrote:There's the gl_vid_multisample CVAR. It's not in the menu because it currently requires an engine restart. If you make the render buffer multisampling capable, could you do it in a way that can reset it without a restart when the CVAR changes? Then it could be fully exposed to the menu.
Yes, supporting dynamic switching should be doable by just recreating the render buffer object in the setup function. We can also remove the platform specific multisampling init code if it is ok to require render buffers for this feature.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Bloom and Tonemap

Post by dpJudas »

Graf Zahl wrote:Smaller commits would definitely be better, but on the other hand, adding such complex stuff often necessitates adjustments throughout the code, making the commits larger than ideal.
I usually make things in a lot of small commits, but I figured a few big ones were better for the way you were merging things in gzdoom. But it sounds like that's not an issue so I'll go back to my old ways. :)

About multiple pull requests - in this case I couldn't really finish my bloom code without the OpenGL 2 fixes to the shader/renderbuffer part. After the multisampling part this should get a lot better as the general framework for postprocessing effects should be in place.

It is probably a good idea everyone gives gzdoom a spin to make sure nothing broke. Because the render buffer thing changes where things get rendered to, there is always the chance there's some case that I missed while testing it myself. GZDoom is rather featureful after all - as the missing multisample support is a good example of. :)
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Bloom and Tonemap

Post by Graf Zahl »

One small thing I noticed: When an inter-level text screen appears there seems to be some short flicker with the wipes.

Aside from that: I do not think that requiring a render buffer is a big issue. It doesn't really require any more recent hardware than what is already required - the only thing I think that needs to be done is to allow a shader-less draw for GL 2.x hardware in case the shaders slow it down. I can't tell because I do not have such an old thing. On my Geforce 550Ti I cannot detect any performance impact at all from using an intermediate buffer.
_mental_
Developer
Developer
Posts: 259
Joined: Sun Aug 07, 2011 13:36

Re: Bloom and Tonemap

Post by _mental_ »

For "awesome" Apple's OpenGL the single problem is the bloom effect that causes exit with fatal error because of unsupported GLSL 1.30 feature.
Everything else seems to work fine. Most likely it will act the same on other outdated hardware/drivers.
If bloom cannot be made compatible with GLSL 1.20 (macOS version and old Intel's are limited to it), probably the option should be hidden in the menu.
Hard to say something about shader-less rendering though. I have an access to old notebook with integrated Intel HD4500M graphics, will try to run the latest version as soon as possible.
Locked

Return to “GZDoom”