193 replies to this topic

[Judith]

 

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:

 

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?

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

[Bikerdude]

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

[Judith]

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

[HMart]

Hey duzenko is this useful for the matter at hand?

 

http://fabiensanglar...ightScattering/

[duzenko]

Hey duzenko is this useful for the matter at hand?

 

http://fabiensanglar...ightScattering/

That stuff can only work against the clear sky

[duzenko]

 

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.

[Judith]

Sure, will do that after my work.

[HMart]

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   

[duzenko]

 

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.

[Judith]

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

 

[Judith]

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?

[Judith]

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.

 

[Bikerdude]

Does look very sexy though...

[duzenko]

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

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.
 

[nbohr1more]

Hmm.

 

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

[Judith]

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.

[duzenko]

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.

[Judith]

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.

[duzenko]

 

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]

Will do in the afternoon.

[Judith]

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.

[duzenko]

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.

[Judith]

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.

[duzenko]

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?

[Judith]

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?