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

[mamaluigisbagel]

Tried replacing the code, and I can save the game successfully now. Though after a bit, I got this crash during gameplay.

[Hey Doomer]

Tried the newest version and noticed any time I try to save the game with this mod loaded, the save fails with this message.

Attempt to save pointer to unhandled type NativeStruct<CVar>

Oops, guess I forgot to make the CVar variables transient when I made my optimizations.

Oh thanks!! I noticed that, hadn't gotten around to investigating it. Makes sense.

[phantombeta]

Tried replacing the code, and I can save the game successfully now. Though after a bit, I got this crash during gameplay.

Sounds like a light is getting deleted mid-game. If this is intentional, this can be fixed by replacing LightSensor's Tick override with this:

---

Code: Select all

override void tick()
	{
		for (int i = brightLights.size() - 1; i >= 0; i--)
		{
			if (!brightLights[i])
				brightLights.delete(i);
		}

		// freed itself
		if (!checkNoDelay())
			return;

		// Advance the state
		if (tics != -1)
		{
			if (tics > 0)
			{
				tics--;
			}

			while (!tics)
			{
				// mobj was removed
				if (!setState (curState.nextState))
				{
					return;
				}
			}
		}
	}

If you're also adding lights after any light sensors are created, you'll also need to make other, more complex changes to the light sensors for them to be aware of the new lights.

[Hey Doomer]

I've posted 2.42b that includes the patch from phantombeta (great!) and changes the marker placement code to be the same for everything. I haven't had a chance to look at this for many levels, but it seems more natural in some areas such as here:

https://i.postimg.cc/L5n0nXwn/Screensho ... 154929.png

Note the entire descending staircase isn't lit up because the window to the right is up too high to cast downward.

Another:

https://i.postimg.cc/rmJKKyxX/Screensho ... 155241.png

Note the improvement from the previous MAP01 screenshot above. In this one, the light is evenly pouring in through the window and the glitch to the left is gone (another bug fix thanks to something Enjay pointed out).

Thanks to everyone. Great feedback.

Update:
https://i.postimg.cc/vm0x8LnL/Screensho ... 162741.png
https://i.postimg.cc/Ssj2n270/Screensho ... 163052.png

[Enjay]

Getting better all the time. It's a great way to play through familiar maps and get a new perspective on them - makes old familiar maps creepy again.

I was wondering is anything can be done to allow for sectors that change appearance.

e.g. E1M2

The nukage pool is creating a green fog environment (be nice if the platform sector was also included, but I can see why it isn't).


After hitting the switch, the nukage disappears but the green fog persists.

[SLON]

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.

It's a little strange because I have a noticeably older system, but everything went smoothly.

As for the lighting issues, the only way to overcome this is to change all the lighting to dynamic, instead of the old-school scheme that is hard-coded to sectors.

[Hey Doomer]

Getting better all the time. It's a great way to play through familiar maps and get a new perspective on them - makes old familiar maps creepy again.

I was wondering is anything can be done to allow for sectors that change appearance.

I've seen the same thing. Perhaps, in the World Line Activated event and iterate through sector tags. I'll have to check into it.

The above sector is linked to the wall switch with action 9 linked to tag 8. It seems I would need to iterate through all sectors, since multiple sectors can have the same tag. Sounds possible.

Update:
The above works - sort of - but for present I've decided to disable fog. I'd rather avoid this kind of exception programming... thanks for pointing this out.

[Hey Doomer]

I've posted a small update (v2.43b) in which I've disabled fog. It's possible to find out which sectors have changed where when, but I'm not a fan of exception programming in this case. I suspect this would just break many maps, so I've chosen to disable fog while I ponder this.

I have added support for adding dynamic light actors to top, middle, and/or bottom textures. Previous versions averaged colors and stuck a dynamic light actor in the middle. While this version may add more dynamic lights they are placed logically depending on definitions.

Update:
I see that some of the colors are now more noticeable, as in the Exit on MAP01. I suspect this is a color definition more than a coding problem. In previous versions colors were incorrectly averaged, because I didn't check for null textures. This version fixes that bug. I'll look at colors again I guess.

Update:
Working on sizing based on texture area. Much better since part of the issue is the top or middle (as well as window height) may not doesn't match width. Next update.

Update:
Working on cleaning up lights based on perceived brightness, sector light, etc with a more subtle effect. Example:
https://i.postimg.cc/sxMMp3B2/Screensho ... 191947.png
https://i.postimg.cc/FH3Dy4cG/Screensho ... 193529.png

Previous code was dealing with diluted color and so dynamic lights were much stronger. I have tweaked this calculation to be based on sidedef area, which makes more sense than just the width of a texture.

[Hey Doomer]

Minor release with dynamic light calculation tweaks and more subtle lighting. Still working on this regarding colors and size of textures, but this will give you a better idea of the direction. Also experimenting with subtractive lighting.

[Hey Doomer]

Making progress for the next release with a lot of little things.

Screenshots:
https://i.postimg.cc/1XJ7PHT7/Screensho ... 164204.png
https://i.postimg.cc/y6PbF1dh/Screensho ... 164305.png

The white balls are not spirit orbs. They are for my benefit in testing and represent dynamic light objects.

I've added dynamic light windows as an option, since this is used to cast light from much brighter into much darker areas and can be a performance hit since it increases the number of dynamic lights. I've reordered the light code to determine the sector light levels before attaching any dynamic lights and added an option to select the perceived brightness calculation that determines the strength of the light. (Perhaps someone with more knowledge can enlighten me - yes, ha ha - on that subject.)

Many bug fixes and other things, so this will be an important but incremental release, possibly tomorrow.

[Hey Doomer]

Just posted v2.46b with the following changes:

• fixed a lot of little bugs related to dynamic light placement
• added an option to select one of two formulas for perceived brightness (converting RGB to luminance); note this only affects strength of dynamic lights added by Relighting.
• there was a bug in certain areas, such as the closet at the start of E1M4, that has been fixed
• added a brightmap for BRWINDOW.png
• a few color tweaks, notably making BROVINE brighter, affecting the start of E2M3, for example:
  https://i.postimg.cc/FskDsvrc/Screensho ... 055800.png
• general code cleanup

There are still far too many areas of the game without any visible light at all, but then Doom is meant to be a horror game. Some areas work well with dynamic lights:

https://i.postimg.cc/85rx860J/Screensho ... 060159.png

Since dynamic lights are now based on the area covered by the texture or window, this avoids a washed-out look on textures with interesting effects:

https://i.postimg.cc/Bv5M2BkC/Screensho ... 060448.png

This also has a more realistic effect on small vs. large windows:

https://i.postimg.cc/sXb247tT/Screensho ... 060947.png
https://i.postimg.cc/fyXR2ksD/Screensho ... 061006.png

Note that "window" lights are not only outside windows but any opening from an area of light to dark exceeding limits. I've added a Settings option to turn window lights off completely, since it does add quite a few dynamic lights in some areas.

Let me know what you think!

[Enjay]

Looking nice and still performing well.

A handful of oddities that I quickly spotted:
It might be an idea to include a brightmap for the exit signs to prevent situations like this.


Is this sector meant to be green? To me it looks odd - especially with the water being so blue. There is no obvious reason in the map for it to look so green IMO.


For some reason, the nukage pool is very dark in an otherwise bright outdoor area.

[Hey Doomer]

Looking nice and still performing well.

A handful of oddities that I quickly spotted:
It might be an idea to include a brightmap for the exit signs to prevent situations like this.


Is this sector meant to be green? To me it looks odd - especially with the water being so blue. There is no obvious reason in the map for it to look so green IMO.


For some reason, the nukage pool is very dark in an otherwise bright outdoor area.

There is a brightmap in the SBrightmaps pk3 that I brightened:
https://i.postimg.cc/CLGTbyGq/Screensho ... 185820.png

Originally my problem with MAP02 was no light sources at all, and since I'd give NUKAGE3 a color I added one to FWATER1. Then I added a greenish color for the PIPEWAL textures. But you're correct, this looks dumb. Here's a revised look:
https://i.postimg.cc/YCR5y1y2/Screensho ... 185440.png

I don't see a dark pool, really. Maybe it's your sector lighting mode?
https://i.postimg.cc/HLLqGVfw/Screensho ... 185913.png

All valid and constructive points.

As an aside, I've looked at spotlights. Currently this uses sector or point lights with support for subtractive lights (not sure about the latter). I tried an overhead spotlight, and this didn't add to or replace the sector-based lighting. Most of Relighting is still sector based, so I've abandoned (for now) the idea of adding texture spotlights.

[Hey Doomer]

Just posted v.2.47b.

This update does the following:

• adds 5 sector lighting steps (should be no performance hit)
• moves the "Luma" calculation to Light Performance Settings, since this also affects sector lighting
• optionally change the number / distribution of light source markers

I'm continually disappointed using dynamic lighting as light sources; they don't seem to be suited for it. Doom has sector-based static lighting, and a primary goal of Relighting has been to improve that feature. That's the intention of this minor update. Increasing lighting steps below 512 map units creates subtle gradients of light. The light sensors only see placed light source markers, so increasing the number of markers also helps lighting quality at a performance cost. I haven't noticed this on my rig, but it certainly hits performance. What this means, since light markers are prioritized at doors and then two-sided lines, is that sensors respond quicker and in more locations.

Increasing the number of steps below 512 won't impact performance, but it will make the game a bit brighter in some areas, and I also tweaked these limits.

Examples of improved (your mileage may vary) lighting:
https://i.postimg.cc/Hxz78VMz/Screensho ... 042203.png
https://i.postimg.cc/Rh0J74QB/Screensho ... 043517.png
https://i.postimg.cc/nVdDH9pc/Screensho ... 051125.png

The difference is subtle but noticeable I think.

I forgot initially that the calculation to determine perceived lightness of color (RGB->Luma) also affects sector lighting, so I've moved this to the Color Settings menu. I've not tested this extensively, but theoretically it adjusts lighting based on however the human eye perceives light. Rods and cones are not evenly distributed and have different wavelength sensitivities; our eyes are more sensitive to some colors than others. This "perceived brightness" is the idea behind adjusting sector lighting and dynamic light strength. Both formulas give more weight to the color green, for example, to which our eyes are most sensitive. BT.601 emphasizes red and blue more.

Thus, the colors chosen in the text lumps can significantly affect lighting. Darker colors result in a gloomier game.

[SLON]

With brightmaps it looks dramatic now (see map 13). I also think they should be added to the lamps on the walls.