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

[Hey Doomer]

Could the error be created by the way map makers do lighting in their maps?
Because the error never happened on the regular Doom maps. Or maps of chaos, I also tried that. Only on the Mars Wars v3.01 WAD.

It's possible depending on what spawns. Shouldn't happen now.

I don't think this is connected to lighting. Lighting in any map is ignored by Relighting except for dynamic lights and sector specials placed by the author. I doubt it works with lighting mods such as DarkDoomZ that only change sector lighting.

You'll find performance hits depending on the number of small sectors in an area, textures used, and so on. Most of that can be fixed by changing definitions to suit whatever the style of the map is, I think. I just picked what looks good for Doom.

[ezedrommond]

Just posted v2.6b with a few changes to dynamic lights.

• Fixed the ShadowActor bug
• Added different strengths for "sky" windows, indoor windows, and texture-attached dynamic lights
• Added a logarithmic light strength scale e.g. 0.4 is higher compared to 0.3 than 0.3 is to 0.2

Most of this is stuff I meant to get to or saw at one point or another and added fudge instead to make something else taste better. All dynamic lights are now sector lights. Finally, I've added further adjustments to sector lighting depending on how many and what kind of dynamic lights are added.

This has created some surprising effects, even in "bright" sectors without light sensors. Examples of the new and improved lighting:

MAP11 - a good example of everything working together (still reminds me of nighttime miniature golf!)
E1M3 - an example of adjusted sector lighting after dynamic lights are added to the right
MAP05 - sector lighting (these colors were pointlights in previous versions)
E2M3 - another example of dynamic lights adjusting the sector lighting, this time in a "bright" sector

Amazing. Again I emphasize there is no exception programming - with less fudge - and everything is just based on text lump definitions. A few changes can completely transform an area. (Try commenting out a definition, reopen the map, and see what happens.) I've just chosen what looks good to me for the Doom textures, but don't let that influence your opinion of the mod. It can easily be customized to work with any map or game, even with custom textures.

Performance should be better with this version. Many dynamic lights were overpowered, and while there are still areas of performance hits, dynamic lights have been drastically reduced to be in line with the strength scale. Tastes great, less chewing.

Thanks for your interest and comments. Let me know what you think!

Now it works great!! thank you!!

[Enjay]

At default values, I'm finding 2.6b much less subtle, and far darker (unplayably so) than with previous versions. Many sectors seem to have dropped to what must be 0 light and the contrast between light and dark areas right next to each other can be very stark.

A few examples:


MAP01: the starting area is almost completely black, except the steps which are much brighter. (There is also that strange "arch" of darkness on the wall.)


Map02: The only light here is spilling through from elsewhere. I haven't killed any of the bad guys yet so they are all still present (and somewhere in the gloom) but, aside from the one lit by that light spilling through, I can't see any of them.


Also MAP02 - just another angle with slightly different settings. All the zombies are still there. Stepping into the black means I can see nothing (unless I look back to the brighter areas, of course). The entire screen is black.


E1M1: No light through these windows.


E1M1: Or in the corridor beyond.


E2M1: has also taken on a very dark, sinister look.


I guess 2.6b has implemented Doom3 mode,

[Hey Doomer]

At default values, I'm finding 2.6b much less subtle, and far darker (unplayably so) than with previous versions. Many sectors seem to have dropped to what must be 0 light and the contrast between light and dark areas right next to each other can be very stark.

A few examples:
I guess 2.6b has implemented Doom3 mode,

Great observation as always, Enjay. I think I see a problem. In relighting_actors.zs line 181 the gradient constant is 3.0 and needs to be 2.0 to be less stark, although I'll look at this. Fix by next release, although that may be all it is.

Also the windows in E1M1 face West. If you change the light to come from the West it should come in. (Something else to worry about.)

Code: Select all

		double fK = 2.0;

Update:

Yep, the above is a temporary fix, but the problem is the revised light gradients (previously there was added fudge). I'll include this as a performance option in the next release (as you say, Doom 3 mode ). It's mathematically correct but the exponential rise is too steep to be subtle. However, some may prefer that, so great catch Enjay!

[thugsta]

Maybe as a little side version of this you can have the lighting be less realistic and just make it shine down with light as if the sun is directly completely above the map/level and there was no roof/ceilings to have a basic cone of light in every room/location.

or maybe you can have a ceiling light spawn on ceiling textures (like brutal doom does for example) and build the light from their?

Food for thought is all

[Hey Doomer]

Maybe as a little side version of this you can have the lighting be less realistic and just make it shine down with light as if the sun is directly completely above the map/level and there was no roof/ceilings to have a basic cone of light in every room/location.

or maybe you can have a ceiling light spawn on ceiling textures (like brutal doom does for example) and build the light from their?

Food for thought is all

Already scrapping all the old light code to use precalculated light levels based on inverse square law (does Dawn remove fudge, I wonder?). HS physics!

Work in progress with refactored light sensor code. When a sensor is created all light levels are baked into sorted arrays for nearby light sources and then updated in real time. The only real-time calculation is a CheckSight() function call. Much less code and much faster (I think). I should have an update perhaps by tomorrow.

Update: for the curious see attached canary build with window grids disabled.

Update: Canary with color gradient. Should have a beta tomorrow. This new code is a significant improvement.

Just a note, but the other thing I've eliminated is the light source marker restriction. This was needed before because of an iterator search each cycle. Now that these are preloaded into arrays that doesn't matter.

[Hey Doomer]

I don't have anything just yet, but I have completely rewritten the light code adapted to the inverse square law. (I knew about that, just forgot. And I liked HS physics more than trig.) I've eliminated all light adjustments for "bright" sectors, since there are no restrictions on markers; light sources are changed based on perceived brightness of color. During this process I found a dozen or so bugs - some of which have festered for some time and that I'd fudged one way or another. Fixed all. Performance and responsiveness are improved (sensors fired every 52 tics, now it's every 14, etc).

Unfortunately I don't have a release quite yet. I still have to review dynamic light code. I may have something by tomorrow.

[vokar]

Are there older versions still available anywhere? Specifically looking for a version that will run with gzdoom 4.3.3 or older.

[Hey Doomer]

Are there older versions still available anywhere? Specifically looking for a version that will run with gzdoom 4.3.3 or older.

I started writing this with a newer version of GZDoom, so I don't have an answer if this doesn't work with an older version. It could be the ZScript version or any number of things, I suppose.

[Hey Doomer]

I've been doing CPR on the canary, and I think she'll live. So far I've done the following:

• Rewrote marker and sensor placement.
• Rewrote the sensor code from scratch. Everything is calculated ahead of time and put into a sorted array for speed for each sensor. (Used an insertion sort for the curious.)
• Added sensor code to ignore sector light specials for now. This causes inconsistent starts on some maps (such as E1M1 where the closest bright marker might be the blinking column sectors.)
• Fixed a few nasty bugs that took a while to find. Example: LightSensors were not given a default shared sector ID, which caused sector 0 to always be changed by every LightSensor not sharing another sector. (This is the large room at the start of MAP01, Enjay.)
• Fixed directional lighting. This is natural looking in outdoor areas where light seems to come from a single direction. Very cool!
• Other stuff too numerous to mention...

However, I do not have a release. What I have works amazing with no performance issues. Indeed, a few bugs I found degraded performance, so eliminating them is good. Screenshots:

MAP10 with light from the south. Affects bright markers as well as dynamic lights.
E1M3 door opened...
E1M3 door closing... all doors work great.
E1M4 example of minimal lighting. Many areas are lit that before were dark as... well, just dark.

I still have some work on this and will release 2.7b soon. Maybe tomorrow unless I find other nasty surprises.

[hitmanx]

Your work on this is nothing short of amazing!

but I wonder if it's possible to have the light gradually fade off from the open door shot on e1m3.

Also what sector light mode should we use for your mod?

[Hey Doomer]

Your work on this is nothing short of amazing!

but I wonder if it's possible to have the light gradually fade off from the open door shot on e1m3.

Also what sector light mode should we use for your mod?

Thanks for commenting!!

Sector lighting is all or nothing - sadly no. I have an idea for this I'm experimenting with, but it won't change how the engine handles sector lighting.

I've been writing this with "Software" light mode and haven't really checked what others look like. I'm mulling over an idea for this as well.

[vokar]

Are there older versions still available anywhere? Specifically looking for a version that will run with gzdoom 4.3.3 or older.

I started writing this with a newer version of GZDoom, so I don't have an answer if this doesn't work with an older version. It could be the ZScript version or any number of things, I suppose.

Ahh, I understand. That makes sense. I imagine that there's some function (PlayerSpawn, I think it was) that is different in the newer versions.
Next time I try it out I'll post the error and perhaps we can figure out a work around or something to retrofit it (unlikely, but you never know!). Full disclosure, I'm hoping to get it running on questzdoom for vr, since I think the relighting effect would add epic levels of immersion to the experience

[Hey Doomer]

Are there older versions still available anywhere? Specifically looking for a version that will run with gzdoom 4.3.3 or older.

I started writing this with a newer version of GZDoom, so I don't have an answer if this doesn't work with an older version. It could be the ZScript version or any number of things, I suppose.

Ahh, I understand. That makes sense. I imagine that there's some function (PlayerSpawn, I think it was) that is different in the newer versions.
Next time I try it out I'll post the error and perhaps we can figure out a work around or something to retrofit it (unlikely, but you never know!). Full disclosure, I'm hoping to get it running on questzdoom for vr, since I think the relighting effect would add epic levels of immersion to the experience

Sounds good. I know I had to write a string function workaround for another GZDoom fork.

[vokar]

It says:

... :relighting_events.zs, line 146: Attempt to override non-existent virtual function PlayerSpawned"