Jump to content
The Dark Mod Forums

Messin with shaders


totallytubular

Recommended Posts

On 6/11/2021 at 10:15 AM, nbohr1more said:

The posterization is fixed in Stencil Shadows mode but still persists in Shadow Map mode.

I will have to go back and review again since the lighting in shadow map mode is not as good as stencil mode

in the default shaders anyway. ( If you can fix that it will remove one of the hurdles to moving to exclusively shadow map mode.)

Also, puddles in "No Honor Among Thieves" are spazzing out and alpha leaves on trees are flickering different brighness values.

Edit:

Never-mind about the flickering trees. This appears to be a general bug in Stencil Shadows in SVN (sorry).

Can you post a pic of the posterization you're seeing? I need some place to reference to tell if I'm fixing it or not.

See if the shadow map tweak I made fixes it.

~~~~~~~~~~~~~~~~~~

v 0.92

  • fixed puddles
  • tweaked shadow map (not sure if it fixes anything)

Puddles were spazzing from the MIN_AMBIENT_LIGHT amount I try to add to diffuse light color to keep it from being pitch black. Not sure why it spazzes out. I commented out that part of the ambient frag shader until I can think of a way to do that w/o spazzes.

I looked at shadow maps. I'm not sure where the posterization issue is, but the cubemap facing function seems to be doing the wrong values in a few spots. I added a new version of the function that emulates what khronos has in the OpenGL pdf for cubemaps. I'm not sure if it fixes anything or not. I dont' notice a difference when I flip between it and the original TDM version.

glprogs.stages.interaction.092.zip

  • Like 1
Link to comment
Share on other sites

v 0.92b

  • shadow map texSize pre-calc'ed one time
  • Filmic Worlds LdotH optimization included in PBR (switch it on/off with #define PBR_OPTIMIZE in funcs file)

Stared at the shadow map fs shader a little more, and noticed texSize is calculated in the main() for shadowResolution, then calculated in the shadow Atlas functions again. Made it where main() calc's it one time, and passes it to the Atlas functions. Real minor change, but the atlas functions are called over and over in soft shadow loops. So, just in case compiler doesn't notice a one-n-done value is done over and over, pulled it out of the loops.

I also forgot that I implemented the Filmic Worlds LdotH Visibility GGX PBR optimization in 0.92. Basically, instead of having to calculate a GGX "arm" for NdotL and for NdotV, it just has to calc one for LdotH then square it. Helps cut down on calculations. It makes the PBR a bit brighter, but the results look acceptable.

 

 

glprogs.stages.interaction.092b.zip

Link to comment
Share on other sites

So, new challenge...

I'm trying to implement simple post-processing volumetric lighting as per Nvidia's GPU Gems...

https://developer.nvidia.com/gpugems/gpugems3/part-ii-light-and-shadows/chapter-13-volumetric-light-scattering-post-process

It's a simple plug-n-play algorithm to shove into the post-processing pipeline (the /glprogs/tonemap.fs file).

My idea is to create very faint god-rays for moonlighting. We already have hand-placed god-rays for direct-lighting. So, just wanted to have very faint highlighting for overhead moon light as well.

Issue I'm running into is the algorithm needs a light direction.

I got into tonemap.vs, and tried calculating a var_WorldLightDir (like the way interaction.common.vs does for shadowmaps). I removed the parts in the calcs needing model matrix, b/c I just try to get a basic light direction for scene w/o model impact.

So.. like this...

//	var_WorldLightDir	= (params[attr_DrawId].modelMatrix * attr_Position).xyz - u_globalLightOrigin;
	var_WorldLightDir	= attr_Position.xyz - u_globalLightOrigin.xyz;

I can't pull in params w/o shader crashing. The u_globalLightOrigin uniform doesn't seem set for the post-processing tonemap shader. So, all the god rays just dump into the lower-left corner regardless of view angle.

Is there another global light direction that exists for post-proc? Or, is that something the would require fiddling with the game engine?

Link to comment
Share on other sites

Unfortunately, if a parameter is not present in a shipped shader, it is almost certainly not prepared for that shader and can therefore not be added without changes to the engine.

Given that we have multiple lights in the game, it wouldn't even be clear which one to send to a post-processing stage.

Link to comment
Share on other sites

sikkmod for Doom 3 afaik has post process godrays, so is apparently possible the problem, is that afaik he modified the engine c++ code to support that and his shaders are ARB and not GLSL... 

cabalistic, not that I'm a expert in this stuff but I don't see why a single directional light, couldn't be marked has the "sun" direction and its light origin, used for the effect, could be done perhaps by requiring that it be named that particular name, "sun".

I assume not many mission developers over used directional lights perhaps one or two are used and I assume a few even name it "sun" but I could be totally wrong. 

Edited by HMart
Link to comment
Share on other sites

3 hours ago, totallytubular said:

So, new challenge...

I'm trying to implement simple post-processing volumetric lighting as per Nvidia's GPU Gems...

https://developer.nvidia.com/gpugems/gpugems3/part-ii-light-and-shadows/chapter-13-volumetric-light-scattering-post-process

It's a simple plug-n-play algorithm to shove into the post-processing pipeline (the /glprogs/tonemap.fs file).

My idea is to create very faint god-rays for moonlighting. We already have hand-placed god-rays for direct-lighting. So, just wanted to have very faint highlighting for overhead moon light as well.

Issue I'm running into is the algorithm needs a light direction.

I got into tonemap.vs, and tried calculating a var_WorldLightDir (like the way interaction.common.vs does for shadowmaps). I removed the parts in the calcs needing model matrix, b/c I just try to get a basic light direction for scene w/o model impact.

So.. like this...


//	var_WorldLightDir	= (params[attr_DrawId].modelMatrix * attr_Position).xyz - u_globalLightOrigin;
	var_WorldLightDir	= attr_Position.xyz - u_globalLightOrigin.xyz;

I can't pull in params w/o shader crashing. The u_globalLightOrigin uniform doesn't seem set for the post-processing tonemap shader. So, all the god rays just dump into the lower-left corner regardless of view angle.

Is there another global light direction that exists for post-proc? Or, is that something the would require fiddling with the game engine?

 

2 hours ago, cabalistic said:

Unfortunately, if a parameter is not present in a shipped shader, it is almost certainly not prepared for that shader and can therefore not be added without changes to the engine.

Given that we have multiple lights in the game, it wouldn't even be clear which one to send to a post-processing stage.

 

1 hour ago, HMart said:

sikkmod for Doom 3 afaik has post process godrays, so is apparently possible the problem, is that afaik he modified the engine c++ code to support that and his shaders are ARB and not GLSL... 

cabalistic, not that I'm a expert in this stuff but I don't see why a single directional light, couldn't be marked has the "sun" direction and its light origin, used for the effect, could be done perhaps by requiring that it be named that particular name, "sun".

I assume not many mission developers over used directional lights perhaps one or two are used and I assume a few even name it "sun" but I could be totally wrong. 

See this thread:

 

@duzenko implemented volumetric lights in his branch. Did this ever get merged to Trunk?

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

 

http://www.indiedb.com/mods/the-dark-mod

 

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

Link to comment
Share on other sites

Probably because those are very different things. duzenko's attempt was actual volumetric lighting calculated from shadow maps, not a fake post-process effect. But no, it was never merged due to performance being poor. At some point, we may want to try that again.

Link to comment
Share on other sites

7 hours ago, duzenko said:

And the mappers did not show much interest

Do they not realize volumetric lighting would make their job easier? It does all the work in creating god rays w/o having to hand-place them.

 

9 hours ago, cabalistic said:

Probably because those are very different things. duzenko's attempt was actual volumetric lighting calculated from shadow maps, not a fake post-process effect. But no, it was never merged due to performance being poor. At some point, we may want to try that again.

I wanted to try real volumetric lighting via shadowmaps, but that's beyond me. (IE: not sure how to implement it, and reached my level of incompetence trying to wrap my head around it .. kept finding a lot of Unity examples, and not sure how to translate that into non-Unity). That's why I focused on the easier post-processing version.

I can understand the performance issue ... Fallout 4 was Nvidia's big "look at our volumetric lighting using shadow maps!" example, and I remember having awful performance with FO4 with that turned on while using a GTX760.

As more TDM graphics get offloaded from CPU / game engine to GPU / shaders, maybe there will be a time when there's a performance surplus folks would then be willing to rethink spending on cadillac features like volumetric lighting.

Since I've spent time farting with lighting, just thought I'd try to bolt on a cheap version and see how it goes.

Edited by totallytubular
Link to comment
Share on other sites

8 hours ago, duzenko said:

And the mappers did not show much interest

I wandered through the Bloom / Volumetric Lights thread, and came across the link to your github

https://github.com/duzenko/darkmod-experiments

I wanted to check out your Volumetric Light shaders, but don't see a "glprogs" folder anywhere (?)

 

When researching volumetric lights, I came across a a lot of different sites talking about various ways to do them and optimize them.

Maybe I can stare-n-compare to see if I can find a way to tweak them?

Link to comment
Share on other sites

1 hour ago, totallytubular said:

I wandered through the Bloom / Volumetric Lights thread, and came across the link to your github

https://github.com/duzenko/darkmod-experiments

I wanted to check out your Volumetric Light shaders, but don't see a "glprogs" folder anywhere (?)

 

When researching volumetric lights, I came across a a lot of different sites talking about various ways to do them and optimize them.

Maybe I can stare-n-compare to see if I can find a way to tweak them?

They are very much incompatible with 2.09

The C++ infrastructure does not exist, so nothing to tweak really

Quote

Do they not realize volumetric lighting would make their job easier? It does all the work in creating god rays w/o having to hand-place them.

Mappers welcome to discussion, but my guess is we already have a fire particle and fog for this effect

volumetric.fs volumetric.vs

  • Like 1
Link to comment
Share on other sites

v 0.93

  • LdotH used for BRDF Fresnel, too, if PBR_OPTIMIZE switched on

Really minor update.

Stumbled across a presentation on "Physically Based Lighting for Black Ops" (SIGGRAPH 2011) that made the distinction between Fresnel for mirror/cubemap that uses NdotV or NdotL, and Fresnel for BRDF microfacet that uses VdotH or LdotH.

Since the FilmicWorlds optimization already does LdotH, I just added LdotH Fresnel to the optimization path.

So...

Optimization off...

  • VdotH gets calc'ed
  • Fresnel uses VdotH
  • Visibility calc's 2 arms, one for NdotV, one for NdotL

Optimization on...

  • LdotH gets calc'ed
  • Fresnel uses LdotH
  • Visibility calc's 1 arm with LdotH then squares it

The LdotH specular is a bit brighter than the VdotH one.

glprogs.stages.interaction.093.zip

Link to comment
Share on other sites

  • 2 months later...

Can't believe I haven't found this thread earlier. Been interested in seeing people mess with the shaders to further improve the already great graphics we have. This will be fun to keep track of.

I should actually ask whether there's a guide on the basics of implementing your own shader. Asking as I really want Depth of Field as a feature, possibly even motion blur later on... since no one wanted to pick those up I was somewhat considering trying to integrate DoF myself to gain some coder experience in this area. I assume it will require editing the engine of course, and that we have no way of automatically loading shaders from a directory or with a script function.

Link to comment
Share on other sites

You can create an overlay and apply your own GLSL to that overlay but such effects are better handled by integrating them directly into the engine since you can better optimize what the shader is executed against.

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

 

http://www.indiedb.com/mods/the-dark-mod

 

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

Link to comment
Share on other sites

2 hours ago, nbohr1more said:

You can create an overlay and apply your own GLSL to that overlay but such effects are better handled by integrating them directly into the engine since you can better optimize what the shader is executed against.

Can it be first implemented as an overlay for testing then into the engine if accepted? Or do overlay and engine shaders use different and incompatible structures?

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

      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.
      · 0 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
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...