Relighting v4.0165b - blurry shadows w/ rlassets

[Hey Doomer_]

WIWO v4.0154b

Code: Select all

v4.0154b

2/7 - added +NOTELESTOMP to ghostlight actor

I keep pondering better lighting given GZDoom confines. There's this, but it seems to tank framerates and is still fired with the BSP. Very cool nonetheless.

So I'm experimenting with subtractive lights again. Example. I'm wondering if subtractive sector lights have a place in this context. A bit here and there...

The ghostlight actor problem above is most noticeable in TN_MAP30.

[Dan_The_Noob]

that bulletpuff lighting thing is very jank huh.

i am on the fence when it comes to subtractive lighting, because i feel like darkness should be the absence of light sources so should occur relatively naturally. but then with gzdooms limitations there are so spots that it could definitely work.
like MAP01 entry pillars or the impcage at the end of MAP01, though it's not overly lit anyway.

[cosmos10040]

Received the error below with beautiful doom.

VM execution aborted: division by zero.
Called from hd_relighting_EventHandler.WorldLoaded at relighting v4.0153b.pk3:zscript/hd_relighting.zs, line 1522
]

[Hey Doomer_]

Received the error below with beautiful doom.

VM execution aborted: division by zero.
Called from hd_relighting_EventHandler.WorldLoaded at relighting v4.0153b.pk3:zscript/hd_relighting.zs, line 1522
]

Looks like I missed that one. This is a sector with a 0 light level, I think. I'll check it out, thanks. In the meantime try changing the line to this:

Code: Select all

double f = rl_Cvar.rl_sector_light_min.GetInt() / (light.CurSector.LightLevel + 0.1);

[cosmos10040]

Received the error below with beautiful doom.

VM execution aborted: division by zero.
Called from hd_relighting_EventHandler.WorldLoaded at relighting v4.0153b.pk3:zscript/hd_relighting.zs, line 1522
]

Looks like I missed that one. This is a sector with a 0 light level, I think. I'll check it out, thanks. In the meantime try changing the line to this:

Code: Select all

double f = rl_Cvar.rl_sector_light_min.GetInt() / (light.CurSector.LightLevel + 0.1);

Worked!

[Hey Doomer_]

Posted v4.0154b

Code: Select all

v4.0154b

2/7 - added +NOTELESTOMP to ghostlight actor
2/9 - fixed DIV/0 calculation error
2/15 - added optional subtractive lighting
2/16 - changed lower area limit of conditional hdlightsource (performance)

The big change here is the addition of optional subtractive lighting to add nuanced shading to some areas. There's also some bug fixes and performance improvements. The subtractive lighting doesn't generally make sectors darker (although this is possible); if a sector is darker it is most likely due to other corrections related to v4.0153. Generally all of these changes are connected to the sidedef baking.

I have tested this in Doom, Doom II, Heretic, and several maps with complex geometry. Performance is good and may be improved in some maps. The subtractive lighting is limited to larger walls and doesn't seem to affect performance. It is tweaked by changing the ratio of the sidedef add and subtract values.

This is also dependent on the author's lighting. While I make corrections depending on placement of light sources, an area that is lit for no reason map stay that way to some degree. I'd rather leave it like that than attempt to reinterpret the author's intent.

As for screenshots, this pretty much speaks for itself. Many of the changes are subtle, and performance has improved in some areas. I was surprised in this shot where the Baron is completely obscured:

E2M3.png (48.74 KiB) Viewed 1262 times

Let me know what you think!

[Dan_The_Noob]

I know this is a small/unrelated suggestion.
but when you post a new version, can you plug the link into your latest post on here as well as the original post? just to make it quicker to grab it for us extra lazy enthusiastic types.

--EDIT--

I have a suggestion/idea but i don't know how possible it is.
would it be possible to bump up the minimum lighting in a room that is indoors and HAS light in it?

so you would need to check it's not connected to any sky or outdoor window somehow (not sure it's possible) and if it has a light (or a sector being brightened by relighting).

because rooms like the room on the left in the first hallway of MAP01 get very dark in contrast to the hallway itself.

also what do "sidedef add" and "sidedef sub" actually affect? like what does the 1-255 actually relate to?

--EDIT2--
setting "sidedef add" or "sidedef sub" to 0 causes an error.

[DarkkOne]

Okay, is there a readme or more detailed description of each of the options somewhere? I've been trying to figure out, for example, what the "Sprite -> Shadow" toggles do. I don't see an obvious difference where I thought I would (in the appearance of the shadows cast by players and monsters). And just in general, I'd like to read up on as much of it as possible, so I can tweak it. It looks gorgeous over all, but I'm weird and certain artifacts just kinda distract me, so I kinda want to try to tune it to like... look as good as I can without the bits that catch my eye necessarily being there anymore.

Also, it suggests that "0 = inf" for the amount of shadows, but I keep noticing that like... I only cast one player shadow, and it'll hard jump from one position to another as a new light source becomes the shadow-casting light source. Is that expected? I would've thought with 'infinite' shadows, I'd just have a shadow for each light source that had LoS on me, basically.

[Hey Doomer_]

I know this is a small/unrelated suggestion.
but when you post a new version, can you plug the link into your latest post on here as well as the original post? just to make it quicker to grab it for us extra lazy enthusiastic types.

--EDIT--

I have a suggestion/idea but i don't know how possible it is.
would it be possible to bump up the minimum lighting in a room that is indoors and HAS light in it?

so you would need to check it's not connected to any sky or outdoor window somehow (not sure it's possible) and if it has a light (or a sector being brightened by relighting).

because rooms like the room on the left in the first hallway of MAP01 get very dark in contrast to the hallway itself.

also what do "sidedef add" and "sidedef sub" actually affect? like what does the 1-255 actually relate to?

--EDIT2--
setting "sidedef add" or "sidedef sub" to 0 causes an error.

Good idea about the post! Thanks.

There are several things happening with a decorative light source in a room not otherwise lit or near a light source. Wall lighting is baked based on the visibility of the decorative light, and overall lighting is adjusted based on proximity to any sector light source with an assumption that this creates some ambient light. When a door is opened, sector light level is adjusted based on the brightness and sector volume of the light source area. Some or all of those factors may explain what you are describing. Baked wall lighting does NOT change when a door is opened, although I think it does respond to sector lighting changes.

Sidedef add and sidedef sub affect how bright / dark baked wall lighting is; I assumed this was in a range of 1-255 as I recall (positive or negative integers). I'll have to look at this, but I think I know where that DIV/0 error is when both are 0; this is related to this version I think. These affect how much or how little (how much negative) light is added; in turn this affects sector lighting adjustment and subtractive lights that are added. When I coded the subtractive lights I kept these values at the defaults, and in general I haven't tried playing with these values in different maps. I chose defaults that looked good at the time in Doom, Heretic, etc, but there could be different values that work better.

https://zdoom.org/wiki/Structs:Side

The property is Light. Flags are Side.WALLF_NOFAKECONTRAST | Side.WALLF_SMOOTHLIGHTING

[Hey Doomer_]

Okay, is there a readme or more detailed description of each of the options somewhere? I've been trying to figure out, for example, what the "Sprite -> Shadow" toggles do. I don't see an obvious difference where I thought I would (in the appearance of the shadows cast by players and monsters). And just in general, I'd like to read up on as much of it as possible, so I can tweak it. It looks gorgeous over all, but I'm weird and certain artifacts just kinda distract me, so I kinda want to try to tune it to like... look as good as I can without the bits that catch my eye necessarily being there anymore.

Also, it suggests that "0 = inf" for the amount of shadows, but I keep noticing that like... I only cast one player shadow, and it'll hard jump from one position to another as a new light source becomes the shadow-casting light source. Is that expected? I would've thought with 'infinite' shadows, I'd just have a shadow for each light source that had LoS on me, basically.

Thanks for commenting and kudos.

I haven't gotten around to an explanation of the options. On the list.

Sprite -> Shadow refers to how the player casts a shadow on a monster when close enough to do so. Cheap and subtle.

The number of shadows refers to the number generated, since these are expensive. Each shadow has a thinker checking for the brightest light source. Dual Shadows changes from one shadow per caster to two, so the maximum shadows per caster is two. This is true for the player as well, although you may not see it. These shadows often can look jittery depending on the light sources; I think this happens when two similar light sources are the same distance apart. Normally this isn't a big deal with everything moving.

Shadows are updated based on visibility to the player as you suggest, although it isn't line of sight. Anything in front of the player within the shadow distance updates its shadow position to reduce thinker chewing. (We want for example shadows cast around corners in front of the player.) This is also true for extra dynamic lights. These are also limited by whatever might be blocking the shadow. This is to avoid situations where a corpse might cast a shadow when a monster is standing in front of it, for example. All of this is to reduce thinker chewing in any one sector.

Thinkers iterate through everything of a certain class and are relatively inefficient. I've wondered if its worthwhile creating different light source objects for moving light sources such as missiles versus static light sources such as decorative lights. I'm unsure that would improve performance. Currently items are eliminated based on some simple calculations before applying a hit scan to the source, but it's still relatively expensive when there are many shadows in view.

Keep in mind that shadows in close proximity to a wall will also cast shadows on the wall, which creates another actor albeit one without a thinker. Shadows can be limited by sprite size, but this will lead to some odd effects depending on the geometry and whatever tricks are used to achieve a certain effect. Shadows are FLATSPRITEs or WALLSPRITEs and can't be clipped, so they extend upward or outward to their length regardless of geometry. Note there is also a FLATSPRITE bug in GZDoom regarding Z-order sorting that makes some sprites overlap the caster sprite (I think that's the issue). There aren't any ZScript workarounds for these issues. Ideally, for example, a FLATSPRITE should bend and cling to flats and textures. But they are just sprites.

As a universal mod I have coded very little specific information, so you'll also see shadows for flames and a few other oddities. Can't be helped as is.

The above is also true for GZDoom's built in sprite shadows, of course. They've just been squished and always pushed back a little to avoid these issues.

Hope that rather long explanation helps. Let me know if there are other options you are curious about.

[DarkkOne]

Just wanted to say, I *really* like the shadows cast on walls. Their pixels align with the wall texture pixels (or at least, did when I was staring at one), which, to me, is so much nicer than a lot of things look when they put things on walls.

[Someone64]

Getting a VM Abort when the titlemap of DoomRPG loads:
https://imgur.com/a/8qog5t9
(Imgur embed doesn't seem to be working...)
Using the latest GZDoom, load only the DoomRPG folder, Relighting, and Doom 2 and it will consistently happen. Doesn't happen when you actually get in-game.

[Hey Doomer_]

Getting a VM Abort when the titlemap of DoomRPG loads:
https://imgur.com/a/8qog5t9
(Imgur embed doesn't seem to be working...)
Using the latest GZDoom, load only the DoomRPG folder, Relighting, and Doom 2 and it will consistently happen. Doesn't happen when you actually get in-game.

Thanks, I'll check it out!

[Hey Doomer_]

WIWO for v4.0155b - more wall shadows

I'm working on splitting toggles for floor and wall shadow alpha transparency (in effect making it possible to see wall shadows and not floor shadows, for example) and enhancing wall shadows. Here's an example with slighting increased brightness and contrast to illustrate:

https://i.postimg.cc/W1m5dPhc/e1m1-wallshadows.gif

Currently wall shadows are an extension of a floor shadow when the floor shadow hits a wall that is not two sided. This avoids most situations where a wall shadow extends beyond the floor height of the adjoining sector. I'm experimenting with extending the theoretical shadow length to see what it hits and simply projecting a shadow on the wall. As you can see in the above, the zombieman on the right has a larger wall shadow, and the one on the left casts a larger wall shadow when the flashlight is turned on.

So far this looks pretty cool. No performance impact.

[Hey Doomer_]

Getting a VM Abort when the titlemap of DoomRPG loads:
https://imgur.com/a/8qog5t9
(Imgur embed doesn't seem to be working...)
Using the latest GZDoom, load only the DoomRPG folder, Relighting, and Doom 2 and it will consistently happen. Doesn't happen when you actually get in-game.

Is this in GZDoom or on Delta Touch?