Jump to content


Photo

Feature request: emissive materials/volumetric lights

emissive postprocess effects

193 replies to this topic

#176 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 12 October 2018 - 08:00 AM

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?



#177 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 12 October 2018 - 08:06 AM

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 by Judith, 12 October 2018 - 08:06 AM.


#178 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 13 October 2018 - 12:47 AM

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/T..._load.cpp#L1353



#179 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 13 October 2018 - 03:35 AM

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

 

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


Edited by Judith, 13 October 2018 - 03:43 AM.


#180 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 13 October 2018 - 08:13 AM

It doesn't make any difference, I guess that's because the image already is a greyscale texture. https://modwiki.xnet...ogram_function)
 
That makeintensity keyword was unnecessary, I didn't check what it does until now.

And same banding?

#181 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 13 October 2018 - 09:47 AM

Yup, no change.

#182 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 13 October 2018 - 01:19 PM

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?


  • Judith likes this

#183 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 14 October 2018 - 02:57 AM

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 by Judith, 14 October 2018 - 02:57 AM.


#184 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 15 October 2018 - 06:25 AM

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.



#185 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 15 October 2018 - 07:33 AM

 

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.



#186 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 15 October 2018 - 07:58 AM

 

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.


  • Bikerdude and Judith like this

#187 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted Yesterday, 10:02 AM

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...iew?usp=sharing



#188 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted Yesterday, 10:07 AM

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



#189 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted Yesterday, 10:11 AM

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.



#190 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted Yesterday, 10:17 AM

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


#191 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted Yesterday, 11:16 AM

 

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.



#192 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted Yesterday, 12:19 PM

Try now (same download link)



#193 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted Yesterday, 12:51 PM

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.

obraz.png

obraz.png


Edited by Judith, Yesterday, 12:58 PM.


#194 Jetrell

Jetrell

    Member

  • Member
  • PipPip
  • 80 posts

Posted Yesterday, 08:42 PM

...


Edited by Jetrell, Yesterday, 09:09 PM.




Reply to this topic



  



Also tagged with one or more of these keywords: emissive, postprocess, effects

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users