[2.10] Volumetric Lights

[duzenko]

Dear mappers, please be aware of this decorative light option introduced in upcoming 2.10

It aims to highlight the light volume and produces something like the existing fog particle with the intended effect of better speed and arguably better visuals

It looks like this in game

The test map we have been testing recently is courtesy of Bikerdude: download

To enable this effect you will need to mark your light material with the volumetricLight keyword, like this

lights/test_mansion01_window04_vol
{	
	description "volumetricLight for mansion01 window04"
	volumetricLight
	{
		map	lights/mansion01_window04
		colored
		zeroClamp
	}
}

Volumetric lights use projection and falloff textures to generate the volumetric effect. With shadow maps on, they also take shadows in the account.

There's also an optional parameter after volumetricLight that toggles max speed vs decent look mode.

Credits:

• @peter_spy for the original test map and direction
• @Bikerdude for great support during the reintroduction effort this year
• @stgatilov for taking the implementation on a completely different quality level
• @all for being cool and awesome

[Guest]

Nice work! Ray quality looks much better than the last time we've worked on this.

[stgatilov]

Most likely, we will change the way volumetric lights are set up in beta210-03.

Instead of "volumetricLight" keyword in material, the "volumetric_light" entity spawnarg will be used.
There will be no need to create or fork material, just add a "volumetric_light" "1" on the light and you are done.

It seems that volumetric lights would be easier to use this way, and we'll have less material duplication.

[Wellingtoncrab]

Great! I already love this new feature!

If it’s not already been taken care of it also be great to pass the new spawnarg through the DR hot reload.

[kingsal]

These look great! @duzenkoI would definitely recommend these being a graphics feature if possible. I can see these tanking some machines. 

[Goldwell]

On 12/26/2021 at 3:43 AM, stgatilov said:

Most likely, we will change the way volumetric lights are set up in beta210-03.

Instead of "volumetricLight" keyword in material, the "volumetric_light" entity spawnarg will be used.
There will be no need to create or fork material, just add a "volumetric_light" "1" on the light and you are done.

It seems that volumetric lights would be easier to use this way, and we'll have less material duplication.

 

That's a much better way to implement it, great job!

 

I saw @Wellingtoncrab post on the discord channel of how the new cameras look with volumetric lights, and my god it's a huge step up in quality!

[duzenko]

9 hours ago, kingsal said:

These look great! @duzenkoI would definitely recommend these being a graphics feature if possible. I can see these tanking some machines. 

Originally I tied it to Level of details, but @stgatilov moved it to a new cvar, making it IMHO harder for 'normal' users to configure

[stgatilov]

Volumetric lights should not cost too much.
And if we render them to separate buffer (5850) in 2.11, the cost will be lowered even further.

Right now if someone has serious performance problems with them, he can use cvar.
And by the way, no one complained yet.

If it has to be tied to some existing main menu settings, I'd better tie them to soft shadows quality.
Because both soft shadows quality and volumetric quality define number of samples to use per-pixel, with more or less the same performance implications.

[duzenko]

4 minutes ago, stgatilov said:

Volumetric lights should not cost too much.
And if we render them to separate buffer (5850) in 2.11, the cost will be lowered even further.

Right now if someone has serious performance problems with them, he can use cvar.
And by the way, no one complained yet.

No one has complained because no existing mission features it yet

OTOH a cvar is better than nothing and we can return to this later

Quote

If it has to be tied to some existing main menu settings, I'd better tie them to soft shadows quality.
Because both soft shadows quality and volumetric quality define number of samples to use per-pixel, with more or less the same performance implications.

I still like LOD better for this 

[kingsal]

 

2 hours ago, stgatilov said:

Volumetric lights should not cost too much.
And if we render them to separate buffer (5850) in 2.11, the cost will be lowered even further.

Sorry, its not just about cost. They do not work correctly in stencil mode and will go through walls. So a player can be standing behind a wall and might expect to be fully visible.

So we're going to either need a menu setting or they need to be turned off in stencil mode or we're going to have gameplay problems.

[duzenko]

6 minutes ago, kingsal said:

 

Sorry, its not just about cost. They do not work correctly in stencil mode and will go through walls. So a player can be standing behind a wall and might expect to be fully visible.

So we're going to either need a menu setting or they need to be turned off in stencil mode or we're going to have gameplay problems.

For now I think mapper has to manually adjust the light so that it does not intersect any walls, etc

[kingsal]

Heres an example
Shadow maps:

Stencil:

[kingsal]

5 minutes ago, duzenko said:

For now I think mapper has to manually adjust the light so that it does not intersect any walls, etc

I dont think thats wise. We should just be turning them off in stencil mode. Isnt this part of the beta test? To debug this stuff?

EDIT heres a good example. A mapper wants to add them to a security camera which @Wellingtoncrabshowed an awesome example of. We can't do that if players are gonna use stencil mode and expect to get caught behind a wall...

[Dragofer]

Shouldn't it rather be fixed properly? Volumetric lights include shadowcasting, so why would wall shadows be excluded?

[stgatilov]

To me, volumetric light was a replacement for adding translucent frustum, which is typical in old missions.
Translucent geometry cannot compute shadows either.

Disabling all volumetric shadows with stencil shadows sounds too harsh: it is a nice graphical effect, even if it does not react to a guard passing by. And it does not affect gameplay, as far as I know.

[kingsal]

Just now, stgatilov said:

 And it does not affect gameplay, as far as I know.

It does effect gameplay unfortunately.

[stgatilov]

7 minutes ago, kingsal said:

It does effect gameplay unfortunately.

How?

It does not affect lightgem.

[kingsal]

8 minutes ago, stgatilov said:

How?

It does not affect lightgem.

It does effect the light gem:
https://www.dropbox.com/s/0ucaxcvk9rp4zqf/The Dark Mod 2.10_64 2021-12-27 02-15-23.mp4?dl=0

And even if it didnt we cant have players thinking they are going to be in light.. when they arent.

[stgatilov]

In simple cases, mapper can set light_start and light_end in such a way that light volume is clipped by a plane. You need to ensure (end - start) vector is orthogonal to wall plane, then put end point at the wall. Start point is put so that there is a plane parallel to the wall contaning both light source and start point. Yeah, rather messy...

Aside from that, maybe add spawnarg "volumetric_shadows_required"?
If you set it to 1, then volumetric light becomes disabled if shadows cannot be taken into account.

UPDATE: Of course, noshadows lights should always have volumetric lights.
I'm just worried about cases when mapper is not against shadows in general, but is OK that volumetric lights don't respect them...

 

[stgatilov]

After chatting with @kingsal, it seems there are two questions:

1. Do we need the case when light casts shadows but volumetric light can ignore them?
2. Which behavior should be made default for volumetric lights in stencil shadows mode: disable or enable with ignored shadows?

Previously volumetric lights were faked by adding some geometry with translucency / light textures.
Whenever you can use such a fake, you don't care that volumetric light ignores shadows, so it fits the case from p.1.

However, I'd agree that shadow-ignoring volumetric shadows can be a great surprise to a mapper which always tests the map with shadow maps. So perhaps default behavior should be "disable" in p.2.

Need more opinions from mappers.

[Wellingtoncrab]

I have to say the idea of avoiding geometry with these lights is of some surprise to me, as if you will forgive the pun that is where in my opinion these lights shine!

I have been using particles to fake “volumetric” effects for static sources like windows and spotlights and such, as I was not a fan of using textured geometry for this, which sounds like basically how this works in stencil. With some considerable advantage in that you have greater control over the shape of the particle effects via the material texture and light volume shape without modifying a def, though less control over the appearance of the particles themselves.

Though admittedly I have found using the volumetric material on directional lights from things like windows to be quite difficult to shape the light volume correctly - as you have to get the “light start” parameter just right otherwise the origin of the effect looks quite off.

Honestly though I think this effect is most transformative on moving lights which intersect geometry where the effect could not be “faked” at all. Like the dancing glow of a fire place in a dark room or the vision cone of a security camera sweeping across pillars. Though perhaps not intended, that is at least how I have been using them.

So to answer your second question, in my opinion if you are using a mode which doesn’t support volumetric lights or also if you have disabled it for performance reasons, I would default just display the light as if the volumetric light spawnarg/material flag was off.  

Maybe let the mapper consciously enable the fact they want to force the effect on ignoring shadows through a spawnarg.

As to your first question I have not encountered a circumstance like that yet. Given the particle generated is limited now to a sort of “illuminated dust” effect it’s harder for me to imagine, or I simply lack the creativity to see that circumstance yet. 

 

[Wellingtoncrab]

11 hours ago, stgatilov said:

Volumetric lights should not cost too much.

I am not as sure about this. I am not very good at judging the whole tdm perfomance thing given all the different lighting model and MSAA preferences and I do not have a particularly powerful machine. I might agree that with my settings I still tear through scenes with the volumetrics in them with lots of headroom, but they appear to me to be quite expensive even in simple scenes, especially as you get closer and the screen fills with alpha effects.

I mean I only have a 1650 mobile which is firmly in the "sucks" category - I would pay the cost for the effect personally. But it's enough I would probably lump into some group of settings which make it easier to disable if need be. 

[stgatilov]

What if we add "volumetric_noshadows" spawnarg, with the following values:

• "volumetric_noshadows 0": Volumetric light must respect shadows. If it cannot, then it is disabled/hidden.
• "volumetric_noshadows 1": Volumetric light must ignore shadows.
• "volumetric_noshadows -1": Volumetric light should use shadows if possible. If that's not possible, then it ignores shadows.

If this spawnarg is not set explicitly, then its value is defaulted to the value of "noshadows" spawnarg.

I think it covers all the possible cases, and its default behavior is "disable if stencil shadows are used".

The only case which won't work is noshadows = 1 with volumetric_noshadows = 0: shadow map won't be computed for this light, so volumetric light won't be able to use it. But I can't imagine who wants a light without shadows but with volumetric light having shadows...

[duzenko]

Ideally volumetric projected lights could have separate shadow implementation (just one projection instead of 6) and its shadow map would be used even when 'normal' lights are on stencil

@stgatilovCan you tell me what the problem with lightgem seems to be? I think we should just skip volumetric during the lightgem pass

[Spooks]

I don't think the volumetric light cost too much, granted i drop from 60FPS to 30, and to 20 if the samples go up to 32 or so, but I'm hoping there's more optimizations on the way. Couple of things I wanted to point out.

Number one is that there's a lot of overbrightening when the area of the volumetric light is big. Combine this with the bloom and you can get the game to look pretty ridiculous. The light in the first screenshot is only at about 40% max lightness. Turn it up to 80% and you can see that it just looks like white void. This is the same problem with the layering of the haze particles, and it's why I usually set my haze particle colors to something that's nearly black.

Could there be a separate color spawnarg for the godray part of the light? Or maybe just some "intensity 0.0 to 1.0" kind of spawnarg, for further control? To prevent this kind of thing happening. edit: Basically there's a disjoint where the color is controlling two "real life" things: the intensity of the light and the thickness of the presumptive atmosphere through which the light is traveling. These shouldn't really be coupled together.

Number two is the obvious and old thing where the skybox doesn't get affected by any of this. Wish that that could get sorted at some point since it's handicapping a lot of outdoor scenes with particles, and now with this.

 

Edited December 28, 2021 by Spooks