Relighting Doom v3.31b [Updated 4/8/22]

[Hey Doomer]

The difference between dynamic lighting and sector lighting is that sector lighting isn't. But what if it was? What if sectors changed light depending on light sources? What if a sector got brighter when a door opened and dark again when it closed?

This is my take, called Re light ing. This relights the entire game based only on flats and textures configured in text lumps to be light sources. The farther away from a light source, the darker the sector. The gloomier the surroundings, the gloomier the sector. Sector lighting increases or decreases dynamically. Outside light streams in through windows. Floors are reflective. Pupillary light reflex is simulated, allowing player eyesight to adapt to darkness as needed.

Here it is compared to vanilla Doom:

---

E1M5 before and after Relighting.

e1m5.gif

E2M1 before and after Relighting.

e2m1.gif

Definition file example:

Code: Select all

; yellow
CEIL3_4,#ffff00
CEIL4_3,#ffff00
TLITE6_1,#ffff00
TLITE6_4,#ffff00
TLITE6_6,#ffff00

Settings control options to adjust the maximum light, "lost" light when a bright sector bleeds into another, minimum light, any added light (a fudge factor in case dark is just too dark), and the color strength. I have configured this for Doom, but this will work with Heretic or Hexen as well. Just edit the text lumps.

Notes:

• This works best with texture brightmaps. I've included a few additional maps.
• Sector lighting specials aren't changed and should work well with Relighting. Any sector based shading is relit from scratch.
• Five text lumps control lights: rl_flats, rl_textures, rl_gldefs, rl_fog, rl_liquids. A sixth controls reflections.
• Map-specific colors will override Relighting definitions.

Changelog: (revised with v3.0b)

---

Code: Select all

changelog
3/31/22 - v2.9b
4/1/22  - added rl_spinners.txt, spinning spotlight
            - tweaked luminosity in shader
4/2/22  - hotfix for null pointer in relighting_actors.zs
4/3/22  - fixed animated ceiling glows (v3.0b)
            - added missile flashes (v3.1b)
4/4/22  - added distance optimization to liquid light actor, randomized
             - added double stacking for strip lights
4/5/22  - added check for fist in missile flash (v3.2b)
4/7/22  - added decoration shadow casting, optional player missile flash (v3.3b)
             - added rl_weapons for player missile flash colors
	     - added default if weapon has ammo and is not defined
	     - corrected Missile/Melee check state for weapon flash (v3.31b)

Credits:

---

1/22/22 phantombeta - optimized lighting code, caching cvars

Now at v3.31b

Many Thanks to phantombeta for taking time and energy to optimize the light code! Brilliant stuff.

[Kzer-Za]

Very cool!

For me personally the colored lights seem too colored, I would have preferred them less tinted, but that's just me

[Hey Doomer]

Very cool!

For me personally the colored lights seem too colored, I would have preferred them less tinted, but that's just me

In Settings "Sector Color Strength" (now that I think about it, that should be called something else as it does the opposite) affects color intensity by averaging this value across all three channels. If there are multiple colors in the same sector they are averaged, which may have a similar effect.

Example of "washed out" color:

Screenshot_Doom_20220112_052738-576x324.png

Thus if this value is 255, bright sectors are not colored at all.

I also chose to copy names from Doom Builder with an approach of "red light? #ff0000," if that makes sense. One person's pink is another person's crimson, and it's trivial to change.

[Kzer-Za]

Oh, great!

[FelesNoctis]

This looks awesome!

Out of curiosity, have you gotten to a point of testing how it works in combination with something like DarkDoomZ? Sounds like both mods have minimum/maximum light level checks, so I'm wondering how they'd interact.

[Hey Doomer]

This looks awesome!

Out of curiosity, have you gotten to a point of testing how it works in combination with something like DarkDoomZ? Sounds like both mods have minimum/maximum light level checks, so I'm wondering how they'd interact.

I haven't, but I assume this will ignore whatever DarkDoomZ or a similar mod does. All sector lighting is changed so that a sector is either a light source or contains light sensors that determine the light level in real time. Setting light levels on level load will have no effect on this.

[Hey Doomer]

If you've every been in bright sunlight and then walked into an indoor location without lights on, you understand the pupillary light reflex. It's also the thing your physician does where a brilliant light is shined in one eye and then the other.

I have added this to Relighting. Here's what it looks like in action:

---

Screenshot_Doom_20220113_061124-576x324.png

Screenshot_Doom_20220113_061129-576x324.png

Screenshot_Doom_20220113_061133-576x324.png

These are from E1M2. In the first screenshot the player stands under ceiling lights (a bright sector). Ahead he sees darkness. The second screenshot is after walking into the darkness, and it is suddenly much darker. That's because the bright sector constricted his pupils. As time passes (see Settings) pupils dilate and the sector gradually brightens.

This should not affect gradual changes, such as the tunnel in E1M1 walking up the stairs into the courtyard. The idea is that standing in the light carries an added risk, and it also makes the sector dynamic lighting more responsive to the player. The PLR trigger is determined by the "Lost Sector Light" setting to allow for incremental change. The most dramatic reflex will be seen in going directly from a light source sector into a very dark sector; moving gradually into darkness shouldn't trigger the reflex.

I think this looks pretty cool, but if you don't want this just set Pupillary Light Reflex Time to 0.

[Hey Doomer]

Posted v1.1, which fixes a few minor bugs related to PLR calculations. v1.0 was triggering too soon and the reflex was based on the default values. Other than that no real substantive changes. Also note that dynamic lights are excluded from PLR. So if a sector is "artificially" brightened with dynamic lights it doesn't affect PLR.

Update: v1.15, a minor bug fix with PLR. I've definitely been looking at this for too long today.

[Armaetus]

I like this concept, shall you wanna go for the semi-realistic gameplay mechanic.

[Hey Doomer]

Attached is version 2.0b of Relighting that contains numerous small bug fixes and two new features:

• Optimized light sensor performance (see below explanation).
• Small bug fixes throughout.
• Optional bright sector fog to highlight those sectors. Doom is a dusty, dank environment, and light highlights whatever is floating in the air.
• Optional HUD PLR icon that shows when pupils are constricted or dilated.

Here's what it looks like in action:

---

Screenshot_Doom_20220114_062631-576x324.png

Screenshot_Doom_20220114_062640-576x324.png

As the player enters a bright sector a normal pupil appears; after the PLR response time a constricted pupil appears, indicating the player's eyes will need to adjust to darkness. I have made some adjustments so that darker sectors appear proportionally darker when that happens.

However, note that this dynamic lux factor is global for all light sensors, so you may see some weird things. For example, in the middle of courtyard tunnel in E1M1 there is a bright sector that triggers a PLR. If you go forward into one or the other side the sector darkens, and if you turn around you'll see the other sector looks darker as well. Generally this works, but as a global setting this is far from perfect.

This version should be more performance friendly as well. The light sensors work by using CheckProximity in a widening range to see what light sources are seen. I've calculated these in advance in a PostBeginPlay() function for each sensor. This eliminates a large number of CheckProximity calls, especially in indoor areas.

An observation: Doom is a dark game, and I've never noticed how few light sources exist until now. Many areas have no light sources at all in terms of textures or windows and in the real world would be darker than the inside of a cow. Likely I seldom thought of where light was coming from in areas with no visible lighting, but this does have a significant effect on the character of some maps. Hopefully this mod makes lighting consistently logical, although it makes me wonder how areas function when the base isn't wrecked and overrun with monsters and functioning normally. Are workers all walking around with headlamps?

[Enjay]

I tried the previous version last night and was going to report quite heavy performance issues even on Doom2 default maps. So here's hoping the new optimisations help with that. I'll check when I get home from work.

You are right about the visible light source texture/flat/item thing. I hadn't noticed how extreme this is myself myself until I decided to try converting a few maps to use dynamic lights and realised that many rooms have no obvious light source whatsoever and, therefore, no logical place to put a light object.

[Hey Doomer]

I tried the previous version last night and was going to report quite heavy performance issues even on Doom2 default maps. So here's hoping the new optimisations help with that. I'll check when I get home from work.

You are right about the visible light source texture/flat/item thing. I hadn't noticed how extreme this is myself myself until I decided to try converting a few maps to use dynamic lights and realised that many rooms have no obvious light source whatsoever and, therefore, no logical place to put a light object.

Hopefully this version is performance friendly. It seems to be.

I'm working on another optimization (probably be done tomorrow) that will combine light sensors that share sectors. That should also help improve performance.

[Enjay]

Performance is better, but still noticeably affected. However, (as it was last night) the effect is weird. It definitely feels slower; like a lower FPS. The thing is, it feels less like a normal lower FPS and more like a micro-pause every tic or so - like the gameplay is jerky in a very, very small faltering way. Screen updates seem normal - the delay is somewhere else.

To back this up, FPS is also weird. I run with vsync on and normally get 60fps (i.e. capped ay my monitor refresh rate). With relighting.pk3 loaded, I get 65 FPS!

With vsync off, I get a solid 200fps running around in Doom2 map01 (which I think is an internal cap). With relighting.pk3 loaded, FPS sits around 165 but the feel of the slowdowns is much more obvious - more so than it is with vsync on.

Weird.

All the above was with Vulkan and the latest nVidia drivers (511.23 updated today).

[Hey Doomer]

Performance is better, but still noticeably affected. However, (as it was last night) the effect is weird. It definitely feels slower; like a lower FPS. The thing is, it feels less like a normal lower FPS and more like a micro-pause every tic or so - like the gameplay is jerky in a very, very small faltering way. Screen updates seem normal - the delay is somewhere else.

To back this up, FPS is also weird. I run with vsync on and normally get 60fps (i.e. capped ay my monitor refresh rate). With relighting.pk3 loaded, I get 65 FPS!

With vsync off, I get a solid 200fps running around in Doom2 map01 (which I think is an internal cap). With relighting.pk3 loaded, FPS sits around 165 but the feel of the slowdowns is much more obvious - more so than it is with vsync on.

Weird.

All the above was with Vulkan and the latest nVidia drivers (511.23 updated today).

All very interesting! Thanks for the update. I've noticed some of the "faltering," although I haven't seen the FPS anomalies that you describe. The light sensors only adjust color if the player is within proximity, but that means calling a CheckProximity. I wonder if that's where the problem is. I may try something else. I have been able to eliminate duplicate sensors on the same line, which was another significant performance hit. I may have to reduce those further.

Still working on it.

Update: I think the issue is just too many calls to CheckProximity. I've experimented with a few things, and it seems much better with a longer delay between polling light sources. I don't see as much micro-stuttering with weapon sway. It's subtle but noticeable. I can work on this with a direction, and it may be possible to further reduce light sensors. I discovered another anomaly with these sensors: as the player approached they would drop. I set +NOINTERACTION, which eliminated that. Little stuff like that probably doesn't help performance.

Also, sectors beyond a certain radius don't adjust at all, but that means they all do at least one distance check to the player. It seems about the same with Distance2D and CheckProximity, although I feel the former is probably faster.

Still working on it. Making some progress.

Update:

So I don't load up on screenshots, here is some progress in just reducing the number of light sensors:

https://i.postimg.cc/RCj2LKQt/Screensho ... 174030.png
https://i.postimg.cc/LXNSCXDP/Screensho ... 172756.png

So, which screenshot is vanilla Doom, and which is Relighting?

I'm seeing better performance, and while the game is somewhat darker it looks better. Reducing the number of light sensors seems to improve performance. The number of sensors vs. sources is not proportional, so it may be a matter of finding just the right ratio.

Anyway, I'll keep playing with it. I don't know how interesting this stuff is to people, but for me the idea of completely relighting a 30-year old game based on the map author's design instincts is fascinating stuff. I'm amazed it can be done at all. While I may end up abandoning this for performance reasons, I am seeing improvement and should have something to post tomorrow for the curious. Thanks Enjay!

[thugsta]

Any chance of a LZDoom release as well?

It seems only function that is unknown is:-
flat[0].StripRight();
flat[1].StripRight();
text[0].StripRight();
text[1].StripRight();