Jump to content


Photo

Feature request: emissive materials/volumetric lights

emissive postprocess effects

193 replies to this topic

#151 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 08 October 2018 - 05:38 AM

 

I can add a second param to fastBlur  - what does it need to be - pixels/percent/etc?

 

IMO it should be in pixels as in image editing programs.

 

Although the most important question is: would you be able to use it for falloff images? You can blur your projection texture in Photoshop or Gimp, and the quality of projection texture rises with its resolution, there don't seem to be any limit to that. The problem is, there seems to be in-engine resolution limit for falloff images. That is causing the banding along the light beam:

obraz.png

 

Default light falloff texture (used even where there's no definition in the material) is 64x8 px and it looks like that when zoomed in:

obraz.png

 

Am I wrong to think that means blurring it won't do much, as you only have a few pixels and gradient steps to work with?


Edited by Judith, 08 October 2018 - 02:44 PM.


#152 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 20181 posts

Posted 08 October 2018 - 06:41 AM

can we not just repalce that texture with a better qaulity one.



#153 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 08 October 2018 - 06:43 AM

No we can't, I've already said I've tried it.



#154 HMart

HMart

    Advanced Member

  • Member
  • PipPipPip
  • 701 posts

Posted 08 October 2018 - 07:31 AM

Hey duzenko is this useful for the matter at hand?

 

http://fabiensanglar...ightScattering/



#155 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 08 October 2018 - 08:18 AM

Hey duzenko is this useful for the matter at hand?

 

http://fabiensanglar...ightScattering/

That stuff can only work against the clear sky



#156 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 08 October 2018 - 08:23 AM

 

IMO it should be in pixels as in image editing programs.

 

Although the most important question is: would you be able to use it for falloff images? You can blur your projection texture in Photoshop or Gimp, and the quality of projection texture rises with its resolution, there don't seem to be any limit to that. The problem is, there seems to be in-engine resolution limit for falloff images. That is causing the banding along the light beam:

 

 

Default light falloff texture (used even where there's no definition in the material) is 64x8 px and it looks like that when zoomed in:

 

 

Am I wrong to think that means blurring it won't do much, as you only have a few pixels and gradient steps to work with?

You can blur any image but I can't tell if it's going to make any difference with the falloff.

I'm puzzled about the stated engine limit - can you visualize it in your test map?

Make two non-volumetric lights with differently sized falloff images that cause similarly banded light interactions with walls, etc.

I will look at it.



#157 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 08 October 2018 - 08:25 AM

Sure, will do that after my work.



#158 HMart

HMart

    Advanced Member

  • Member
  • PipPipPip
  • 701 posts

Posted 08 October 2018 - 09:09 AM

That stuff can only work against the clear sky

 

Ok thanks for the info but what i was really asking is if the code or source code in there has some clue on how to smooth the volumetric beams, as IMO god rays are essentially the same thing, just trying to help.

 

And btw there's TDM missions with clear sky... ;P   



#159 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 08 October 2018 - 09:17 AM

 

Ok thanks for the info but what i was really asking is if the code or source code in there has some clue on how to smooth the volumetric beams, as IMO god rays are essentially the same thing, just trying to help.

 

And btw there's TDM missions with clear sky... ;P   

No problem

FYI the idTech 4 has no real skys. What you see in the missions is ceiling with a dynamic wallpaper.

Now one of the things I did in 2.06 was removing the sky ceiling surfaces from backend renderer. While technically we do have the sky now the frontend code still does not know that and has no support for open spaces.

I think the same goes for DarkRadiant.


  • HMart likes this

#160 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 08 October 2018 - 02:33 PM

https://we.tl/t-PCA6QpAigT

 

The light on the left uses default square1a image, the one on the right uses gradient made for 512px image, and actually banding is more visible with larger falloff image. I don't get it :blink:

 

obraz.png



#161 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 08 October 2018 - 03:11 PM

Also, I tested a number of falloff images on volumetric lights and, at least in this state, they actually don't seem to influence banding in the light shafts.

 

If there is anything that has substantial influence on them, it's the number of samples in the r_testvolumetric cvar. So maybe interpolating between the samples will give us what we need here?



#162 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 09 October 2018 - 02:00 AM

Ok, so I experimented with really high values, and it looks like r_testvolumetric 240-320 looks really good, but it obviously brings the framerate down.

 

obraz.png


  • Bikerdude and Aosys like this

#163 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 20181 posts

Posted 09 October 2018 - 07:31 AM

Does look very sexy though...



#164 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 09 October 2018 - 09:07 AM

https://we.tl/t-PCA6QpAigT
 
The light on the left uses default square1a image, the one on the right uses gradient made for 512px image, and actually banding is more visible with larger falloff image. I don't get it :blink:

Try

image_useCompression 0
reloadImages all

I believe all images that start with "lights/" aren't allowed to compress.

If the above worked for you then you might want to put falloff_test_512px under the "lights/" path inside the .pk4 (see the TDM assets file structure for reference).

Also, I don't see why use the makeintensity here.

Theoretically forceHighQuality should disable compressing as well but I'm not sure where to put it for the falloff.
 


  • Judith likes this

#165 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8987 posts

Posted 09 October 2018 - 09:11 AM

Hmm.

 

Rather than disabling all compression, maybe add the "forceHighQuality" keyword to the material def for the light?


Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

(Yeah, shameless promotion... but traffic is traffic folks...)

#166 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 09 October 2018 - 09:25 AM

Yup, disabling compression makes the banding go away. So it's the in-engine thing, as I was using uncompressed greyscale TGAs for projection and falloff image. You can't use forceHighQuality in the global stage of the light material btw., you'll get the "unknown general material parameter" error. Anyway, it's a false lead, number of samples is the culprit.



#167 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 09 October 2018 - 09:40 AM

Hmm.

 

Rather than disabling all compression, maybe add the "forceHighQuality" keyword to the material def for the light?

Surely I did not mean to disable it completely :)

Just to test if it makes the banding to go away. The simplest workaround seems to be the special lights path to image.



#168 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 10 October 2018 - 03:25 AM

I believe all images that start with "lights/" aren't allowed to compress.

If the above worked for you then you might want to put falloff_test_512px under the "lights/" path inside the .pk4 (see the TDM assets file structure for reference).

Also, I don't see why use the makeintensity here.

Theoretically forceHighQuality should disable compressing as well but I'm not sure where to put it for the falloff.

 

I'm not sure that's true. I tried replacing the default falloff image in the lights folder with 512px version, and it had the same banding problems as above. The problem went away only after I disabled compression for all the images, as you suggested earlier.

 

It would be great to have something like forceHighQuality for falloff images in global stage of light material, as we could replace current falloff images with better ones to eliminate banding.


Edited by Judith, 10 October 2018 - 03:25 AM.


#169 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 10 October 2018 - 04:17 AM

 

I'm not sure that's true. I tried replacing the default falloff image in the lights folder with 512px version, and it had the same banding problems as above. The problem went away only after I disabled compression for all the images, as you suggested earlier.

 

It would be great to have something like forceHighQuality for falloff images in global stage of light material, as we could replace current falloff images with better ones to eliminate banding.

I would have to see how exactly you did that - try putting the 512px version in the test map and if it's still compressing then I will look.


  • Judith likes this

#170 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 10 October 2018 - 04:18 AM

Will do in the afternoon.



#171 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 12 October 2018 - 02:49 AM

Sorry, won't have any spare time to do this until next Tuesday. But the issue is pretty straightforward: with image_useCompression set to 1 (by default), the engine compresses all textures in-game until told otherwise (which is good). That includes textures in lights/ folder, so both light falloff images and projection textures. Now, light materials use stages in similar fashion to surface materials: they have global stage (with light falloff image), and image stage (with projection texture), both with their specific keywords. While image stage has a keyword that switches off the compression (forceHighQuality), the global stage does not. So, to eliminate banding caused by falloff image compression, we'll need an equivalent of forceHighQuality for global stage, as this keyword is only accepted at image stage.

 

Edit: Or, since it's hard to imagine that you'd want this kind of banding for any of TDM lights, you could try to disable in-engine compression for global stage images. That would improve quality of all TDM lights without the need to update all stock light materials with new global keyword.


Edited by Judith, 12 October 2018 - 03:01 AM.


#172 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 12 October 2018 - 03:21 AM

Sorry, won't have any spare time to do this until next Tuesday. But the issue is pretty straightforward: with image_useCompression set to 1 (by default), the engine compresses all textures in-game until told otherwise (which is good). That includes textures in lights/ folder, so both light falloff images and projection textures. Now, light materials use stages in similar fashion to surface materials: they have global stage (with light falloff image), and image stage (with projection texture), both with their specific keywords. While image stage has a keyword that switches off the compression (forceHighQuality), the global stage does not. So, to eliminate banding caused by falloff image compression, we'll need an equivalent of forceHighQuality for global stage, as this keyword is only accepted at image stage.

 

Edit: Or, since it's hard to imagine that you'd want this kind of banding for any of TDM lights, you could try to disable in-engine compression for global stage images. That would improve quality of all TDM lights without the need to update all stock light materials with new global keyword.

I still believe in never compressing images in the "lights/" path. I wonder if you can prove me wrong with the test map.



#173 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 12 October 2018 - 03:30 AM

The link is in this post actually: http://forums.thedar...e-7#entry428641

 

And you can see it on the image. Higher res falloff image gets compressed. Then, try setting image_useCompression to 0 and load the map again:

obraz.png

 

Hmm, it still kind of sucks, but the green/purple hue from compression is gone. Maybe it needs better falloff image.



#174 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 12 October 2018 - 03:37 AM

The link is in this post actually: http://forums.thedar...e-7#entry428641

 

And you can see it on the image. Higher res falloff image gets compressed. Then, try setting image_useCompression to 0 and load the map again:

 

 

Hmm, it still kind of sucks, but the green/purple hue from compression is gone. Maybe it needs better falloff image.

AFAIR the falloff image in that version did not start with 'lights/', did it?



#175 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1593 posts

Posted 12 October 2018 - 03:43 AM

When I move the falloff image to lights/ folder:

obraz.png

 

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





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