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

Re: Bloom and Tonemap

Post by dpJudas » Sun Jul 31, 2016 22:47

Eruanna wrote:(I really like my Doom status bar... *sniff*)
The mugshot is by far my favorite part of the status bar. :D

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

Re: Bloom and Tonemap

Post by dpJudas » Sun Jul 31, 2016 22:52

Graf Zahl wrote:which is the best GL extension loader I have found yet.
It does look very nice.

So I just run it again with "lua LoadGen.lua -style=pointer_c -spec=gl -version=4.5 -profile=compatibility -extfile=gl_extlist.txt load" instead of the 3.3 it uses now? Or is there more to it?

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 » Sun Jul 31, 2016 23:19

Generally, yes, but you shouldn't create a blanket 4.5 include unless you really need 4.5. Better enable only the extensions you need. The files were intentionally created with 3.3 so that unintentional use of 4.x features results in a compile error, not some hard to track down bug later.

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

Re: Bloom and Tonemap

Post by dpJudas » Sun Jul 31, 2016 23:30

Okay got it. KHR_DEBUG to the gl_extlist.txt file it is. :)

ZZYZX
Developer
Developer
Posts: 14
Joined: Thu Nov 26, 2015 6:10

Re: Bloom and Tonemap

Post by ZZYZX » Mon Aug 01, 2016 20:16

r_drawplayersprite 0 (often used as part of nice screenshot bind) results in horrible behavior. If bloom is enabled there will be no bloom, if tonemap is enabled you will simply get pitch black screen.

ibm5155
Posts: 152
Joined: Tue Oct 25, 2011 13:05

Re: Bloom and Tonemap

Post by ibm5155 » Mon Aug 01, 2016 21:15

Nash wrote: That would allow mappers to make 3D-floor deep waters that have reflective surfaces (currently this combination of setup is impossible). And of course this should be switchable for the user.
You mean... something like this?
Image :lol:

I'm wondering if my fake 3D water hack still Works with the latest version of gzdoom :lol:
dpJudas wrote:Okay got it. KHR_DEBUG to the gl_extlist.txt file it is. :)
I'm ready for the testing :D

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

Re: Bloom and Tonemap

Post by dpJudas » Mon Aug 01, 2016 23:45

ZZYZX wrote:r_drawplayersprite 0 (often used as part of nice screenshot bind) results in horrible behavior. If bloom is enabled there will be no bloom, if tonemap is enabled you will simply get pitch black screen.
I think the fix for http://forum.drdteam.org/viewtopic.php?f=24&t=7042 also fixes this one. At least toggling that on and off on my local copy works fine.

User avatar
StrikerMan780
Hellbender FTW
Posts: 21
Joined: Fri Nov 23, 2007 10:11
Location: Somewhere in Cyberspace
Contact:

Re: Bloom and Tonemap

Post by StrikerMan780 » Tue Aug 02, 2016 2:55

Earlier someone suggested the ability to disable bloom for certain actors or textures... Couldn't stencils be used to do this like below, or some property passed to/from the fragment shader to determine what pixels can be disregarded during the bloom pass?
Image

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 » Tue Aug 02, 2016 8:32

Stencil: no. GZDoom already uses the stencil buffer for marking portal windows. Having it active for other things may cause interference. You'd also need an exclusion buffer, not an inclusion buffer, because what about lights on walls etc.?

But in the end, read what I said before: Bloom is a filter that's supposed to be on the camera side so it really makes no sense to exclude stuff.

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

Re: Bloom and Tonemap

Post by dpJudas » Tue Aug 02, 2016 9:18

My original vision for the bloom pass was to extend the range of allowed light level values. If gl_exposure is set to 1.0 the bloom only begin to appear for pixels that go beyond 1.0 in the scene - but with the current maps and mods that meant nothing would bloom (except maybe only if you placed a bright dynamic light in a full bright sector). So gzdoom's auto exposure mode currently increases the exposure to bring the brighter stuff into the blooming range.

As an example, if things could be set more freely, we could make only the imp fireballs bloom by having a 1.0 exposure and then fireballs at 1.5 light (~380 light level).

Gez
Developer
Developer
Posts: 1399
Joined: Mon Oct 22, 2007 16:47

Re: Bloom and Tonemap

Post by Gez » Thu Aug 04, 2016 15:58

dpJudas wrote: 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.
The immediate thing that comes to mind is allowing fullbright sprites to be affected by dynamic lights.


But having Quake-style overbrights would be nice, too, if a software implementation could be added to ZDoom.

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 » Thu Aug 04, 2016 16:38

Sector lights beyond 255 would have been possible before, if the lighting code was changed to be able to process them. All the lighting is done in the shader where you still have full floating point precision of the pixel.

Of course this is something that will require a map flag and some changes to the lighting thinkers to work as intended.

User avatar
Nash
Developer
Developer
Posts: 1226
Joined: Sun Sep 25, 2005 1:49
Location: Kuala Lumpur, Malaysia
Contact:

Re: Bloom and Tonemap

Post by Nash » Thu Sep 22, 2016 11:01

Sorry for resurrecting this thread but I figured I'd re-use this one instead of making a new one just to ask a silly question.

I'm trying to describe tonemap to someone who's not too graphics-savvy, but I'm not really sure what the tonemap feature is actually doing, to be honest. Would it be accurate if I say "tonemap is basically Instagram filters for GZDoom"? :mrgreen:

Rachael
Developer
Developer
Posts: 3623
Joined: Sat May 13, 2006 10:30

Re: Bloom and Tonemap

Post by Rachael » Thu Sep 22, 2016 11:45

You're gonna hate me for this, Nash...

https://en.wikipedia.org/wiki/Tone_mapping

The long and short of it is: It's making things appear more realistic on your monitor by increasing the contrast of the scene. Your monitor is not able to display a wide range of colors, so the min and max colors that are actually available simply look too muted in a realistic or even rendered sense. By applying some sort of dynamic contrast, the image then looks more realistic and life-like, even on your limited monitor - or as another way to look at it - it tries to get your monitor to mimic the original scene - well, Doom's approximation of it, in any sense.
Spoiler: Zen Sarcasm

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

Re: Bloom and Tonemap

Post by dpJudas » Thu Sep 22, 2016 15:45

The short answer is that, currently, the tonemaps are mostly useless in GZDoom, except for the palette one.

The long answer: In modern games the colors and light in a scene can expand way beyond the 0-255 range used in Doom. Imagine the first map in KDiZD, where you are standing outside. Modern games would make the light here in some far brighter scale, lets say 0-10,000 range, and then when you look inside the light values would be maybe 0-500.

No matter where you stand in the world, an eye exposure sampling pass determines what the average light level is for the scene at that viewpoint, just like our real eyes. Then, based on that, it maps a certain range to the 0-255 range our monitors can show. For an inside scene that might be 0-400 -> 0-255, and for outside that might be 0-8,000 -> 0-255.

The tonemap is the way it maps the chosen range to the 0-255 range. In a scene where we are standing outside and looking in, a simple divide by 8000 would leave the inside values very compressed and the few overbright light values would get clamped. The tonemap operator enhances the contrast in such a way that you can still see the difference in overbright values and the contrast in the darker inside area.

Now, the reason all of this is somewhat pointless in Doom is that right now it is very difficult to do light beyond the 0-255 range in GZDoom. Only thing that can really do it right now are the dynamic lights. You also can't load HDR (16 bit) textures for the sky and such either, leaving little additional dynamic range to be revealed here. So right now the tonemap setting is mostly there for completeness sake. I personally have it off when playing. It could be argued that, besides the palette tonemap, the tonemap is an artistic choice by the mapper and not a user setting (classic maps would always have it off).

Locked

Return to “GZDoom”