Relighting v4.0165b - blurry shadows w/ rlassets

[Skrell]

Anyone know what setting in relighting causes strange black outlined "box" shadows around voxel items? I love relighting but also my voxels!

[Hey Doomer_]

Anyone know what setting in relighting causes strange black outlined "box" shadows around voxel items? I love relighting but also my voxels!

I did add code to disable sprite shadows for voxels, but you may have to turn off shadows in Settings. Voxels are models in GZDoom and so do not generate a FLATSPRITE actor. At some point it may be possible to pitch a voxel actor, in which case shadows should be possible. (I think the same thing happens in non-accelerated software rendering mode, which ignores the FLATSPRITE.) These are GZDoom issues. Can't be helped at this time.

I'll review the voxel code again. It reads voxel definitions and when one is spawned doesn't add a shadow inventory item that spawns the shadow FLATSPRITE actors. It may also be possible to create a duplicate of a voxel actor that isn't a voxel so the voxel generates sprite shadows from the duplicate... a voxel doppelganger of sorts. I still should know the sprite name.

I'll ponder that.

[Skrell]

Anyone know what setting in relighting causes strange black outlined "box" shadows around voxel items? I love relighting but also my voxels!

I did add code to disable sprite shadows for voxels, but you may have to turn off shadows in Settings. Voxels are models in GZDoom and so do not generate a FLATSPRITE actor. At some point it may be possible to pitch a voxel actor, in which case shadows should be possible. (I think the same thing happens in non-accelerated software rendering mode, which ignores the FLATSPRITE.) These are GZDoom issues. Can't be helped at this time.

I'll review the voxel code again. It reads voxel definitions and when one is spawned doesn't add a shadow inventory item that spawns the shadow FLATSPRITE actors. It may also be possible to create a duplicate of a voxel actor that isn't a voxel so the voxel generates sprite shadows from the duplicate... a voxel doppelganger of sorts. I still should know the sprite name.

I'll ponder that.

If it helps at all... It's not ALL voxels. I can't figure out what the pattern is. Also I disabled pickup shadows and that seemed to help somewhat

[Dan_The_Noob]

sky lights look good, is there a way to adjust JUST the sky light bleed though?

[Hey Doomer_]

sky lights look good, is there a way to adjust JUST the sky light bleed though?

Can you explain what you mean? All the flat colors are treated about the same and can be adjusted through the color settings... just not sure what you're getting at with the sky.

[Dan_The_Noob]

sky lights look good, is there a way to adjust JUST the sky light bleed though?

Can you explain what you mean? All the flat colors are treated about the same and can be adjusted through the color settings... just not sure what you're getting at with the sky.

the indoor lights colour bleed is ok. but say the red sky in Episode Inferno of Doom 1, it comes out completely red.
it doesn't REALLY matter, but would be nice to have an option to lower just the sky bleed amount.

[Hey Doomer_]

sky lights look good, is there a way to adjust JUST the sky light bleed though?

Can you explain what you mean? All the flat colors are treated about the same and can be adjusted through the color settings... just not sure what you're getting at with the sky.

the indoor lights colour bleed is ok. but say the red sky in Episode Inferno of Doom 1, it comes out completely red.
it doesn't REALLY matter, but would be nice to have an option to lower just the sky bleed amount.

Ah gotcha. I'll take a look at that

[Zaibatsu64]

Thanks for another great update.

I've found that I've unfortunately had to disable the colour bleeding option. This setting works well indoors, but it can lead to some odd results with the coloured skies. The sky should usually be the dominant lighting source in an outdoor scene, but sometimes the texture of the floor is used to determine the colour of the sector. There can be other issues when there's an overhang. I can provide pictures if it's helpful, that may be easier to understand (and easier to explain what I'm talking about).

The coloured skies add tons of atmosphere when everything is working as expected. There are many fringe cases and it must be very difficult to account for them in a way that will work universally. I can't credit you enough for the mod, it's so cleverly done.

[Hey Doomer_]

Thanks for another great update.

I've found that I've unfortunately had to disable the colour bleeding option. This setting works well indoors, but it can lead to some odd results with the coloured skies. The sky should usually be the dominant lighting source in an outdoor scene, but sometimes the texture of the floor is used to determine the colour of the sector. There can be other issues when there's an overhang. I can provide pictures if it's helpful, that may be easier to understand (and easier to explain what I'm talking about).

The coloured skies add tons of atmosphere when everything is working as expected. There are many fringe cases and it must be very difficult to account for them in a way that will work universally. I can't credit you enough for the mod, it's so cleverly done.

Interesting. This is unintentional. Can you give an example where floor texture determines the sky sector color?

In the meantime try changing 967 in relighting.zs to this:

Code: Select all

				else if (!sky && (fc.r + fc.g + fc.b + cc.r + cc.g + cc.b))

[Hey Doomer_]

Anyone know what setting in relighting causes strange black outlined "box" shadows around voxel items? I love relighting but also my voxels!

I did add code to disable sprite shadows for voxels, but you may have to turn off shadows in Settings. Voxels are models in GZDoom and so do not generate a FLATSPRITE actor. At some point it may be possible to pitch a voxel actor, in which case shadows should be possible. (I think the same thing happens in non-accelerated software rendering mode, which ignores the FLATSPRITE.) These are GZDoom issues. Can't be helped at this time.

I'll review the voxel code again. It reads voxel definitions and when one is spawned doesn't add a shadow inventory item that spawns the shadow FLATSPRITE actors. It may also be possible to create a duplicate of a voxel actor that isn't a voxel so the voxel generates sprite shadows from the duplicate... a voxel doppelganger of sorts. I still should know the sprite name.

I'll ponder that.

I don't see any issues as described with Relighting and voxels using Vulkan as is. What renderer are you using?

[Hey Doomer_]

Can you explain what you mean? All the flat colors are treated about the same and can be adjusted through the color settings... just not sure what you're getting at with the sky.

the indoor lights colour bleed is ok. but say the red sky in Episode Inferno of Doom 1, it comes out completely red.
it doesn't REALLY matter, but would be nice to have an option to lower just the sky bleed amount.

Ah gotcha. I'll take a look at that

The sky color derived from color settings against the palette is applied as is to the sky sector. Originally I set a darker shade to this, which made several outdoor sectors appear extremely dark. However, I wonder if this primary affects red sectors in Doom. (What? Red in Doom? Is there red in Doom's palette? Crazy.)

Code I'm experimenting with in relighting.zs:

Code: Select all

				if (sky && (cc.r + cc.g + cc.b))
				{
					if (cc.r > cc.g && cc.r > cc.b)
					{
						sec.SetColor(shade(cc, 2.5));
					}
					else
					{
						sec.SetColor(shade(cc, -0.8));
					}
				}

There are two related color functions, shade() and tint() borrowed from the original Relighting. In color theory these generally add black or white to a color, but in this case shade() multiplies uniformly while tint() multiplies perceptually. It's the latter function, for example, that makes the blue health bonus items stand out a little more...

In general Relighting adds indoor ceiling colors using different shades of the flat color. It's certainly possible to expose these as CVars, but feel free to experiment with the above and let me know what you think.

[Hey Doomer_]

WIWO v4.0151b

Code: Select all

v4.0151b

1/10 - added check for !sky with other colors
1/11 - corrected sky colors

Also a new option called "Smart Lighting." The idea is CVars are dynamically adjusted for a map depending on what kind of map it is (indoor, outdoor, bright, dark, etc). Still an idea but consider (comments in italics):

---

----------------------------------------

E4M1 - Hell Beneath - bright outside, dark inside

Sky color 203 89 10, area 3790, light 165, n 17
Indoor color 144 109 82, area 5838, light 128, n 64
]map e1m1

----------------------------------------

E1M1 - Hangar - bright outside, dark inside

Sky color 190 190 189, area 10978, light 250, n 7
Indoor color 164 139 123, area 20252, light 188, n 81
]map e2m1

----------------------------------------

E2M1 - Deimos Anomaly - almost no light from outside

Sky color 190 121 100, area 848, light 178, n 3
Indoor color 157 72 70, area 23542, light 172, n 89
]map map01

----------------------------------------

MAP01 - Entryway - large outside area without much additional light

Sky color 189 167 136, area 28258, light 200, n 10
Indoor color 178 170 165, area 11428, light 168, n 49
]map map03

----------------------------------------

MAP03 - The Gantlet - outside dim, mostly indoors and very dim

Sky color 189 167 136, area 9020, light 184, n 31
Indoor color 179 0 0, area 11902, light 138, n 90
]map map12

----------------------------------------

MAP12 - The Factory - mostly outside and dim, indoor areas dimmer

Sky color 230 208 187, area 75829, light 165, n 11
Indoor color 169 132 126, area 33245, light 162, n 151
]quit

I'll be working on tweaking lighting based on map "character" variables. Not sure of a release, but I should have something in a few days.

Update
Close to releasing. Still working on smart lighting. There should be more light sources in many maps with smart lighting, and at least one calculation has been corrected. This is a subtle enhancement for the most part. Performance impact is minimal or positive so far in testing.

[Skrell]

Anyone know what setting in relighting causes strange black outlined "box" shadows around voxel items? I love relighting but also my voxels!

I did add code to disable sprite shadows for voxels, but you may have to turn off shadows in Settings. Voxels are models in GZDoom and so do not generate a FLATSPRITE actor. At some point it may be possible to pitch a voxel actor, in which case shadows should be possible. (I think the same thing happens in non-accelerated software rendering mode, which ignores the FLATSPRITE.) These are GZDoom issues. Can't be helped at this time.

I'll review the voxel code again. It reads voxel definitions and when one is spawned doesn't add a shadow inventory item that spawns the shadow FLATSPRITE actors. It may also be possible to create a duplicate of a voxel actor that isn't a voxel so the voxel generates sprite shadows from the duplicate... a voxel doppelganger of sorts. I still should know the sprite name.

I'll ponder that.

I don't see any issues as described with Relighting and voxels using Vulkan as is. What renderer are you using?

Interesting! I haven't been using Vulkan, I've been using OpenGL! Is that the issue? So I just tested Vulkan being the preferred renderer. The voxel shadows were still messed up however when I disabled shadows for pickups it seemed to work better and I didn't see any "shadows" still attempting to be rendered for any voxels.

[Hey Doomer_]

I did add code to disable sprite shadows for voxels, but you may have to turn off shadows in Settings. Voxels are models in GZDoom and so do not generate a FLATSPRITE actor. At some point it may be possible to pitch a voxel actor, in which case shadows should be possible. (I think the same thing happens in non-accelerated software rendering mode, which ignores the FLATSPRITE.) These are GZDoom issues. Can't be helped at this time.

I'll review the voxel code again. It reads voxel definitions and when one is spawned doesn't add a shadow inventory item that spawns the shadow FLATSPRITE actors. It may also be possible to create a duplicate of a voxel actor that isn't a voxel so the voxel generates sprite shadows from the duplicate... a voxel doppelganger of sorts. I still should know the sprite name.

I'll ponder that.

I don't see any issues as described with Relighting and voxels using Vulkan as is. What renderer are you using?

Interesting! I haven't been using Vulkan, I've been using OpenGL! Is that the issue? So I just tested Vulkan being the preferred renderer. The voxel shadows were still messed up however when I disabled shadows for pickups it seemed to work better and I didn't see any "shadows" still attempting to be rendered for any voxels.

When I use OpenGL (AMD card) the voxels are flattened, like sprites. I just noticed this and switched to Vulkan. I don't normally test with voxels. There shouldn't be any voxel shadows, although I did see them with the flattened voxels in OpenGL. Not sure why.

[Dan_The_Noob]

how do you get the sky colour? or can you read the texture colour averages somehow? because i think sky colour could help with determining how bright it would be outside. just purely based on saturation.