Relighting v4.0165b - blurry shadows w/ rlassets

[cosmos10040]

I think this mod is just getting better and better, except for one change that you made. I don't think the way you've done the wall shadows is as realistic anymore, I don't think the shadow would end on the floor before hitting the wall, I'd say that would require 2 light sources.

I think in order versions the floor shadow stretched out until it reached the wall if the light source was low enough.

That's my only critisicm haha, keep up the good work.

I think I can agree on this, the mod is perfect. But if the floor shadow can stretch to the wall then it would look better when there is a wall shadow. Ofcourse unless there are two light sources.

[Hey Doomer_]

I think this mod is just getting better and better, except for one change that you made. I don't think the way you've done the wall shadows is as realistic anymore, I don't think the shadow would end on the floor before hitting the wall, I'd say that would require 2 light sources.

I think in order versions the floor shadow stretched out until it reached the wall if the light source was low enough.

That's my only critisicm haha, keep up the good work.

Great suggestion that makes sense. The shadow thinker doesn't analyze where collective light sources are, but it does track the number of visible lights. Line is changed to this:

Code: Select all

double shadow_length = rl_Cvar.rl_long_shadows.GetBool() && num_visible > 1 ? rl_Cvar.rl_shadow_distance.GetInt() : caster.Height * Scale.Y;

This allows for disconnected wall shadows when there are multiple light sources. I'll see how this works, since it's performance-friendly. Many thanks!!

[Hey Doomer_]

Posted v4.0157b

Code: Select all

v4.0157b

3/14 - clamped light level to avoid DIV/0 error
3/15 - added check for no/null sprite in shadow caster, deleted exception coding
3/17 - added light size adjustment based on color settings
3/17 - checks for caster lights, bug fixes for shadow pitching of long shadows (bug fix)
3/17 - check for 3d distance of light (performance)
3/17 - search animated texture lumps instead of list
3/18 - added wall shadow alerts
3/21 - added "Death" decoration/missile state spotlights
3/22 - reorganized menus with tips
3/22 - added ceiling shadows for SPAWNCEILING actors

Many changes, some of which are not on the above list. In addition to what has already been mentioned above in this thread, I've added "Death" state decoration and missile spotlights. Usually these are things like the explosive barrels, doom imp balls, etc., that have a Death state. A pitched spotlight is attached to these items. Example.

I've also reorganized the menu into submenus that (hopefully) make more sense with some explanation of the settings. I've added settings for animated reflections vs. simple floor reflections based on color. All exceptions except for a few light specials and flashlight classes have been deleted as previously noted.

In addition to wall shadows being modified as noted, I've also added the ceiling shadows. I've tested with the original levels and a half-dozen mods without any errors.

Thanks for your help and support with this mod. It's getting better all the time! Let me know what you think.

[Hey Doomer_]

WIWO v4.0158b - optimizations

Code: Select all

v4.0158b

3/25 - used Thinker.STATNUM + 1 for hd_light actors (optimize)
3/25 - limit reflections on non-anim flats by rl_colored_perceived only (optimize)
3/25 - added sprite height check for TNT1A0 actors in hd_shadow (optimize)

I think this is more or less feature complete as a universal mod (for now ), so I'm working on optimizations. I think there are more opportunities to adjust CVar limits dynamically based on the map itself.

You can try the Thinker.STATNUM + 1 and see if it helps; it's certainly more efficient. Add the following in zscript\actors\hd_light.zs:

Code: Select all

	override void BeginPlay()
	{
		Super.BeginPlay();
		ChangeStatNum(Thinker.STAT_USER + 1);
	}

In zscript\actors\hd_shadow.zs, change the ThinkerInterator in the Tick() function to this

Code: Select all

			ThinkerIterator it = ThinkerIterator.Create("hd_light", Thinker.STAT_USER + 1);

[Hey Doomer_]

Posted v4.0158b - optimizations

A maintenance update with some optimizations.

Code: Select all

v4.0158b

3/25 - used Thinker.STAT_HDLIGHT for hd_light actors (optimize)
3/25 - limit reflections on non-anim flats by rl_colored_perceived only (optimize)
3/25 - added sprite height check for TNT1A0 actors in hd_shadow (optimize)
3/25 - fixed DIV/0 error line 1754
3/25 - adjust dynamic light intensity per # hd_lights (optimize)
3/25 - limit shadows within fov (optimize)
3/25 - eliminated sight function checks for player shadow (optimize)
3/25 - eliminated BlockedCheckSight for non-monster casters (optimize)
3/27 - adjust visible light distance by light scale (optimize)

Out of the above the stat number, avoiding calling line trace functions, and reducing visible light distance have the biggest (although not dramatic) impact. The mods that I've tested with often have many small items spawning, so increasing Sprite Min Size in the Settings to 20 will help (default is 5). I'm working on adjusting that based on the map, something already done with light placement and dynamic light intensity.

Other optimizations above are useful but less commonly needed, such as using the player fov instead of 90 (GZDoom default is 90).

Other Boring Stuff About Optimization

The way shadows work is they are spawned by an inventory item (this is the technique in Nash's shadow mod). Shadows in the player view window - that is, not behind the player and that can "see" the player - search for visible light using a thinker iterator. Since an iterator goes through all items of a type, more light sources = more cycles. This happens every few tics, which can be adjusted by changing the Shadow Lifespan in Settings (default is 3). Shadows are activated in front of the player and lights are searched for by those shadows depending on the type of shadow and Shadow Distance in Settings.

Adjusting these settings may have more impact on frame rates than adjusting Area Min or Max, which determine where lights might be placed (the minimum is adjusted by area skew and is likely much higher in game, especially in detailed maps). In summary the following limit shadow thinkers for improved performance: raising Sprite Min Size eliminates shadows on smaller items; lowering Shadow Distance reduces the number of active thinkers although won't change the iterator itself; increasing Shadow Lifespan decreases the number of thinkers running at any one tic. Limiting the maximum number of shadows may also help - these are in-game counters that are increased or decreased depending - but at present it can cause some sprites that should have shadows not having shadows.

I hope that helps explain what Relighting is doing.


Many thanks!

[Kanok]

I wanted to know if your mod works with Project Brutality for you, Doomer. I'm starting to wonder if maybe I need to reset my configuration and redownload PB instead of trying to understand why it's not working and submitting bug reports for a problem that I might be the only one having.

[Hey Doomer_]

I wanted to know if your mod works with Project Brutality for you, Doomer. I'm starting to wonder if maybe I need to reset my configuration and redownload PB instead of trying to understand why it's not working and submitting bug reports for a problem that I might be the only one having.

I did try this version with Project Brutality and didn't have any problems with it. What's the error? I'll see if I can help.

[Hey Doomer_]

WIWO v4.0159b - more optimizations

Code: Select all

v4.0159b

3/27 - adjust sprite min/max by number of sprites (optimize)
3/28 - double shadow lifespan for actors > 1/2 distance (optimize)

It's a simple thing to iterate through a sector thing list and get the Actors in a map, including sizes for a count. (DOOM:ONE, for example, has over 2700 shadow generators in the map with default Relighting settings.) I've added an adjustment to the CVars depending on that count, which improves performance and helps make Relighting scalable.

Interestingly regardless of count size distribution and kurtosis are consistent, unlike sector area. Most maps that I have tested seem to have equal proportions of critters, decorations, and pickups at WorldLoaded, in other words. The number of these varies - even in canonical maps - and that makes sense.

If caster-to-player distance is within range but more than half that range, I've doubled the CVar lifespan of the shadow. Still testing this and it looks the same. However this certainly reduces the number of thinkers running at any one tic. Practically speaking with default settings all this is still fractions of a second (going from 3 tics to 6).

Any bugs or ideas for optimizing, please let me know. I've likely missed things, and it still seems that each time I review the code I find a minor bug here and there.

Many thanks! I appreciate it!

[DarkkOne]

https://imgur.com/ul71fkw

Got a DIV/0 with 4.0158b

Only mod was Flashlight++ 8.5


I will say, Hexen looks _really_ good with this mod.

[Hey Doomer_]

https://imgur.com/ul71fkw

Got a DIV/0 with 4.0158b

Only mod was Flashlight++ 8.5


I will say, Hexen looks _really_ good with this mod.

This is something I missed from several versions back from smart lighting additions. The idea was to tweak the scale of a decorative light source by the perceived brightness of light color against how bright a sector is; to trigger this error the sector has a 0 light level and a decorative light. Try changing 1321 to this:

Code: Select all

r *= perceived / ((sec.LightLevel + 1) * 0.7);

The light scale is clamped below the block, so this will increase the scale to maximum if the sector has no light, which makes sense.

I agree that Hexen looks good, as does Heretic and even Freedoom. I don't have Strife, and indeed I've mostly worked with Doom as the game most familiar to me. Hopefully Relighting enhances anything that runs in GZDoom.

Thanks!

[ate0ate]

I'm having a strange issue with the recent update. I was playing Hell Revealed and noticed if I save on map one, then proceed to map two and attempt to load my prior save on map one that the game errors with the message "Savegame is from a different level." This is repeatable every time using only HR and the relighting mod. I was curious if it was exclusive to the level or wad but no, I could also get this to happen on vanilla doom 2 using just the relighting mod. Just make your way through a level to the exit, quicksave, exit the level and begin the next, then attempt to reload your quicksave on the prior level.

[Hey Doomer_]

I'm having a strange issue with the recent update. I was playing Hell Revealed and noticed if I save on map one, then proceed to map two and attempt to load my prior save on map one that the game errors with the message "Savegame is from a different level." This is repeatable every time using only HR and the relighting mod. I was curious if it was exclusive to the level or wad but no, I could also get this to happen on vanilla doom 2 using just the relighting mod. Just make your way through a level to the exit, quicksave, exit the level and begin the next, then attempt to reload your quicksave on the prior level.

Interesting. Doom 2 works fine for me with 4.10.0. What version of GZDoom?

A user on Mod DB had the same error and adds this:

This problem occurs in the latest version of developer GZDoom.
It does not occur in version 4.10.0.

[ate0ate]

Shoot, I hadn't even thought of that. I am also using the latest dev build, 163 I believe. Sorry about that. It completely slipped my mind. I'll just revert to the release version. Hopefully its just a temporary dev thing and not a lasting change that'll break the mod down the road at the release of 4.11. Sorry again!

Edit: There's a bug with quicksave rotation in the 4.10 release so I prefer using a dev build where that has been fixed. After playing around with things more it seems to be only the most recent build, 163, that causes issues with this mod. 4.11pre build 154, the build prior to latest, works just fine. I thought maybe it was just an issue with the latest dev build itself but when testing things in just vanilla doom the issue did not occur. I have no idea what any of that means, but if there is anyone wanting to play with relighting and also avoid the quicksave rotation issue in GZDoom's release build, then dev build 154 is where to go.

[Kanok]

Sorry it took me so long to get back to you on this. I actually posted it earlier, but it was probably missed. Either way, here is the current output. This is with the latest version of PB and your mod.

TITLEMAP - PB_Introduction

VM execution aborted: division by zero.
Called from hd_relighting_EventHandler.WorldThingSpawned at relighting v4.0157b.pk3:zscript/hd_relighting_eventhandler.zs, line 1754

[Hey Doomer_]

Sorry it took me so long to get back to you on this. I actually posted it earlier, but it was probably missed. Either way, here is the current output. This is with the latest version of PB and your mod.

TITLEMAP - PB_Introduction

VM execution aborted: division by zero.
Called from hd_relighting_EventHandler.WorldThingSpawned at relighting v4.0157b.pk3:zscript/hd_relighting_eventhandler.zs, line 1754

This loads fine on my end using PB v8.5 and Relighting v4.0158. Line 1754 is this:

Code: Select all

ptr.Scale.Y = rl_Cvar.rl_sector_light_scale.GetFloat() * clamp(e.thing.CurSector.LightLevel / (sky_light + 1), 0.5, rl_Cvar.rl_sector_light_scale.GetFloat() * 1.1);

Not sure where a DIV/0 is coming from. Indeed this line doesn't fire for me in TITLEMAP. Are you running a different version of PB or using any PB add-ons?