Gzdoom: No light diminishing?

I noticed while playing wads on OpenGL mode that there are no light diminishing effects, but they do appear on Software Rendering mode. What's the deal?

call me a nub, but whats Light Diminishing exactly?

From the DOOM Press Release:
Light Diminishing/Light Sourcing

Another touch adding realism is light diminishing. With distance, your surroundings become enshrouded in darkness. This makes areas seem huge and intensifies the experience. Light sourcing allows lamps and lights to illuminate hallways, explosions to light up areas, and strobe lights to briefly reveal things near them. These two features will make the game frighteningly real.

well, I think one of the texture formats supports a crude light diminishing feature.

other that that, you're stuck with crappy "depth fog". sorry.

heh. light sourcing. they finally implemented that in quake- though vavoom has a crude implementation of what it would have been like.

GoatLord said:

I noticed while playing wads on OpenGL mode that there are no light diminishing effects, but they do appear on Software Rendering mode. What's the deal?

The 'deal' is that Doom's software lighting model can't be emulated with a hardware renderer. The capabilities of depth fog are a little too limited for that. I tried to approximate the light levels of the software renderer as precisely as possible but an excact emulation can't be done.

Once pixel shaders get fast enough it might be possible but right now such an approach simply costs too much performance.

Well, I'm just perplexed, because I also occassionally use Doomsday, which supports OpenGL and has light diminishing.

I haven't looked at the algorithm Doomsday uses but rest assured that GZDoom's default settings (lighting model = Doom, depth fog = on) are the closest I could get to Doom's original light levels. As important as diminshing light (which is implemented in GZDoom) is the correctness of the light levels. If those are too far off the maps just don't look good.

If you change the lighting model to 'standard' you might get something that is more to your liking although everyone I have talked to so far considered the effect too uneven.

Graf Zahl said:

I haven't looked at the algorithm Doomsday uses but rest assured that GZDoom's default settings (lighting model = Doom, depth fog = on) are the closest I could get to Doom's original light levels. As important as diminshing light (which is implemented in GZDoom) is the correctness of the light levels. If those are too far off the maps just don't look good.

That's true in the context of gzdoom, but not as a general statement. First off, it depends on the level. Long corridors show the differences here quite well. Then it depends on one's monitor/vid card and last opinion.

Let's start with the simplest and eliminate opinion for a bit. Compare what looks the closest to sofware mode (not saying that's better or worse, merely a comparison point). So compare to STOCK DOOM (or even software ZDOOM) and compare the diminishing light levels in a "tunnel". One may or may not like it, but that's not the point. Are there noticeable diminishing light levels? This is how one does a valid objective comparison.

"darker" just hides mistakes more, it doesn't mean that it's better. All that has been said is that using gzdoom (in the context of how everything else displays) ends up being liked better with the darker view. That has nothing to do with other ports.

Haven't rechecked JDOOM, but since RISEN3D (derived from same and R3Dedit) certainly do a better job (come the closest) in this department then JDOOM should also. One can see the light noticeably diminish with distance. Arguably this is subjectively better since it blends nicer than software mode with distance for a more realistic effect. IOW it can be done better. So check the JDOOM code :)

deep said:

So check the JDOOM code :)

When using the same gamma settings both renderers look more alike than you think. But Doomsday tends to get too dark for medium light levels. For those Doomsday uses denser hardware fog. Yes, that makes the light diminish quite noticably but it isn't quite right. At those light levels the software renderer never fades to black as hardware fog inevitably does so you have to compromise in some way.

When I created the current lighting model my main goal was to approximate the software renderer's brightness at a medium distance and to avoid getting too dark in the distance. I got the current settings by constantly switching between the GL and the software renderer and IMO it is the best that can be done with standard GL features.

Graf Zahl said:

When using the same gamma settings both renderers look more alike than you think.

Then I think? Since I am redoing the RISEN3D code (meaning I know how it works) that means I have a lot of seat time in this topic. Hence I "think" not. Secondly there is a WAY better method to change the look than just "gamma" or a crude 3 choices.

It helps to really look to see the distinct difference here and the huge variety of customization to suit a players taste, monitor and vid card available in these 3 ports. Trust me, there is no comparison in this regard.

But Doomsday tends to get too dark for medium light levels.

I don't think so. You don't realize the options available - hence make an opinion based on limited knowledge. Similar to other criticisms that have been made that merely tell me lack of knowledge of a port, not that it's true.

I got the current settings by constantly switching between the GL and the software renderer and IMO it is the best that can be done with standard GL features.

That's nice, but doesn't prove anything. "best" is still purely subjective and clearly not the same as objective:) I can just as easily say "it's not the best that can be done with standard GL features" and can back it up by pointing you to features you apparently don't realize exist.

Not only that, one's monitor makes a VAST difference here and it would be unwise to conclude anything from one's own testing. In fact, that's why DeeP was the first editor that had brightness correction since I knew I couldn't really rely on my own impressions.

We've had this discussion before regards monitors and vid cards. I have one older (Sony relatively bright)) monitor where the gzdoom "DOOM" setting looks like poo since it's way too dark. OTOH, you can DUPLICATE gzdoom's look exactly in R3Dedit (and I assume JDOOM/RISEN3D) by adjusting the 3 various aspects of the display.

This much more sophisticated solution is what all ports need to do - not just a few fixed settings and an overly simplistic "gamma".

Btw, what's the deal with not letting a light level of -0- not be actually BLACK? That's taking away a level author's prerogative. [FYI, again JDOOM/R3D allow a variable minimum darkness if that's what a player wants - but it's not forced on them - or is there some menu option that turns this off that I didn't see?]

This reminds me - I'd been intending to add sector light range compression to Doomsday for a while now (since I played with it in R3D) as it does make a noticeable difference and allows much closer emulation of the original software renderer. As deep says, due to the nature of hardware accelerated rendering it is not possible to balance the lighting model on ones own machine and expect those settings to be optimum for others.

Sector light range compression is calculated in Risen3D (and Doomsday as of 1.9.0) as:

i = sector->lightlevel;
if(light_compression_percentage > 0)
    i += (int)((255.f - i) * ((float) light_compression_percentage / 255.f));

I understand something similar is already implemented in GZDoom but it is not user customizable (and appears to not work correctly with regard to very dark/pitch black sectors).

So is there something I can type in on the gzDoom console that can emulate or simulate fog/light diminishing on OpenGL?

deep - Does Risen3D clamp to the lower ambient light limit before or after sector light range compression? I want to make sure we do it the same way in Doomsday.

DaniJ said:

Sector light range compression is calculated in Risen3D (and Doomsday as of 1.9.0) as:

i = sector->lightlevel;
if(light_compression_percentage > 0)
    i += (int)((255.f - i) * ((float) light_compression_percentage / 255.f));

I understand something similar is already implemented in GZDoom but it is not user customizable (and appears to not work correctly with regard to very dark/pitch black sectors).

I've been planning to customize the formula for the next version. Although I like my current formula I've been having issues with it on extremely dark levels. But IMO it needs 3 parameters to be really flexible:

- the light level below which the effect starts (in GZDoom it is currently 192)
- the minumum allowable light level (currently 35)
- the percentage itself (but I have to admit that I don't really understand the intention of your formula. It only seems to compress the light range at the upper end of the possible values. How can I get a steeper falloff than the original values?)

As deep says, due to the nature of hardware accelerated rendering it is not possible to balance the lighting model on ones own machine and expect those settings to be optimum for others.

But wouldn't that mean that the software renderer has the same issues with the same settings if the overall display brightness is the same?

The above formula will only work correctly (ie increases the brightness in linear ramp from low to high range) when applied to the entire range ie 0 - 255.

Thats why I'm checking with deep that the lower range clamp occurs after the compression. Logicaly I would think compression should happen first.

If you limit the lower range before compression then you will applify the wrong part of the range.

The formula should be applied to the unaltered sector light values and the range should NOT be limited.

There doesn't need to be an upper cap because as the original light level increases the altered ramp more closely matches the original so there is very little being added to the original value.

Obviously it would be a good idea to recalculate the values when light_compression_percentage changes and put the data into a lookup table.

Eg here is some sample data:

compression = 20

orig	result(approx)
8	28
16	35
32	49
64	79
128	137
160	167
192	197
240	241

compression = 40

orig	result(approx)
8	47
16	53
32	67
64	94
128	148
160	175
192	202
240	242

- the minumum allowable light level (currently 35)

Agreed. That is why Doomsday and Risen3D allow the user to set the "ambient light level" which provides the lower cap for the result of the above formula. However, you should not need a value greater than 0 as better results are obtained by increasing the light range compression factor.

DaniJ said:

deep - Does Risen3D clamp to the lower ambient light limit before or after sector light range compression? I want to make sure we do it the same way in Doomsday.

Sorry for the delay, have been out on business for a while.

Clamping is after. Other than where to put some data - we think alike - hehe.

PS: Oh - and I do the divide 1 time up front.

Graf Zahl said:

But wouldn't that mean that the software renderer has the same issues with the same settings if the overall display brightness is the same?

Apples and oranges insofar as this topic goes.

In a general way, the limited settings in ZDOOM also are flawed in not really allowing a wide enough range of the THREE methods of correcting a display.

In a nutshell, it involves more than just "brightness".

Clamping is after. Other than where to put some data - we think alike - hehe.

PS: Oh - and I do the divide 1 time up front.

Cheers.

Yeah, I noticed that after I implemented it.

I've been hoarding a good idea on how to closely emulate the Doom light fading in an OpenGL port. Seeing that I'm done with Doom, I may as well share it:

First thing: it requires splitting polygons. But you don't need split every polygon in the scene, and the split process maintains polygon edge compatibility (i.e. it doesn't introduce "gaps" caused by neighbouring edges having different start/end coordinates).

The split line (on the 2D map) is always perpendicular to the view angle, and away from the view point by a distance D. They extend to infinity. Any polygon which crosses a split line must be split, which is not trivial but not too hard either.

There are five split lines: D=0, D=+200, D=+1000, D=-200, D=-1000. You can skip the two behind the viewplane when the mlook angle is small enough (<= 45 degrees or so from the horizontal).

Let LITE(sec,dist) be the Doom lighting function, where the sector lighting and result are in the range 0-1. It's something like this:

LITE(sec,dist) = sec * 2 - 1 + 40 / dist

Compute the lighting value at the split distances:

L0 = LITE(sec,0)
L1 = LITE(sec,200)
L2 = LITE(sec,1000)

After polygons are split, they lie entirely in one of three ranges (0-200, 200-1000, 1000-infinity). For polygons in the 1000+ range, just give all their vertices a single color: L2 * white.

Polygons in the range 0-200: compute the vertex color by LINEARLY interpolating between L0 and L1 based on 2D distance of vertex to the viewplane. Similar for range 200-1000.

Because OpenGL also linearly interpolates the colors of a rendered triangle, the above method should ensure a consistent result (no mismatches between neighbouring polygons).

This method has the big advantage of not using the OpenGL FOG mechanism, which as you know always fade to solid black at some distance, making it really unsatisfactory for emulating the Doom fading. My method should work even on old cards like the Voodoo3. You can also increase the number of split lines to improve the emulation (at the expense of more splits == lower performance).