Feature request: emissive materials/volumetric lights

[duzenko]

When I move the falloff image to lights/ folder:

 

Green/purple hue from compression is still there, although a bit less noticeable, I think? Maybe lights folder uses highquality instead of forceHighQuality?

I would like to have the .pk4 to check that.

Do you have postprocessing on?

[peter_spy]

There you go: https://we.tl/t-MppoYCbXfR

 

I might have postprocessing turned on here, but the only thing it does in that scene is increased contrast. Without PP it looks the same, just a tad softer. Also, it seems those horizontal streaks are from slight noise applied to falloff image to mask banding. Looks like like this isn't a good idea here.

Edited October 12, 2018 by Judith

[duzenko]

There you go: https://we.tl/t-MppoYCbXfR

 

I might have postprocessing turned on here, but the only thing it does in that scene is increased contrast. Without PP it looks the same, just a tad softer. Also, it seems those horizontal streaks are from slight noise applied to falloff image to mask banding. Looks like like this isn't a good idea here.

Thanks

 

Could you drop the makeintensity and see if makes any difference

 

The relevant original code: https://github.com/TTimo/doom3.gpl/blob/aaa855815ab484d5bd095f347163194ac569abcc/neo/renderer/Image_load.cpp#L1353

[peter_spy]

It doesn't make any difference, I guess that's because the image already is a greyscale texture. https://modwiki.xnet.fi/MakeIntensity_(Image_program_function)

 

That makeintensity keyword was unnecessary, I didn't check what it does until now.

Edited October 13, 2018 by Judith

[duzenko]

It doesn't make any difference, I guess that's because the image already is a greyscale texture. https://modwiki.xnet.fi/MakeIntensity_(Image_program_function)

 

That makeintensity keyword was unnecessary, I didn't check what it does until now.

And same banding?

[peter_spy]

Yup, no change.

[duzenko]

Sorry, I was wrong

The /lights path check only controls DDS file load - not the on-the-fly runtime compressing of tga's.

 

So, what is the desired behavior - always upload falloff images using an uncompressed format?

[peter_spy]

So, what is the desired behavior - always upload falloff images using an uncompressed format?

 

Yes. Once we got that, we can try to resize or remake falloff images to get rid of the banding in lights.

Edited October 14, 2018 by Judith

[duzenko]

That's easy to do.

However, I'm not sure we should invest in that.

Moving forward with the multi-light shader, we'd need all light textures be the same size.

Even better, not use light textures at all - replace them with math formula.

That should cover 90+% of all lights in missions.

 

In other words, I believe the mappers should plan their design with the assumption that their textures will be compressed.

That means, as little "highQuality" material keyword as possible.

I believe it has been abused to an extent where at some point we might need to start ignoring it.

 

When it comes to lights, mappers should either accept the compression glitches or make an effort of coming up with a formula replacement. No more reliance on sheer GPU horsepower. There are people with weaker GPU's than yours - and less RAM. Give them a chance to play your mission.

[peter_spy]

 

Even better, not use light textures at all - replace them with math formula.

That should cover 90+% of all lights in missions.

 

That would be awesome. Light banding isn't that bad, as long as the normalmap is quite strong, flat surfaces are the biggest problem. All in all, this seems like a distraction. We need to find a bridge between quality and performance for volumetric lights.

[duzenko]

 

That would be awesome. Light banding isn't that bad, as long as the normalmap is quite strong, flat surfaces are the biggest problem. All in all, this seems like a distraction. We need to find a bridge between quality and performance for volumetric lights.

The next thing I want to try is start sampling the view ray from the last solid surface rather that light frustum.

It should fix the visible banding caused by hard cutoff of samples by depth test.

[duzenko]

The next thing I want to try is start sampling the view ray from the last solid surface rather that light frustum.

It should fix the visible banding caused by hard cutoff of samples by depth test.

Done

Not sure if it actually helps any (but it should even if a bit )

To reduce banding caused by discarded samples in shadows: try to squeeze light frustum as close to the occluding silhouette as possible. The close the frustum is to shadow edge, the fewer samples get discarded.

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

[peter_spy]

Hmm, not sure what happened, but all the light shafts are gone now.

[duzenko]

Hmm, not sure what happened, but all the light shafts are gone now.

Load the map anew - quick saves might be incompatible with the new per-light source size I merged from svn.

[peter_spy]

I dmaped and launched the map from console.

 

Also, I got this message during the game launch:

WARNING:shaderCompileFromFile(glprogs/volumetric.fs) validation
0(66) : error C7616: global variable gl_ProjectionMatrix is removed after version 140
0(67) : error C7616: global variable gl_ModelViewMatrix is removed after version 140
0(141) : warning C7533: global variable gl_FragColor is deprecated after version 120

[duzenko]

 

I dmaped and launched the map from console.

 

Also, I got this message during the game launch:

WARNING:shaderCompileFromFile(glprogs/volumetric.fs) validation
0(66) : error C7616: global variable gl_ProjectionMatrix is removed after version 140
0(67) : error C7616: global variable gl_ModelViewMatrix is removed after version 140
0(141) : warning C7533: global variable gl_FragColor is deprecated after version 120

I see.

It did work on AMD - this is nVidia issue.

I will try it on Intel now.

[duzenko]

Try now (same download link)

[peter_spy]

They're back again

 

The second light (the projection texture) works as before, but first light (one using geometry) and the third one (transparency shadow map) has light shaft ignoring geometry. They do cut at geometry though, when I noclip out of the room.

Edited October 18, 2018 by Judith

[Jetrell]

...

Edited October 19, 2018 by Jetrell

[duzenko]

Fixed the light leak on the 'left' light.

As for the right light, I think you need to adjust the light frustum so it includes the entire window - not intersects it in the middle

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

[HMart]

If i use the exes from update 14 shadow maps get all burked if i use your exe shadow maps (and the volumetric lights) work very well !?

 

Now i used the exes from the update 14 and the shadow maps worked?! This is very odd.

Edited October 19, 2018 by HMart

[duzenko]

If i use the exes from update 14 shadow maps get all burked if i use your exe shadow maps (and the volumetric lights) work very well !?

 

Now i used the exes from the update 14 and the shadow maps worked?! This is very odd.

Could be glprogs out of sync in @nbohr1more's release

[peter_spy]

I can confirm that all light frustums collide with geometry now.

[duzenko]

Where are we on this? Does it need further improvements or can be merged to svn?

[peter_spy]

IMO it only needs performance optimization. With number of samples around 30, the performance is solid, but banding is too prominent. Something around 90 looks pretty good (for projection textures), but it's too performance-heavy. So either having 90 samples at the cost of 30 would be great, or maybe some interpolation between those 30 samples will look better.