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

[Hey Doomer]

Just posted hotfix v2.81b for saved games.

v2.9b is progressing. I revised light sensor placement to see the most light & discovered many, many sensors don't see anything. Nada. Blind as a bat. (Example: curving staircase up to nukage pit in E1M2.) v2.8 corrects for this by setting minimum light level to sector color, but that prevents any true minimum light levels in the game. Regardless all sensors eat CPU cycles and impact performance. So I added light sensors as lower-level emitters, an idea I once abandoned, making idlers work.

CheckSight() missed seeing something plainly in front of it in (at least) sector 160 of E1M2. Interestingly, this was fixed by correcting the routine that eliminates markers beyond a void (does the void cause CheckSight errors?).

A major annoyance was color gradients jumping the proscenium, for example in E1M1's entrance to the large tech room (any red tint from nearby sectors with TLITE6_5 ceiling lights looked stupid with no tint between).

Code is leaner and faster (more optimization is needed). That's what I'm working through now. Most recently that sectors with different volumes and the same light level emit different amounts of light. Consider more light is needed to make a warehouse as bright as a closet; light from an open warehouse door travels farther. Maybe or duh, still testing.

Here is E1M1 with dynamic lights removed.

Release soooooooooooooooooooooooooooon.

[phantombeta]

CheckSight() missed seeing something plainly in front of it in (at least) sector 160 of E1M2. Interestingly, this was fixed by correcting the routine that eliminates markers beyond a void (does the void cause CheckSight errors?).

Are you making sure it doesn't spawn the sensors too close to a wall? The engine doesn't actually have a concept of a "void", and sectors extend infinitely in all directions until they encounter another. A sensor being on top of a line could be calculated as being "behind" it due to finite numerical precision, which can lead CheckSight to see the line as blocking it, or seeing the actor as being in a sector different from the one you meant to put it on. The latter can also cause issues due to quick rejection via the REJECT table. (Yes, GZDoom still uses it)
Speaking of the REJECT table, if the table has false rejections, that can also make CheckSight fail in cases where it seems like it shouldn't.

[Hey Doomer]

CheckSight() missed seeing something plainly in front of it in (at least) sector 160 of E1M2. Interestingly, this was fixed by correcting the routine that eliminates markers beyond a void (does the void cause CheckSight errors?).

Are you making sure it doesn't spawn the sensors too close to a wall? The engine doesn't actually have a concept of a "void", and sectors extend infinitely in all directions until they encounter another. A sensor being on top of a line could be calculated as being "behind" it due to finite numerical precision, which can lead CheckSight to see the line as blocking it, or seeing the actor as being in a sector different from the one you meant to put it on. The latter can also cause issues due to quick rejection via the REJECT table. (Yes, GZDoom still uses it)
Speaking of the REJECT table, if the table has false rejections, that can also make CheckSight fail in cases where it seems like it shouldn't.

Good to know. Yes, all actors spawn off sector lines. I noticed this problem a few versions back.

In this case CheckSight worked correctly once I excluded markers from the list located in sectors across voids. Perhaps, I missed something obvious.

[UTNerd24]

So this whole "Eye Adjusting" feature... Is that meant to be a Faux-HDR effect? If so, that's some fascinating engine trickery. Although I must admit, when I first saw it, I thought you had implemented stealth mechanics into Doom.
One question though. Will this conflict with "Universal Enhanced AI"? That mod works by making you harder to see in dark sectors.

[Ozymades]

Cool, the hotfix fixed my problem with the save games.
Keep up the good work. It's an amazing mod you are creating here.

[Hey Doomer]

So this whole "Eye Adjusting" feature... Is that meant to be a Faux-HDR effect? If so, that's some fascinating engine trickery. Although I must admit, when I first saw it, I thought you had implemented stealth mechanics into Doom.
One question though. Will this conflict with "Universal Enhanced AI"? That mod works by making you harder to see in dark sectors.

The eye adjusting isn't that far off from HDR. Human vision has an unusually high dynamic range, which accounts in part for our pupillary light reflex that makes your iris contract or dilate in response to different light levels. This explains why, for example, walking into a suddenly bright room hurts your eyes or walking indoors from bright sunlight makes everything look darker than it is. It's the latter that Relighting attempts to simulate.

This mod shouldn't affect Universal Enhanced AI.

[Hey Doomer]

Still working on 2.9. I found some problems with light sensor placement that I'm working through. Intuitively a sensor should see all available light using Doom's crude sector lighting. After a lot of testing I've decided to attach a light sensor wherever it can see the most light; I may also place light sensors on doors. It's proving difficult to find any kind of consistent compromise between the two.

Just detail trawling as time permits. It's a matter of optimal sensor placement and then interpreting what it sees. (The reason I abandoned using light sensors as sources previously is because it tends to make everything full brightness.) I'll have something soon. Not sure when, but I am working on this.

[eviltechno]

Always looking if theres a new update btw, any recommended mapsets were relighting shines best?

[Hey Doomer]

Always looking if theres a new update btw, any recommended mapsets were relighting shines best?

Thanks! I haven't really looked at other mapsets.

[Hey Doomer]

Quick update. Great fun of course, but this is taking a crazy amount of time in my quest to perfect vanilla sector lighting.

Here's E1M1 with some stats that include the current light level, number of markers in the current loop, sensors and bright lights seen. The sensor in this case is to the right by the hidden door (I tried and abandoned dedicated door sensors).

As a WIP it's difficult to show more, but here's a good example of improved gradients from MAP01.

In the large room (69)
Step 1 (112)
Step 2 (130)
Step 3 (147)
Step 4(163)
Step 5 (181)

As you can see, light is gathered from bright light sources (the lit hallway) first but can also be gathered from sensors. The latter involves simple floating point division I haven't yet optimized; sensors, note, are in dark sectors with dynamic light levels so a gradient is calculated ad hoc.

During testing I found light glitches when I removed color and clamping in core routines. Some sectors had insanely high light levels (interesting in itself, but it is an int16) I hadn't seen because of clamping. Fun stuff like that.

I appreciate the patience, and I will have a release soon. Thanks!

[Hey Doomer]

What's done:

• Vanilla lighting redone and simplified adjusted for emitting and receiving sector volumes
• Sector coloring redone and simplified adjusted for temperature
• Light sensors now detect baked gradients / colors from BrightActors or closest LightSensor.

Remaining problems with sector lighting include detecting sectors between an emitter and receiver and grouping sectors meant to be the same light source (E1M2 has examples of both). I'm not sure it's possible to resolve these given the irregular nature of Doom map design. I've also tested and chucked anything that doesn't work well. All that's left is fog and dynamic lights before the next release.

Screenshots (default settings, Software sector lighting, no added dynamic lights or fog):

E1M3
MAP01
E1M7
E2M5
MAP06
E1M1

Note that colored lighting and other elements are less overbearing. I've tried to bias toward darkness while correcting "emitters" for sector volumes after some trial and error. Colored sectors bleed into adjacent sectors and otherwise emit temperature midtones, if that makes sense. So far that seems like an OK compromise but still testing.

[Hey Doomer]

Another update: revisiting vanilla lighting (because sector lighting sucks). The game was simply too dark in too many places, and adding intermediate "bright" sectors defeats the whole idea. I've again rewritten the sensor code (eliminating around 200 lines of code), increased the number of bright actors (more light to be seen), optimally placed sensors to see the most light after calculating gradients for each point, and accounted for lighting specials to improve this.

Example: E2M1 - note the extra bright markers (does not impact performance but obviously adds more "light")

Example: E1M2 - note staircase gradients and varying placement of sensors

Example: E1M4 - more stairs.

Previous code placed sensors according simple rules of thumb that cause frustratingly dark areas impossible to resolve without fudge. Currently using a brute force approach of stepping floor to ceiling through a sector on each two-sided line, calculating total amount of light seen after applying gradient calculations, and choosing where most light is seen. This slightly increases load time for large levels but otherwise doesn't impact performance. If anything once optimized I expect performance to improve compared to the current release. It has the effect of improving lighting as you can imagine.

Easy really. Anyhoo...

[Plasmazippo]

Have I already given you massive kudos for your extra hard work on this mod, HD? Because even if I did, it's worth repeating.

[Hey Doomer]

Have I already given you massive kudos for your extra hard work on this mod, HD? Because even if I did, it's worth repeating.

Thanks! I appreciate the support!

[Hey Doomer]

v2.9b is very close to a release.

One of the vexing simplifications of sector lighting is its all-or-nothing nature. Large and small areas are lit equally when a door opens and light is received e.g. the door to the outdoor nukage pit in E1M5. Another irritating sector to resolve is 29 in E1M1, the angled corridor leading to the large tech room at start adjacent to both light and darkness.

E1M1
E1M7

While the above don't look much different the applied theory is. Minimum and found light are adjusted by several variables: the amount of light that could be collected (ambient light); the amount of light directly adjacent to a sector; sector height rather than volume; sector "openness" (a qualified ratio of two- to one-sided lines). setLight() finds the first bright actor or uses the previous actor if the new one is darker, calculates a gradient based on the current light of that sector adjusted for lighting specials, and adds that to the minimum light.

This means, for example, that the "gotcha" room where the blue key is found in E1M3 now works without fudge.

All of which makes as much sense as Washington's foreign policy, but it at least accounts for differences in size and shape. Also fixed a few long-standing bugs such as accounting for flipped lines in some sectors. Overall an interesting and fun problem. Thanks to all for support and interest in this project.

v2.9b should be released soooooooooooooooooooooooooon.