Relighting v4.0165b - blurry shadows w/ rlassets

Projects that alter game functions but do not include new maps belong here.
Forum rules
The Projects forums are only for projects. If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.
DarkkOne
Posts: 270
Joined: Mon Jun 06, 2016 11:26 pm
Preferred Pronouns: No Preference
Operating System Version (Optional): Widnows 11
Graphics Processor: nVidia with Vulkan support

Re: Relighting v4.0155b - long shadows

Post by DarkkOne »

So, just to see if my understanding is correct:

In summary, all flats, plus a set list of animated textures, are pre-processed at level load for "perceived brightness," and if it's over a threshold it starts becoming reflective, being more reflective the brighter it is? And because it's formulaic based on the perceived brightness of the base texture/flat, different palettes and other things can affect whether they hit the cutoff.

If I understand correctly then, custom flats of any sort can end up reflective, but custom textures will only be reflective if they replace one of the ones in "the list?"
User avatar
Hey Doomer_
Posts: 414
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.0155b - long shadows

Post by Hey Doomer_ »

The only textures read for color at this time are sky textures (there are no sky flats). Most of the stuff in ANIMDEF lumps is ignored, since it defines more wall textures than floor and ceiling flats. Otherwise correct.
User avatar
Hey Doomer_
Posts: 414
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.0155b - long shadows

Post by Hey Doomer_ »

Testing v4.0156b - window lights

Code: Select all

v4.0156b

3/4 - fixed DIV/0 in skew function
3/4 - added window lights, post baking hdlightsources for wall shadows
3/4 - added alpha adjustment for elevated floor shadows
3/7 - added CVar for player shadows on self
3/10 - minor bug fixes in shadow spawn code, added exception for BD headshottargets, pitched shadows
"Window" lights and wall shadows have been corrected for the pitch of the light source. In the case of decorations and flashlights, this is the height of the light; for sector light sources it is now the top and middle of the sector respectively. This can be seen here:

map11

Outside sky light casts primarily a downward shadow while the flashlight casts a wall shadow that is pitched. Down this rabbit hole I also corrected numerous bugs in spawning of shadow generators, some of which could improve performance. One significant change is to substitute an actor's Height property when the current state sprite texture is TNT1A0, which returns a height of 0. This enables shadows for xenomorphs in the Alien TC mod, for example. Height and sprite height aren't an exact match, but it's close enough in this case and avoids searching lumps for DECORATE or class definitions.

Should have a release soon after testing is completed. 8-)
DarkkOne
Posts: 270
Joined: Mon Jun 06, 2016 11:26 pm
Preferred Pronouns: No Preference
Operating System Version (Optional): Widnows 11
Graphics Processor: nVidia with Vulkan support

Re: Relighting v4.0155b - long shadows

Post by DarkkOne »

Those pitched wall shadows are _delicious_.
DarkkOne
Posts: 270
Joined: Mon Jun 06, 2016 11:26 pm
Preferred Pronouns: No Preference
Operating System Version (Optional): Widnows 11
Graphics Processor: nVidia with Vulkan support

Re: Relighting v4.0155b - long shadows

Post by DarkkOne »

Okay, noticed this in Strife: A bridge came up out of water, and that bridge was reflective even though that flat isn't normally reflective when used elsewhere in the level. I assume because the water was reflective, and it maintained that property after it changed appearance?
User avatar
Hey Doomer_
Posts: 414
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.0155b - long shadows

Post by Hey Doomer_ »

DarkkOne wrote: Sun Mar 12, 2023 4:05 am Okay, noticed this in Strife: A bridge came up out of water, and that bridge was reflective even though that flat isn't normally reflective when used elsewhere in the level. I assume because the water was reflective, and it maintained that property after it changed appearance?
Correct. This is a known issue with the mod, as initially all sectors with the same texture are flagged. This is also noticeable in the rising nukage pit in E1M3 and the lowering donut in E1M2. So this is an issue I have to fix and haven't gotten around it.
User avatar
Hey Doomer_
Posts: 414
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.0155b - long shadows

Post by Hey Doomer_ »

Progress v4.0156b

I've done more work on pitched shadows and directional shadows. (I may have walked around my house with a flashlight. :) ) I'm trying to work into wall shadows a difference between harsh lighting that is directional (from a missile, flashlight, etc) vs. ambient light sources. Environmental shadows are diffused as light reflects off surfaces and scatters. Casting a bright light on an object negates that effect and generally causes a shadow to be sharper and darker. This is a reason photographers use reflectors in a session.

Directional lighting is impossible in GZDoom - it works off a flat BSP and bleeds through walls - but the pitch of the player, pitch of shadow caster to the light, and type of light (diffuse or harsh) are fair game. Thus directional shadows are possible. I've added player pitch and increased shadow alpha for harsh lighting.

Examples:

e4m7
map10

This has to be somewhat exaggerated with shortcuts for performance; the closest and most powerful light sources are used instead of all visible light sources. Much of the time that is sufficient. There is no way to make a sprite shadow diffuse, although alpha transparency helps.

I don't believe any of the above affects performance. All I've done is included two more variables. Still looks very cool. 8-)
User avatar
Hey Doomer_
Posts: 414
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.0156b - many improvements

Post by Hey Doomer_ »

Posted v4.0156b - pretty much what it says in the above. I tested this by playing through the first few levels of Doom, the first map of Heretic, MAP01 for Brutal Doom, several custom maps, and the Aliens TC.

Let me know what you think!

Edit - note that in correcting bugs I changed the default minimum sprite size to 5.0. This allows items such as shotgun shells, for example, to cast shadows...
DarkkOne
Posts: 270
Joined: Mon Jun 06, 2016 11:26 pm
Preferred Pronouns: No Preference
Operating System Version (Optional): Widnows 11
Graphics Processor: nVidia with Vulkan support

Re: Relighting v4.0155b - long shadows

Post by DarkkOne »

Hey Doomer_ wrote: Sun Mar 12, 2023 10:39 am
map10

This has to be somewhat exaggerated with shortcuts for performance; the closest and most powerful light sources are used instead of all visible light sources. Much of the time that is sufficient. There is no way to make a sprite shadow diffuse, although alpha transparency helps.

I don't believe any of the above affects performance. All I've done is included two more variables. Still looks very cool. 8-)
That looks amazing. I'm so excited to try this later.
DarkkOne
Posts: 270
Joined: Mon Jun 06, 2016 11:26 pm
Preferred Pronouns: No Preference
Operating System Version (Optional): Widnows 11
Graphics Processor: nVidia with Vulkan support

Re: Relighting v4.0156b - many improvements

Post by DarkkOne »

Would it be possible to prioritize light-sources originating at the player, or at least weighing them more heavily? Often some other light source that seems less bright will create shadows while the Flashlight++ flashlight doesn't. While those other sources may be "brighter," I wouldn't be surprised if it ends up looking better if light sources either originating at the player, or that are between the player and the lit object, are weighted more, or are just given priority for creating shadows.
Ginji23
Posts: 14
Joined: Wed Aug 12, 2020 7:50 pm

Re: Relighting v4.0156b - many improvements

Post by Ginji23 »

Plutonia map17 crashes, no other wads loaded, Gzdoom 4.10.0:

Code: Select all

VM execution aborted: division by zero.
Called from hd_relighting_EventHandler.WorldLoaded at relighting v4.0156b.pk3:zscript/hd_relighting.zs, line 1573
User avatar
Hey Doomer_
Posts: 414
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.0156b - many improvements

Post by Hey Doomer_ »

Ginji23 wrote: Mon Mar 13, 2023 1:58 am Plutonia map17 crashes, no other wads loaded, Gzdoom 4.10.0:

Code: Select all

VM execution aborted: division by zero.
Called from hd_relighting_EventHandler.WorldLoaded at relighting v4.0156b.pk3:zscript/hd_relighting.zs, line 1573
Interesting. Doesn't crash for me, and that particular line should not throw a DIV/0 unless a sector light level is -1.

Code: Select all

double f = rl_Cvar.rl_sector_light_min.GetInt() / (light.CurSector.LightLevel + 1);
Did you change any of the default settings? Just curious.
User avatar
Hey Doomer_
Posts: 414
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.0156b - many improvements

Post by Hey Doomer_ »

DarkkOne wrote: Sun Mar 12, 2023 9:15 pm Would it be possible to prioritize light-sources originating at the player, or at least weighing them more heavily? Often some other light source that seems less bright will create shadows while the Flashlight++ flashlight doesn't. While those other sources may be "brighter," I wouldn't be surprised if it ends up looking better if light sources either originating at the player, or that are between the player and the lit object, are weighted more, or are just given priority for creating shadows.
Thanks for the suggestion!

I have noted this, and it is likely how dual shadows are coded. Each non-blocked shadow caster in front of the player within a certain distance runs a single thinker (an iterator object that advances through each object of a class) to check all light sources on the map. Seems inefficient, but that's just how all iterators work when objects are randomly added to an unsorted list. Since I don't have access to the BSP tree in ZScript I can't check one sector against another for visibility. I also don't use separate thinkers for different types of light (ambient vs. decoration, for example).

Most light sources are eliminated as being too distant before a hitscan check. The two closest and strongest light sources are used to cast shadows, which at present can create flickering shadows and shadows that appear to be at odds. Generally this approach works well for ambient lighting mixed with missiles such as doom imp balls, but it does seem to fall short at times with a flashlight mod.

A flashlight is already coded as a stronger light source, but it's just one source. I'm considering how to improve my crude approach to dual shadows, as it simply swaps the most for the next most until the end of the iterator is reached and then cycles through those to cast the shadows. Keep in mind that casting wall shadows also needs a line trace to see if and where a wall is. Just haven't spent a lot of time on it. The number of shadow casters running light iterators are certainly the biggest source of lag.
Ginji23
Posts: 14
Joined: Wed Aug 12, 2020 7:50 pm

Re: Relighting v4.0156b - many improvements

Post by Ginji23 »

Hey Doomer_ wrote: Mon Mar 13, 2023 2:40 am Did you change any of the default settings? Just curious.
Just attempted on a fresh instance of Gzdoom 4.10.0; all default settings. Same result.
User avatar
Hey Doomer_
Posts: 414
Joined: Tue Oct 18, 2022 1:59 am
Operating System Version (Optional): Windows 11
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Relighting v4.0156b - many improvements

Post by Hey Doomer_ »

Ginji23 wrote: Mon Mar 13, 2023 5:29 pm
Hey Doomer_ wrote: Mon Mar 13, 2023 2:40 am Did you change any of the default settings? Just curious.
Just attempted on a fresh instance of Gzdoom 4.10.0; all default settings. Same result.
My apologies, I was testing against a renamed version of the mod. I now get the same result. Sector 80, which has a light level of 0 on the map, does have a light level of -1 at this line and generates a DIV/0. Line 972 needs to be clamped to prevent this. Try changing to this:

Code: Select all

						sec.LightLevel = clamp(sec.LightLevel - int(secs[i].Height / 64), 0, sec.LightLevel);
This fixes it for the moment. I'll have to look closer to exclude any light levels can generate the error. Thanks for the catch!

Return to “Gameplay Mods”