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

[mamaluigisbagel]

Just tested v2.33b. Can confirm I still have noticeable performance hit, but I will add I have a really crap PC so it could just be that. Other than that problem, I really like how things look with this mod. Especially the reflections.

btw is there any recommended sector light mode for this, or does it really matter that much?

Also random screenshot because I found the look of this area interesting.

[Gorec]

just downloaded the latest version of the mod,not sure why this happens, tried on 4.7.1(fresh) and on dev build

[mamaluigisbagel]

just downloaded the latest version of the mod,not sure why this happens, tried on 4.7.1(fresh) and on dev build

I actually had this crash too with Project Brutality. I'm curious if it has to do with custom title maps or something else.

[Hey Doomer]

just downloaded the latest version of the mod,not sure why this happens, tried on 4.7.1(fresh) and on dev build

My bad - this is because it's looking for a CVar called "rl_sensors" that I removed. I'll fix that, but try adding rl_sensors 1 on the console.

[Hey Doomer]

btw is there any recommended sector light mode for this, or does it really matter that much?

Thanks for the feedback! I'm working on some performance issues. Found at least one bug that has a small negative impact, working on z-height adjustments, etc. I have been running this on "Software" sector mode, but I don't think it matters.

[phantombeta]

I'll preface this with a note: Please don't view this as an attack on your programming skills. If anything here seems abrasive, it's due to bad phrasing or social skills, not malice or condescension.

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.

ZScript is not slow at all. It's quite fast, and several orders of magnitude faster than something like ACS. Of course, as with any programming language, you still have to carefully optimize your algorithms while accounting for the language's quirks.

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.

ZScript is a JIT-compiled language, and a subtraction is only a few instructions. It'll certainly be considerably faster than portal checking, 2 multiplications, 2 additions and a square root.
It has some quirks, like having no function inlining and no optimization pass, but these are rarely a problem if you're aware of them. You can use the "profilethinkers" console command to find out what thinker exactly is causing performance issues.

You seem to be doing some things that are harmful to performance here- CheckProximity, for example, has to iterate through every single existing thinker of any type to do its job, which is quite slow. You're also allocating multiple new instances of rlClass_CVars constantly, and you get the CVar structs every time you create a new one, and that'll cause performance issues.
For a simple test, I removed dormancy and pauses, and changed the 52-tics Spawn state to 1 tic. On E1M2, this slowed the game down to a crawl. I made some changes to the mod, such as caching CVars, and using statnums and directly iterating the statnums to find the actors instead of using CheckProximity, and the framerate went back to 60 FPS in most places, with the most intensive places still being above 30.

The attached file has these optimizations, along with some other ones, like storing the closest lights for sight checking instead of calling CheckProximity.

[Hey Doomer]

ZScript is not slow at all. It's quite fast, and several orders of magnitude faster than something like ACS. Of course, as with any programming language, you still have to carefully optimize your algorithms while accounting for the language's quirks.

The attached file has these optimizations, along with some other ones, like storing the closest lights for sight checking instead of calling CheckProximity.

No worries. ZScript's CheckProximity is slow, that's the bottleneck I think. Exactly what I meant, I assumed a loop using an iterator would be slower than a (?compiled) function. Also meant that subtraction is probably faster than Distance2D - possibly not for similar reasons. But it's all good.

Thanks for looking at this and spending time, I'll check it out!

Update: great work.

I am stuck (been looking at this too long) seeing why dynamic lighting is broken, however...

Update: got it

[Hey Doomer]

I'm pleasantly surprised by the new optimizations and more impressed by what ZScript can do. This is a great community! I've posted v2.34b, which contains phantombeta's optimizations with a few changes, correction to the dynamic light size, and an improved function to determine actor z-offset that places light sources slightly higher and fixes placement around doors. There are still a few issues with this here and there that I'm looking at, but it looks very good.

Screenshot:
https://i.postimg.cc/YCh0Mpvy/Screensho ... 043404.png

Again, didn't mean to suggest that ZScript itself is a poor language. Quite the opposite - I'm continually astonished at what it can do - but that some functions are obviously too slow for some needs. I expressed my frustration poorly.

[Hey Doomer]

Here's a new experiment:

https://i.postimg.cc/259pZt73/Screensho ... 075042.png
https://i.postimg.cc/L8sN18CB/Screensho ... 075359.png

It is annoying that Relighting doesn't have light coming in from windows. Just started on this, but the screenshots illustrate the idea. Coming in next release.

Update
Progress. The strength of the light is based on perceived brightness.

https://i.postimg.cc/3wsLdLrQ/Screensho ... 085521.png
https://i.postimg.cc/5y1nm6FP/Screensho ... 085958.png
https://i.postimg.cc/G20BBfBR/Screensho ... 090723.png

The white dots are the dynamic light markers in the windows. It uses whatever the sky color is. The broader the window, the more light.

[Enjay]

Just tried the most recent release and - woohoo! - performance issues are gone. When I first started playing, I was sort of convincing myself that there might still be a hint of something but, actually, I don't think there was. I certainly soon forgot about it and was able to just get on with playing without giving a thought to performance.

So, with that out of the way, I thought I'd mention a couple of things that I'm sure are already known about. All of these are minor quibbles and do not really detract from the amazingness of what this mod is managing to do. However, if there is some way to tweak how these things happen...

All shots are from E2M2 of Doom.

Light placement 1:

---

Pool of light to the right of the shotgun tip - with no obvious reason to exist.


Similar deal on these steps.


and these two points of light by the wall.

Light placement 2:

---

Interesting triangle of light that looks like it is coming from a light on the wall that doesn't exist.

Light colour:

---

The square of red light is very abrupt. i.e. there is no fade-out/overspill of red light into the surrounding area.

However, the mod worked really well. As I said, the performance issues that I was experiencing have now gone and the overall visual effect is very nice indeed, especially for a high-level mod that is calculating the changes as it goes (which is always going to be a bit blunter than a mapper carefully agonising over light levels and light placement). It really added a new dimension to a map that I am incredibly familiar with (outside Ep1, E2M2 (and E3M9) is probably the Doom map that I am most familiar with).

[Hey Doomer]

This is great news, Enjay!

Dynamic lights bleed in all directions, perhaps, unless a spotlight.* These are all sector point lights, and currently it's one size fits all. Possibly it needs code to add/remove a light conditionally. That's for an upcoming release, perhaps.

* Update: I see the problem I think.

[Hey Doomer]

I've posted v2.4b (the real version) with added dynamic window lights. This is a light actor in the middle of the window that shows light the color of whatever is outside (see above screenshots). The intensity of the light is broadly based on width of the window and perceived color brightness. Let me know what you think!

Update:

Another screenshot showing the new window lighting:
https://i.postimg.cc/pVjMq22Q/Screensho ... 100414.png
https://i.postimg.cc/t4rDGxXK/Screensho ... 102048.png

[mamaluigisbagel]

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>

[Enjay]

Window lighting looks good.

Just another example of where strongly coloured sectors can be an issue E1M1 final room:


Sector under the exit sign is not red. No idea if your algorithms can cope with something like that.

And just an observation:
The colour that you use for the other types of TLITE flats is quite yellow:


Personally, I tend to use 255, 219, 182 (FFDBB6) for those. I'm not saying it's perfect either, and it's not as obvious/dramatic, but I think it does more closely match the colour of the lights on the texture.

(screenshot not taken with relighting - hence the rest of the map not quite "popping" in the same way.)

[phantombeta]

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.

Here's the fixed code for rlClass_CVars:

---

Code: Select all

class rlClass_CVars : Thinker
{
	transient bool cvarsLoaded;

	transient CVar rl_default;
	transient CVar rl_enabled;
	transient CVar rl_gldefs;
	transient CVar rl_reflections;
	transient CVar rl_hudicon;
	transient CVar rl_debug;

	transient CVar rl_max;
	transient CVar rl_min;
	transient CVar rl_lux;
	transient CVar rl_dynlux;
	transient CVar rl_add;
	transient CVar rl_alpha;
	transient CVar rl_fog;
	transient CVar rl_fogarea;
	transient CVar rl_plr;
	transient CVar rl_gltype;

	transient CVar rl_glstrength;
	transient CVar rl_ldist;
	transient CVar rl_pdist;
	transient CVar rl_ddist;

	void initialize()
	{
		ChangeStatNum(Thinker.STAT_Info);
		initializeCVars();
	}

	void initializeCVars()
	{
		if (cvarsLoaded)
		{
			return;
		}

		rl_default = CVar.findCvar("rl_default");
		rl_enabled = CVar.findCvar("rl_enabled");
		rl_gldefs = CVar.findCvar("rl_gldefs");
		rl_reflections = CVar.findCvar("rl_reflections");
		rl_hudicon = CVar.findCvar("rl_hudicon");
		rl_debug = CVar.findCvar("rl_debug");

		rl_max = CVar.findCvar("rl_max");
		rl_min = CVar.findCvar("rl_min");
		rl_lux = CVar.findCvar("rl_lux");
		rl_dynlux = CVar.findCvar("rl_dynlux");
		rl_add = CVar.findCvar("rl_add");
		rl_alpha = CVar.findCvar("rl_alpha");
		rl_fog = CVar.findCvar("rl_fog");
		rl_fogarea = CVar.findCvar("rl_fogarea");
		rl_plr = CVar.findCvar("rl_plr");
		rl_gltype = CVar.findCvar("rl_gltype");

		rl_glstrength = CVar.findCvar("rl_glstrength");
		rl_ldist = CVar.findCvar("rl_ldist");
		rl_pdist = CVar.findCvar("rl_pdist");
		rl_ddist = CVar.findCvar("rl_ddist");

		cvarsLoaded = true;
	}

	static rlClass_CVars get()
	{
		let it = ThinkerIterator.create("rlClass_CVars", Thinker.STAT_Info);
		let ret = rlClass_CVars(it.next());

		if (!ret)
		{
			ret = new("rlClass_CVars");
			ret.initialize();
		} else
			ret.initializeCVars();

		return ret;
	}

	static void setDefaults()
	{
		CVar.findCvar("rl_default").resetToDefault();
		CVar.findCvar("rl_enabled").resetToDefault();
		CVar.findCvar("rl_gldefs").resetToDefault();
		CVar.findCvar("rl_reflections").resetToDefault();
		CVar.findCvar("rl_hudicon").resetToDefault();
		CVar.findCvar("rl_debug").resetToDefault();

		CVar.findCvar("rl_max").resetToDefault();
		CVar.findCvar("rl_min").resetToDefault();
		CVar.findCvar("rl_lux").resetToDefault();
		CVar.findCvar("rl_dynlux").resetToDefault();
		CVar.findCvar("rl_add").resetToDefault();
		CVar.findCvar("rl_alpha").resetToDefault();
		CVar.findCvar("rl_fog").resetToDefault();
		CVar.findCvar("rl_fogarea").resetToDefault();
		CVar.findCvar("rl_plr").resetToDefault();
		CVar.findCvar("rl_gltype").resetToDefault();

		CVar.findCvar("rl_glstrength").resetToDefault();
		CVar.findCvar("rl_ldist").resetToDefault();
		CVar.findCvar("rl_pdist").resetToDefault();
		CVar.findCvar("rl_ddist").resetToDefault();
	}
}

As an unrelated note, ZScript is case insensitive, so you can write type, function, variable, etc. names from gzdoom.pk3 in the same casing as your own code for consistency. I recommend doing that, for consistency and readability.
(The transient modifier makes the member variable not be saved to save files.)