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

[Hey Doomer]

This is running on GZ.

How do i check the cvar rl_tid? turning on debug?

You can just type it in the console. I've made rl_reflections default to false for now and uploaded this version as 2.321b. Let me know if that works.

I figure out what was wrong, You did a typo as the command was not working in console. You added an s to the cvarinfo file. It is running now. Should be user string rl_tid

Great! I just figured that out myself. Jeesh.

Update: fixed.

[Enjay]

The new version looks very pretty. The coloured light works well.

Performance is still a problem for me though. Approximately once every second or so, there is a noticeable momentary slowdown (even on simple Doom2 maps). Between these "hiccups" performance is fine. I guess that a calculation of some sort is being performed once per second?

[Hey Doomer]

The new version looks very pretty. The coloured light works well.

Performance is still a problem for me though. Approximately once every second or so, there is a noticeable momentary slowdown (even on simple Doom2 maps). Between these "hiccups" performance is fine. I guess that a calculation of some sort is being performed once per second?

After quite a bit of testing I believe I know what the problem is. It's not a single calculation so much as competing calculations in sectors with multiple light sensors. I'll have to completely rewrite the placement of markers and sensors, which I should do anyway with gradients of lights and dynamic lights added. (Originally all this was much simpler.) This may be less accurate depending on the map but should not have these performance issue. Should not take long!

Thanks for looking at this, everyone. I appreciate it!

[SLON]

There aren't many reflective surfaces in the game - mostly fluids and perhaps metal floors like the above - but they add to lighting as can be seen in this example. The lump is similar to others with reflection amount substituted for color. Coming for the next release...

Marble is also quite reflective, I think.

[BROS_ETT_311]

The effect from this is simply amazing! Never seen reflections handled on this scale before and only in a handful of maps. I will say there is certainly a performance hit on wads like Project ReMap, though I suppose that's to be expected given the size of those maps. Either way, I'm loving the direction of this. Any plans to expand compatibility with other IWADS?

[Hey Doomer]

There aren't many reflective surfaces in the game - mostly fluids and perhaps metal floors like the above - but they add to lighting as can be seen in this example. The lump is similar to others with reflection amount substituted for color. Coming for the next release...

Marble is also quite reflective, I think.

Yep. Added already!

Code: Select all

DEM1_5,15
DEM1_6,15

[Hey Doomer]

The effect from this is simply amazing! Never seen reflections handled on this scale before and only in a handful of maps. I will say there is certainly a performance hit on wads like Project ReMap, though I suppose that's to be expected given the size of those maps. Either way, I'm loving the direction of this. Any plans to expand compatibility with other IWADS?

Thanks, it are some pretty.

I honestly haven't thought about compatibility with other wads, but that's certainly possible. Expansion can be handled a few ways:

Any number of textures can be added to text lumps in the main mod zip. There is no error checking to see if these exist in the current map. Currently I've added definitions for Doom, Doom 2, TNT, and Plutonia, as well as a few brightmaps that seem to be missing. It's possible to add Heretic, etc.

The other possibility, which may be more interesting, to to add definition lumps in a separate zip loaded before Relighting. That's also possible, since the mod finds the first lumps in the global namespace. For example, if you don't prefer my choice for a few colors or outside lighting, copy and paste rl_flats.txt, rl_textures.txt, rl_reflections.txt, or rl_gldefs.txt into a separate pk3 file, change whatever you want, and load this before Relighting. The mod should choose those definitions. I haven't tested this, but that was my intent in writing this.

A map designer can also choose add those lumps to a mod and if Relighting is loaded after the mod it will reference those lumps, otherwise it's lighting as usual. Again the mod designer should be able to add just rl_reflections.txt, etc. The mod shouldn't read all lumps so named, only the first.

[Hey Doomer]

I've scrapped the old light code. The new code places BrightLights and LightSensors based on two-sided lines and back sector lighting. A lot less messy and just simpler all around - all the sensor placement exception coding is gone. The mod first looks at floor, ceiling, and wall textures for brightness, adds dynamic lights, decides how bright the sector should be and then adds either 1-3 BrightLight OR one LightSensor (if it isn't bright) to the sector. The performance seems snappier, although I haven't tested extensively. It should be better, since each sector has only one LightSensor. All the previous CPU chewing is gone.

While this has made the game somewhat gloomier so far, sector dynamic lighting still works as intended and dynamic lights work better to sometimes dramatic effect. Examples:

https://i.postimg.cc/hGjqH0Bg/Screensho ... 052320.png

https://i.postimg.cc/T2NjvVW0/Screensho ... 054909.png

Same definitions as before, just refactored lighting code. Ain't that something. Still tweaking this and should have another beta release in the next day or so!

Update: I have been testing randomly here and there as time permits. Looks like there are still a few performance issues in complex maps, which is understandable. Otherwise it's OK. Working on optimizing placement, since there are a few duplicate sensors on lines that can share sectors.

[SLON]

The effect from this is simply amazing! Never seen reflections handled on this scale before and only in a handful of maps. I will say there is certainly a performance hit on wads like Project ReMap, though I suppose that's to be expected given the size of those maps. Either way, I'm loving the direction of this. Any plans to expand compatibility with other IWADS?

Incident light now looks surprisingly believable.

And yes, on any more or less detailed wads, such as Hellfire (Boom), it slows down.

[Enjay]

I don't know how much use this is, but I thought I'd record a video of the performance hiccups that I was talking about. Please ignore the crappy playing, I was concentrating more on trying to show the performance problem.

Like I said, I don't know how useful this is, or even how obvious it will be if you aren't actually playing. I used the inbuilt video-capture of my graphics card and, as a result, there is little to no performance deterioration due to grabbing the video (at least none that I could detect). The game plays just like this when not capturing video. Every time you see a momentary pause in running or any other visuals, that's what I am talking about.


You can see that I actually overshoot the switch near the start because of one of the hiccups.

relighting v2.321b.pk3
Windows 10 Pro 64 bit
Intel Core i7 6800K @ 3.40GHz
32.0GB RAM
NVIDIA GeForce RTX 2060
Game installed on an SSD.

[Hey Doomer]

I don't know how much use this is, but I thought I'd record a video of the performance hiccups that I was talking about. Please ignore the crappy playing, I was concentrating more on trying to show the performance problem.

Like I said, I don't know how useful this is, or even how obvious it will be if you aren't actually playing. I used the inbuilt video-capture of my graphics card and, as a result, there is little to no performance deterioration due to grabbing the video (at least none that I could detect). The game plays just like this when not capturing video. Every time you see a momentary pause in running or any other visuals, that's what I am talking about.

Thanks for doing this. I only noticed this to a far smaller extent after looking for it after you described it. Even then I may not have noticed it in many maps. I haven't experienced anything like this video, so good information. I think what we're seeing is CPU gnashing from multiple sensors in sectors, but that's just a theory after investigating this and trying a half dozen ideas to improve it. One sensor per sector seems to eliminate all of this. Indeed I think sharing sectors is too complex. But I'm still working at it. Thanks again, I appreciate it. I think you'll notice a significant improvement with the next version.

[kalensar]

This seems like an amazing idea BUT this is causing some massive stuttering on my rig, and I have no idea why. Messed with the settings and turned all the relevant ones down to minimal or off, like fog off, and still got the stuttering. I'm clueless on how to even troubleshoot this.

[Time_Streamer]

Yup. Just to say I have the exact same problem with performance. The video posted by Enjay shows the issue very well. I play with V-Sync off with the game capped at 120 fps. My frames go from 120 solid, to 80ish but the experience I get is a total freeze every second or so. Smaller levels can be played with no problems at all (like the first level of Doom 2). The issue only manifests itself at larger (complex?) maps. Perhaps related with the amount of light sources?

Anyway, I love the mod. Hope you can find whats causing the issue.

[Hey Doomer]

Yup. Just to say I have the exact same problem with performance. The video posted by Enjay shows the issue very well. I play with V-Sync off with the game capped at 120 fps. My frames go from 120 solid, to 80ish but the experience I get is a total freeze every second or so. Smaller levels can be played with no problems at all (like the first level of Doom 2). The issue only manifests itself at larger (complex?) maps. Perhaps related with the amount of light sources?

Anyway, I love the mod. Hope you can find whats causing the issue.

Honestly I haven't see this issue on my machine to this degree or I would not have posted this. This new version seems much faster to me, but we'll see I guess.

[Hey Doomer]

I've posted v2.33b with updated lighting code. Placement has been revised based on simpler criteria, and light sensors are generally a little higher to perceive more light.

Screenshots:

https://i.postimg.cc/wvrX2fjr/Screensho ... 104033.png
https://i.postimg.cc/8crh0RFz/Screensho ... 104100.png
https://i.postimg.cc/PNsmsCZz/Screensho ... 105153.png
https://i.postimg.cc/QMMk74LR/Screensho ... 105710.png

This is pretty much the same code with different placement algorithms favoring brighter back sectors and higher sensor positions. Amazing difference although certainly not without glitches. Some areas are darker, some lighter, but this seems more natural to me. The bottom screenshot seems to make sense given there are two windows throwing light into the staircase. I almost didn't believe it when I first saw it. Then there are other areas that seem less natural, but overall this version seems better.

I've refactored this monitoring performance. What I've perceived capped at 120 fps is a slight drop of 1-2 fps with barely noticeable stuttering. If there are many small sectors as at the beginning of E1M2 I see fps as low as 111. Without Relighting I've noted similar performance in GZDoom depending on where I'm moving through a map. With Relighting I don't see anything like the performance Enjay posted, but that all depends. This version seems snappy by comparison to me, although there's a performance hit. Script calls periodically spike two- or threefold depending on map complexity. I haven't found light sources beyond sensor detection with my current definitions, hoping I might eliminate some completely, but I have noticed a bigger performance hit with more light source markers per sector. This version also reduces light source markers based on sector size. I suspect that performance can be improved further by using fewer markers and more dynamic lighting, which seems to have far less performance impact than ZScript calls. ZScript is just slow. If you type "stat vm" in the console you can see these calls regularly spike as Relighting does its thing.

Your mileage may vary, but I find this version quite playable and better looking.

However, I've added three settings that specifically target sensor performance you'll find on a submenu of "Light Settings" called "Light Performance Settings."

• Light Distance - limit to trigger CheckProximity for light
• Pause Distance - limit to put the sensors on pause
• Dormant Distance - limit to put the sensors in a "dormant" state (like Pause but longer)

Depending on these settings, light sensors will be more or less responsive, with lower settings generally improving performance. I've set defaults pretty low, so feel free to experiment. I'm still looking at these settings and how to take advantage of them.

A note on these distances: these are rough estimates within a bounding box assuming that simple subtraction is much faster than Distance2D function. That may not be true given ZScript's pokey speed, but that's my working theory. I suspect accuracy in this case is a negative tradeoff. The point is to pause more frequent CheckProximity calls, and I've eliminated one intermediate distance check (1024) without any apparent degradation in incident lighting. I'll keep looking at this. Let me know how this version works!