Relighting v4.0165b - blurry shadows w/ rlassets

[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?"

[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.

[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.

[DarkkOne]

Those pitched wall shadows are _delicious_.

[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?

[Hey Doomer_]

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.

[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.

[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]

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.

That looks amazing. I'm so excited to try this later.

[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]

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

[Hey Doomer_]

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.

[Hey Doomer_]

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]

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.

[Hey Doomer_]

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!