Feature request: emissive materials/volumetric lights

[duzenko]

IMO next thing is to make geometry occlude the light shaft. Maybe there should be a spawnarg similar to noshadows for this, so mappers can control it and disable it to improve performance.

You would need to add that to the test map for me to look at.

[peter_spy]

That first window in the test map already has a light behind it that is casting shadows through a window frame. If you add collision with geometry, you should see the difference there.

 

I wonder how this should be handled though, so it's not too complicated. Right now you can have volumetric light that does or doesn't cast shadows. Should we handle light shaft collision with geometry separately or maybe link it with noshadows spawnarg?

[peter_spy]

Also, you can already use volumetric option with omni lights, either with light textures like falloff_exp2:

 

Or with your own projection textures:

 

Duzenko, I hope you will be able to clean up light frustum lines and the banding someday, but even with that, the whole thing looks pretty cool in motion

[HMart]

...

 

All in all, this is performance heavy effect and should be used sparingly, for strong light sources like floodlights, or to simulate sunlight / moonlight, but definitely not for every light or every window.

 

Yes this should be used like you said mostly on windows looking directly to the sun or moon, or used in some interior lights to simulate a dusty foggy environment or some magical effect, etc.

 

Btw occlusion by geometry is pretty much standard in all volumetric effects on other engines i've used, how they do that is beyond me but it proves is not impossible.

 

 

How unity handles occlusion with simple objects like walls.

 

http://saladgamer.com/vlb-doc/comp-dynocclusion/

Edited September 28, 2018 by HMart

[Springheel]

That first window in the test map already has a light behind it that is casting shadows through a window frame. If you add collision with geometry, you should see the difference there.

 

I wonder how this should be handled though, so it's not too complicated. Right now you can have volumetric light that does or doesn't cast shadows. Should we handle light shaft collision with geometry separately or maybe link it with noshadows spawnarg?

 

It would make sense to link it to "noshadows" I would think. AI models, for example, have textures with "noshadow" applied, and then use a shadow mesh. If the lights use the actual geometry, that would be a bigger performance hit.

 

It also saves having to modify who knows how many material shaders.

[peter_spy]

Okay, that makes sense. Lights with volumetric keyword should have the light shaft colliding with geometry by default. Now major use scenarios will be roughly like this:

 

1) Mapper uses volumetric light that collides wth geometry, like the in first window in the test map (most expensive option)

2) Mapper uses the same light, but uses noshadows spawnarg on selected geometry, like that window frame, along with custom projection texture (less expensive, and you can e.g. place a light behind opaque glowing window to create a light shaft)

3) Mapper uses volumetric light with noshadows spawnarg and the light shaft ignores geometry (least expensive option, might be useful e.g. in areas without AI, so it doesn't break the illusion much).

 

As for the performance, I haven't tested it much, but having several volumetric lights or sitting inside a volumetric light cone and looking at other lights didn't cause any problems. I saw a big performance drop when two or more volumetric shadow casting lights were overlapping, or when the player was inside the radius of more than one of them. That problem was gone once I used noshadows in all these lights.

[peter_spy]

Other possibly interesting uses of volumetric light and projection textures in omni lights:

 

Also, as Duzenko mentioned, you can use volumetric keyword with intensity parameter, and it goes way higher than 0-1 range (I used, 10, 20, 40, 100, it all works). In practical terms, you could use such lights (along with noshadows, nospecular and nodiffuse) to imitate glow as well:

Edited September 29, 2018 by Judith

[Bikerdude]

@Judith, can you upload a test/demo mission with all of the work you have done thus far, including all the required files and executables?

[peter_spy]

Duzenko, how's progress on light shaft colliding with geometry? It would be really cool to see that in action

[duzenko]

Duzenko, how's progress on light shaft colliding with geometry? It would be really cool to see that in action

In TODO but it should be easy.

I want to fix at least some of the remaining shadowmaps bugs first.

Have you got the transparent surfaces working yet with shadows? I'd want to get that done first.

[peter_spy]

Alright, makes sense. Unfortunately no, I couldn't get transparency shadow maps to work, but I saw in your screenshot that it's there. I assume there's something wrong on my end, but I don't even know where to start looking.

[duzenko]

Alright, makes sense. Unfortunately no, I couldn't get transparency shadow maps to work, but I saw in your screenshot that it's there. I assume there's something wrong on my end, but I don't even know where to start looking.

I will need to test it on nvidia on my end at some point.

[peter_spy]

Ok, so this is definitely a problem on my end:

WARNING:shaderCompileFromFile(glprogs/interactionN.fs) validation
0(87) : error C7532: global function textureGather requires "#version 400" or later
0(87) : error C0000: ... or #extension GL_ARB_texture_gather : enable
0(87) : error C0000: ... or #extension GL_EXT_gpu_shader4_1 : enable
0(169) : warning C7533: global variable gl_FragColor is deprecated after version 120


WARNING:shaderCompileFromFile(glprogs/shadowMap.fs) validation
0(9) : error C7566: in blocks require #version 150 or later
0(9) : error C0000: ... or #extension GL_ARB_gpu_shader5 : enable
0(17) : warning C7533: global variable gl_FragColor is deprecated after version 120

Edited October 4, 2018 by Judith

[duzenko]

Some progress:

• merged svn changes into the volumetric branch
• shadow maps added to the volumetric light shader
• the shader compilation errors from the post above were fixed before today

https://drive.google.com/file/d/0B9OoHSmkeSeNZWdyZFliQkNsVTA/view?usp=sharing

 

Known issues: shadow map cracks and volumetric light gaps along the light frustum edges.

[peter_spy]

Alright, transparency shadowmaps work now Volumetric lights stopped working with r_shadows 1 though. There's also a visible difference between light intensity, while all lights share the same values:

 

[duzenko]

There's also a visible difference between light intensity, while all lights share the same values:

What is your current light material setup?

 

 

Volumetric lights stopped working with r_shadows 1 though.

Not sure what is better - ignore stencil shadows or disable the volumetric lights when they're on.

[peter_spy]

What is your current light material setup?

 

Here's latest version of the map https://we.tl/t-SGG1qKtFeR

 

I haven't changed much stuff. First light uses this material

lights/glowtest/light_shaft

{
	volumetric
    {
        forceHighQuality
        map    lights/falloff_exp2
        colored
        zeroClamp
	}
}

Second one uses projection texture, as it did before.

 

 

Not sure what is better - ignore stencil shadows or disable the volumetric lights when they're on.

 

Actually, stencil shadows seem to have better performance on my pc than shadow maps, at least for now. Shadow maps seem to be pretty GPU intensive right now.

Edited October 4, 2018 by Judith

[duzenko]

 

Here's latest version of the map https://we.tl/t-SGG1qKtFeR

 

I haven't changed much stuff. First light uses this material

lights/glowtest/light_shaft

{
	volumetric
    {
        forceHighQuality
        map    lights/falloff_exp2
        colored
        zeroClamp
	}
}

Second one uses projection texture, as it did before.

 

 

 

I believe the difference in light intensity is caused by different average brightness of textures/glowtest/lights/window_p2 and lights/falloff_exp2

[peter_spy]

Ok, will check that out tommorow.

[peter_spy]

Okay, the difference is actually in light shaft intensity, you can tweak that by setting it to 2 or 3. So that's not a problem.

 

Remaining problems:

 

Banding when light shaft collides with geometry:

 

 

It also happens with projection textures, but to smaller extent. You said you could work with standard textures to improve this, and IMO that will be enough. By default, all lights use lights/squarelight1a.tga image for falloff. Other most commonly used option is _nofalloff parameter, I think that stands for lights/zol_nofalloff.tga. If you could decrease banding for these two falloff images, that would be sufficient for most situations.

 

And until shadowmaps get optimized, maybe it's a good idea to leave the light shafts compatible with stencil shadows too? Right now shadowmaps use most of my GPU, regardless of map size or shadow quality/radius. Similar case here: http://forums.thedarkmod.com/topic/19257-testers-and-reviewers-wanted-bfg-style-vertex-cache/page-12?do=findComment&comment=428236 where the GPU use is 99% most of the time.

[duzenko]

Okay, the difference is actually in light shaft intensity, you can tweak that by setting it to 2 or 3. So that's not a problem.

 

Remaining problems:

 

Banding when light shaft collides with geometry:

AFAIK stencil shadows can't work with translucent materials (i.e. anything not writing to the depth buffer)

How bad is the banding when you disable post-processing and set gamma to 1?

[peter_spy]

This is with postprocess 0 and gamma 1:

[peter_spy]

In terms of performance, I could render the scene below in 60 fps with stencil shadows. With shadow maps the performance goes down to 30 fps and temperature on my GPU gets high. Soft shadows quality is very high, map size is 512.

 

[duzenko]

In terms of performance, I could render the scene below in 60 fps with stencil shadows. With shadow maps the performance goes down to 30 fps and temperature on my GPU gets high. Soft shadows quality is very high, map size is 512.

Stencil soft shadows is a dead end from my point of view. This particular scene is hardly a fair benchmark as well.

With shadow maps, try lowering the SS quality slider until you get back to 60.

[peter_spy]

I did some tests with shadow maps in full missions (like New Job or Volta), and with r_softShadowsQuality 14, r_softShadowsRadius 6, and r_shadowMapSize 512 the results are decent; the GPU use is between 40 and 70%. In that test scene however, GPU use is 99%. I'm guessing it's not shadow maps that are causing trouble here, but volumetric lights.