Jump to content
The Dark Mod Forums

Feature request: emissive materials/volumetric lights


peter_spy

Recommended Posts

 

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
Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

 

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.

  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

 

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

 

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.

  • Like 1
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

The link is in this post actually: http://forums.thedarkmod.com/topic/19659-feature-request-emissive-materialsvolumetric-lights/page-7?do=findComment&comment=428641

 

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.

Link to comment
Share on other sites

The link is in this post actually: http://forums.thedarkmod.com/topic/19659-feature-request-emissive-materialsvolumetric-lights/page-7?do=findComment&comment=428641

 

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?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...