Software renderer's lighting in GZDoom (and Zandronum)

[Korshun]

Hello, it may seem strange to make this my first post. The secret is that I have been dooming for 4 years and wansn't here because of laziness, etc... whatever...

Ever since discovering GZDoom, I was disappointed with its lighting. It doesn't bright up close areas, far areas looks uniform and contrastless and too dark compared to software renderer, making maps look dull. And no configuration in GZDoom can fix that (except making everything fullbright, heh). Yet OpenGL renderer is better than software renderer at everything else. I had to choose between "good lighting" and "good everything else but bad lighting". But now I don't have to!

I have modified GZDoom's OpenGL renderer to have lighting exactly like in software renderer! Big thanks to EDGE developers for actually caring about lighting and providing a ready-to-use doom lighting formula.

---

I have simply stuck EDGE's doom lighting into the main fragment shader of GZDoom and picked some constants to correct the depth to what EDGE's formula expects. Then I modified GZDoom to pass light level as a separate attribute instead of premultipying them on CPU. Code quality is low, I just hacked it till it works plus some other needed tweaks like removing any default fog from the levels.

There's a problem with sprites lit by dynamic lights because everything is white by default so dynamic lights actually darken the sprites. For now when a simply passing fullbright light level and premultipying the color on CPU if a sprite is lit by a dynamic light seems good enough but the best solution (not implemented because of my lack of knowledge of GZDoom codebase) would be to apply EDGE's formula on CPU and then light the sprites with as usual but with new light level.

WARNING: needs good OpenGL shader support to work.

Official page with screenshots and downloads:
http://submarine.homeunix7.org/doku.php ... _in_opengl

Download links:


Zandronum Windows
Zandronum Source code
(linux binaries coming soon, they are not made by me but by Monsterovich)

GZDoom downloads (obsolete, it is added to GZDoom 1.7.0 ):
GZDoom Windows
GZDoom Linux
GZDoom Source code

---

Just use it like ordinary GZDoom/Zandronum. You may import your normal GZDoom/Zandronum config but be sure to set ambient light level to 0 for best results. If you want blocky lighting like in software renderer, rename gzdoom-blocky.pk3 to gzdoom.pk3 (or in case of zandronum: zandronum-blocky.pk3 to zandronum.pk3).

There are two extra unrelated features accessible through Options -> Display Options -> OpenGL Options -> Preferences:

Smooth lines on automap (not available in Zandronum) - eables some kind of ugly OpenGL line smoothing made in 5 minutes.
Foggy sectors are fullbright - meant to make foggy maps look better. In software renderer fog density is light level and all sectors just have black fog by default. If fog is colored, the foggy sector seems fullbright. This option is supposed to make some foggy maps (for example: Darkmere from Hexen) look good like in software renderer without cranking up ambient light level to 255. Warning: semi-black fog looks really bad with this option so turn it on based on what you're playing.

Also, I have fixed the bug with lines on textured automap being drawn one pixel off compared to textured polygons. Guess I should have reported it .

Version list (using totally internal and unrelated versioning scheme):

Zandronum V2.4:

• Fixed liteamp not affecting sprites.

Zandronum V2.3: first released version.

GZDoom V2.4:

• Lighting was not bright enough, fixed that, now light bands in blocky mode match the ones in software renderer .
• Fixed weapons not getting brighter when firing.
• Fixed objects becoming pitch-black when the camera is too close.

GZDoom V2.3: first released version.

[Gez]

This looks interesting; however aren't there license issues with that? Did you clear it with Andrew Apted? EDGE is a GPL port and GZDoom contains code under licenses legally incompatible with the GPL.

[Blox]

Screenies for the lazy (The quality is messed up, but we're talking about general lighting so it's OK.)

But yeah, this definitely looks interesting.

[SFJake]

My my, I would LOVE if this was part of GZDoom officially (and properly)

I always wanted this, but figured it just was not (easily) possible.

[BouncyTEM]

The possible licensing issues on this concern me, but I really, really love that it's been done.
Nice first post, sir, though I do feel we might need a clean-room reverse engineering via Gez + Blzut3 or something.

[ibm5155]

isn´t the same as normal opengl render with doom fog and not dark fog?

[Gez]

So the EDGE code apparently is only in the shader code itself (main.fp), not in the C++ code. That means it doesn't get in gzdoom.exe, but in gzdoom.pk3. It probably doesn't change anything on the licensing point, though.

However, it seems said code is ultimately derived from the Doom utilities formula to generate the COLORMAP.


As for the C++ code, it does feature some problems, mostly enforcing this lighting mode by disabling all others, regardless of user and map settings. This is not acceptable in GZDoom itself. Do keep in mind that some levels have actually been designed for GZDoom rather than vanilla, and require a lighting mode other than "Doom".

[BouncyTEM]

Also worth noting this instantly crashes Gzdoom if you use the R_Visibility console command. Not good.

[Nash]

Looks close... but it's still not 1:1. Good job though! Would love to see the software lighting banding recreated in OpenGL.

[Korshun]

So the EDGE code apparently is only in the shader code itself (main.fp), not in the C++ code.

Actually there's a small bit that changes hud weapon's light level so it is like in software renderer. Also rendering of sprites lit by dynamic lights should use software light calculation for best results. BTW: how do I get distance from camera to currently rendered sprite?

As for the C++ code, it does feature some problems, mostly enforcing this lighting mode by disabling all others, regardless of user and map settings.

I didn't know how to recompile shaders on lightmode change . As for general dirtiness, I just wanted it to work ASAP.

isn´t the same as normal opengl render with doom fog and not dark fog?

No. It's impossible to recreate software renderer's lighting using GZDoom's options.

Also worth noting this instantly crashes Gzdoom if you use the R_Visibility console command. Not good.

Wait... what? r_visibility worked in OpenGL? I thought it only affects software renderer... *checks*
Vanilla GZDoom 1.5.6: nothing happens.
Vanilla GZDoom 1.6.0: crash.
Modified GZDoom 1.6.0: crash.

Looks like it is not my fault but my fault is that I don't know how to make r_visibility behave like in software rendeder. But if anything is too dark, you still have OpenGL renderer's ambient light level.

Looks close... but it's still not 1:1. Good job though! Would love to see the software lighting banding recreated in OpenGL.

Just replace gzdoom.pk3 with gzdoom-blocky.pk3.

[Gez]

You should have based your code on the latest SVN and you wouldn't get the r_visibility crash. I fixed that bug back in July.

[Enjay]

This does actually look very nice. I hope things can be cleaned up so that it can be added to GZDoom proper. I really don't like the "blocky" version though. That's one of the things that I am happy to leave in the past.

[Nash]

The "blocky" option should be built into the game and switchable in-game somehow, as opposed to using a separate base PK3. I wonder if it's possible to switch between the 2 different fragment shaders while the game is running?

Anyway, just tried it in-game running around the vanilla levels. Nice stuff! Keep it up. :D The experience of running around with banding in an OpenGL renderer is surreal. Considering it has been said so many times in the past that it was "impossible". :O

Would love to see this merged into GZDoom officially.

(And yeah you should be working off the trunk on the SVN :D)

[shoober]

Screenies for the lazy (The quality is messed up, but we're talking about general lighting so it's OK.)

Based on those screenshots, I think i'll stick with the software render. You can still tell that software mode renders lightning in its own special way that OpenGL just can't emulate. Nice effort though. Maybe it in the future it will be closer.

I went through the same dilemma when I was choosing between ZDoom and GZDoom, but I went with ZDoom because its a more authentic experience visually.

[Korshun]

A small update

• Lighting was not bright enough, fixed that, now light bands in blocky mode match the ones in software renderer .
• Fixed weapons not getting brighter when firing.
• Fixed objects becoming pitch-black when the camera is too close.

I really don't like the "blocky" version though. That's one of the things that I am happy to leave in the past.

Same .

The "blocky" option should be built into the game and switchable in-game somehow, as opposed to using a separate base PK3. I wonder if it's possible to switch between the 2 different fragment shaders while the game is running?

100% sure it is. I just don't know GZDoom's code well enough and I all want is to play with software lighting in OpenGL. Of course, the proper way would be to make 2 new lightmodes, etc... For now it is okay for me to keep both GZDooms.

Based on those screenshots, I think i'll stick with the software render. You can still tell that software mode renders lightning in its own special way that OpenGL just can't emulate. Nice effort though. Maybe it in the future it will be closer.

What exactly are you talking about? I still see nothing in software lighting what can't be emulated in OpenGL. Also, the previous version was not bright enough. Try it out again. Gotta retake screenshots...