Jump to content
The Dark Mod Forums

Messin with shaders


totallytubular
 Share

Recommended Posts

22 minutes ago, totallytubular said:

I really want to get a noise generation routine going, because it could be used to tone down the "wet / gloss look" of speculars while preserving the brightness / shine. I can't seem to figure that out, though.

Without injecting additional input into the shader (which would require code changes), your options for noise are limited. You could try to use the hash function that the SSAO shader is using; it calculates a "random" value based on the fragment's position:

	ivec2 screenPos = ivec2(gl_FragCoord.xy);
	// "random" rotation factor from a hash function proposed by the AlchemyAO HPG12 paper
	float randomPatternRotationAngle = mod(3 * screenPos.x ^ screenPos.y + screenPos.x * screenPos.y, 3.14159);

This gives a value in [0, PI), so you'll want to adjust that for whatever you need. Whether or not this particular pattern will look good for your intended use, I can't say...

Link to comment
Share on other sites

On 5/21/2021 at 5:09 PM, cabalistic said:

Without injecting additional input into the shader (which would require code changes), your options for noise are limited. You could try to use the hash function that the SSAO shader is using; it calculates a "random" value based on the fragment's position:


	ivec2 screenPos = ivec2(gl_FragCoord.xy);
	// "random" rotation factor from a hash function proposed by the AlchemyAO HPG12 paper
	float randomPatternRotationAngle = mod(3 * screenPos.x ^ screenPos.y + screenPos.x * screenPos.y, 3.14159);

This gives a value in [0, PI), so you'll want to adjust that for whatever you need. Whether or not this particular pattern will look good for your intended use, I can't say...

I'll give that random var a try when I get a chance.

Also, wasn't sure if the branching was worthwhile or not, but did it anyways. I see a lot of conflicting info about branching in shaders, mainly b/c stuff I find when I google is from 2010 when branching killed performance. OpenGL and DirectX have matured since then.

I'm gonna keep the logic branching in the BRDF, because it's being used to avoid div/0 if NdotV or NdotL are 0 without having to do hacky things like add 0.0001 to them.

Link to comment
Share on other sites

v 0.83

  • fake spec PBR path is back to adding to diffuse brightness again

I was playing Now & Then, and the lighting inside the museum was bleached out looking. Wasn't sure why. Then I remembered I had to add diffuse texture to ambient fake spec PBR to keep water from spazzing out. So, I added diffuse texture to direct light fake PBR, and that fixed the lighting.

But, then we're back to having...

  • diffuse texture * diffuse light color * fake spec PBR

.. and that adds to diffuse color once it's calculated

  • diffuse texture * diffuse light color * diffuse brightness * kd ratio

So, basically, it's back to factoring out to...

  • diffuse texture * diffuse color * ( diffuse brightness * kd ratio + fake spec PBR )

Real specs can just multiply by their specular light color and be good to go. But, fake specs need to multiply by diffuse light color (as spec light color replacement) and diffuse texture. Not sure why.

The BRDF takes the specular texture in, and generates an output that counts as the specular color texture / map & specular brightness already mul'ed together. So, it just muls by spec light color. But, for fake spec maps, it still wants a diffuse texture to make it look right. So, back to doing that.

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

  • got rid of PBR_FAKESPEC_IS_REALSPEC (b/c of above reason)
  • real speculars use 1-specular.rgb as roughness, fake specs use 1-diffuse.rgb .. this helps real speculars look a bit better
  • added #define PBR_RIMLIGHTS to add TDM's default rimlight/rimshine even when PBR is on in order to punch up lighting more if end-user wants.

PBR / BRDF takes rimlighting into account with fresnel. And, it does a decent job (eg: the columns on Training Mission have a nice crisp rimlight / rimshine .. walls tend to rimlight at an angle). But, other places it falls flat, like on ground textures that have fairly flat pavers.

So, by adding TDM's default direct light rimlight/rimshine on top of what PBR does, it helps enhance the edge-lighting more to make things pop.

This voids the warranty of the PBR being a "Conservation of Energy" model then, though. PBR's goal is to keep make sure the output light energy coming off a surface (as color & shine) doesn't exceed the input light energy coming from the light source hitting it. If we add in extra rimlight & rimshine, it voids that by magically creating more light energy out of thin air.

But, there's no rule saying PBR can't get enhanced after-the-fact. This is a fantasy video game, so the lighting can get kicked up a notch to help enhance light & shadow for player immersion.

The #define PBR_RIMLIGHTS is off by default (set to 0), so you'll need to change it to 1 if you want to switch that on.

 

glprogs.stages.interaction.083.zip

  • Like 1
Link to comment
Share on other sites

v 0.86

  • fake spec is now just mul'ing by light source color, and doesn't add to diffuse lighting or mul by diffuse texture

I thought about this for a while, and realized that by adding fake specular float to the diffuse light brightness, it was not keeping with PBR.

Here's a drawing I did up to reference for the discussion to follow...

tKkd7Gz.png

In PBR

  • specular equals the light from the light source reflected as-is.
  • diffuse equals the light reflected, but modified by the surface; some colors reflecting, some absorbing

Real speculars have an RGB texture. So, they can theoretically modify how the full-light color looks as it's reflected. (Usually in slight amounts. EG: if you look at each of the specular color channels on surfaces, the grayscale doesn't differ drastically. It just helps create subtle variations in shine).

Fake speculars are just float grayscales. So, they provide an even amount of reflection along all 3 color channels. This means the light source color is reflected as-is.

Our ratio for how much light reflected is specular vs diffuse is based on the Fresnel. The Fresnel is generated as part of the Cook-Torrance specular BRDF in the PBR model. Because the C-T model multiplies the Fresnel into it's equation, specular reflection ratio is already accounted for in the output value from the BRDF...

To put it simply.. the C-T BRDF outputs a specular value that accounts for...

  • specular texture
  • specular brightness (spec dot)
  • specular ratio (fresnel)

All it needs to do after coming out of the BRDF is multiply by the light source RGB.

Regardless of whether we used a real specular or a fake, all it needs to do coming out of the BRDF is multiply by a light source color. It doesn't need to take the diffuse texture into account.

By adding the fake spec output to the diffuse brightness instead of treating it like a stand-alone specular light, we're artificially boosting diffuse color reflection... and, we're breaking the PBR model. (IE: the spec has shifted to act as a surface color vibrancy boost instead of as the full light reflection it was meant to be).

EG:

let's say we had 25% fresnel. That means the specular reflects 25% of the total light energy off the surface. The other 75% is diffuse color. (diffuse ratio is just 1.0 - Fresnel. So, if we had a 25% fresnel, we have a 75% diffuse ratio.. this is keeping with the Conservation of Energy, which is a key point of PBR.. a surface can't reflect more light energy than it was lit with, b/c that would break the laws of physics by it magically creating energy/light out of thin air).

Let's say our color surface was bright red...

  • R = 100%
  • G = 0%
  • B = 0%

This means red is reflected completely while blue & green are absorbed by the surface completely.

If we add in our fake specular to our diffuse brightness dot, then the green & blue channels will get negated, which means the specular won't properly represent the light it's really trying to reflect...

  • R = 100% diffuse color * 75% diffuse ratio * ( surface brightness + spec )
  • B = 0% diffuse color * 75% diffuse ratio * ( surface brightness + spec )
  • G = 0% diffuse color * 75% diffuse ratio * ( surface brightness + spec )

In that situation, the specular output has been cut in 1/3 of what it actually should be.. actually. more than that.. b/c the specular at that point already accounts for it's Fresnel ratio (25%). So, we're subjecting it to another 75% after adding to diffuse surface brightness.. and then it gets negated by the diffuse color channels.

So, long story short...

The specular that comes out of the BRDF needs to just mul by the specular or diffuse light color (spec if it's a real spec, diffuse light color if it's a fake spec since there's no spec light color).

So, we get the following...

Real specs...

// real spec rgb
totalColor.rgb	+= specularPBRreal.rgb
		*  specularLightColor.rgb
		*  vec3( specMulReal * clouddim );

// diffuse
totalColor.rgb	+= diffuseMaterial.rgb
		*  diffuseLightColor.rgb
		*  vec3( diffuseBrightness )
		*  kd3;	// diffuse ratio ... vec3(1.0) - fresnel.rgb

 

Fake Specs get a bit of alteration since they're floats...

// fake spec
totalColor.rgb		+= diffuseLightColor.rgb	// substitute for spec light color
			*  vec3( specularPBRfake );

// diffuse
totalColor.rgb		+= diffuse.rgb
			*  vec3( diffuseBrightness * kd1 ); // 1-fresnel, fresnel as float

 

This makes the fake specs create a more even specular shine.. but, that's the point.. they're reflecting light as-is instead of acting like artificial surface boosters.

This is keeping in line with what PBR is trying to do. But, by doing this, the diffuse colors are not as vibrant, since they are no longer getting the fake boost. If folks want brighter colors, a color saturation setting should get worked in some other place (like as post-processing setting they can adjust). I just want to get the PBR doing what PBR should be doing, even if I'm using fake values as placeholders in parts of it.

In reworking this (yet again), I toned down the fake spec roughness amounts so fake spec wouldn't be too shiny.

The PBR_RIMLIGHT is off again, so if you like using that you'll need to set it to 1 again.

glprogs.stages.interaction.086.zip

  • Like 2
Link to comment
Share on other sites

Not sure why you insist on working on shaders in conjunction with inconsistent, incomplete, and incorrect data, especially when it comes to PBR. And you don't have to look far to find correct implementation for itech4, Rich already has all the modern bells and whistles in his rbdoom3bfg branch https://github.com/RobertBeckebans/RBDOOM-3-BFG

Link to comment
Share on other sites

6 hours ago, peter_spy said:

Not sure why you insist on working on shaders in conjunction with inconsistent, incomplete, and incorrect data, especially when it comes to PBR. And you don't have to look far to find correct implementation for itech4, Rich already has all the modern bells and whistles in his rbdoom3bfg branch https://github.com/RobertBeckebans/RBDOOM-3-BFG

Looking at his interaction lighting...

https://github.com/RobertBeckebans/RBDOOM-3-BFG/blob/master/base/renderprogs/builtin/lighting/interaction.ps.hlsl

He doesn't seem to take Fresnel into account to create the ks / kd ratios needed to follow conservation of light energy, which is a key feature PBR needs to do to be considered a real PBR model.

He's using Lambertian for color.

I'm not quite sure what model he's using for specular.

In his BRDF file, he has equations for the 3 key elements:

https://github.com/RobertBeckebans/RBDOOM-3-BFG/blob/master/base/renderprogs/BRDF.inc.hlsl

  • Fresnel (reflection vs. transmission .. also counts as the specular ratio)
  • Distribution (microfacets)
  • Visibility (Geometry) (how much area the specular covers)

But, in his interaction.ps lighting file, he skips calling those BRDF functions. Instead, he bolts Disney GGX distribution in, and then uses an outside modifier (rpSpecularModifier) to modify specular further.

The goal of PBR is to not have to modify it after-the-fact. If you do PBR correctly, you just shove values in and take the outputs as-is to finish your light. You shouldn't have to tweak them further with multipliers.

(That said, I built tweaks into the PBR model I created, because my distrubtion terms were creating super-shines in shadows and such. But, that's probably because my fake roughness algorithm sucks. LOL!)

His ( USE_PBR ) part generates roughness & metallic for PBR use. So, it does that.

But, he doesn't seem to be doing Fresnel... or Visibility / Geometry.

  • Fresnel is the ks specular ratio.
  • 1 - Fresnel = kd diffuse ratio.

So, in his shader, we should be seeing something do that math to determine how much of the total light energy input gets used by specular vs. diffuse.

I don't see that in his interaction.ps shader.

I was confused about that as well until I finally wrapped my head around it using LearnOpenGL's PBR tutorial.

RBDoom3 has all the pieces there, but doesn't seem to be putting them together for a true PBR final result.

I wouldn't know that if I hadn't spent time sifting through PBR tutorials and stuff figuring it out on my own. If I took his code, and just bolted it right into TDM, it'd just get the same result he has.. which doesn't seem to be real PBR. And, I'd have no way of knowing, because I wouldn't have really understood PBR in doing that.

So, in doing it myself, I learned about PBR, where the pitfalls are, what needs to happen, and what it needs to do to count as real PBR.

 

That's not to say his code is without merit... I'm totally thinking of poaching his roughness algorithms and stuff. LOL!

I'm also chuckling, b/c I noticed he had to google about whether things should be divided by Pi or not, too. That has been one of the most confusing parts of all this... what needs to divide by Pi or not.

 

I'm glad you pointed me to his code. I wouldn't have understood it earlier on. But now that I know what PBR does, I can see what I could possibly use from his. Also, I can see that if I got similar results as him, then I was on the right track. But, I can also see where his code gets up to the finish line, but doesn't quite cross over.

(I'm not personally attacking him. I'm just noticing what I think are flaws in his code. Maybe that rpSpecularModifier handles the specular ratio, and his rpDiffuseModifier handles the diffuse ratio. I'm not sure. It's piped in as a global. I didn't dig through his game engine source code. I'm a shader code person. Maybe he has the game engine calculate fresnel / ratio? Who knows.)

 

  • Like 1
Link to comment
Share on other sites

You'd have to go and ask him either on idtech4 discord or on the forums, he's Takeshi Covacs https://www.doom3world.com/index.php?forums/rbdoom-3-bfg.19/

Given his huge experience in this, I doubt that he made a mistake in implementing the PBR model, and the artists working with him are using correct PBR data (textures/material setups) for reworked character and environment models. IIRC, they're using the metallic-roughness model (as opposed to specular-glossiness). Haven't popped in the idtech4 discord for a long time, but the screenshots they posted there looked correct / similar to other PBR games.

Edited by peter_spy
Link to comment
Share on other sites

It's hard to directly compare RBDoom3BFG and this work since the former uses generated probes for ambient lighting.

As for evaluation of the latest changes of their own merit?

This appears to have the most sane specular response yet.

There is some sort of color banding \ posterization artifact though... Perhaps you are running low on shader precision due to the number of stages?

 

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

44 minutes ago, peter_spy said:

You'd have to go and ask him either on idtech4 discord or on the forums, he's Takeshi Covacs https://www.doom3world.com/index.php?forums/rbdoom-3-bfg.19/

Given his huge experience in this, I doubt that he made a mistake in implementing the PBR model, and the artists working with him are using correct PBR data (textures/material setups) for reworked character and environment models. IIRC, they're using the metallic-roughness model (as opposed to specular-glossiness). Haven't popped in the idtech4 discord for a long time, but the screenshots they posted there looked correct / similar to other PBR games.

 

The metalness equation converts the specular from being a simple R0 value into an F0 metal vs. dielectric value.

He's got that done.

  • half3 specularColor = lerp( dielectricColor, baseColor, metallic );

That would be the next step for TDM if there was a way to flag metallic surfaces vs. non-metallic; could use that to branch the shader code and keep pipes semi-glossy without cobblestone streets looking wet n shiny.

But, whether it's R0 or F0, it needs to head through a Fresnel equation (like Schlick Fresnel) to account for view angle to the surface to determine what ratio of light is reflected as-is vs. diffuse color reflected.

I don't see him doing that anywhere. But, I'm just taking a cursory glance at things. I could be looking at the wrong shader file for all I know. Or, he could be using a different specular BRDF model that does things differently than Cook-Torrance.

But, he's got the BRDF sub-equations in a BRDF file that Cook-Torrance typically uses.

His interaction.ps file creates the dots needed for Fresnel & Visibility/Geometry (vdotN, vdotH), then never uses them. He just uses distribution to do microfacets.

Also, he's using half vars for HLSL (half2, half3, etc). I worked with HLSL to modify the shaders for FUEL. Half vars were originally created by Nvidia to try to get a performance gain over real float variables. They recommended using half vars when precision wasn't needed, like with pixel color calculations.

But, modern graphics cards & drivers and such convert halfs to floats behind-the-scenes. AMD cards had to do that in order to run HLSL. Nvidia eventually did that, too, because eventually the performance gain from halfs wasn't there any more as gfx cards keep growing in power.

The FUEL shaders (built by Asobo in 2009 for Cg, before Cg became HLSL) were using halfs. But, after I did some performance testing, I didn't notice any difference between halfs and floats.

I don't want to start a discussion over on their forum.

I sound like an a**hole nit-picking their code.

I was wanting to put the PBR stuff to bed until TDM got modified in some way where PBR could get expanded on.. like the game engine flagging basic material types (metal vs. non-metal).

I'm still splitting hairs over whether to divide the GGX Visibility function by Pi or not.

Link to comment
Share on other sites

12 minutes ago, nbohr1more said:

It's hard to directly compare RBDoom3BFG and this work since the former uses generated probes for ambient lighting.

As for evaluation of the latest changes of their own merit?

This appears to have the most sane specular response yet.

There is some sort of color banding \ posterization artifact though... Perhaps you are running low on shader precision due to the number of stages?

 

Can you post a screenshot of that banding / posterization?

I'm running bare-bones 16-bit color, no SSAO, etc, etc. Like with the Bloom issue, others are running other options that may be seeing different results.. which could be borked up w/o me knowing.

Link to comment
Share on other sites

v 0.87

* switched fake roughness over to use RBDoom3's version (seems to smooth things out better). Thanks for pointing me to his github, Peter_Spy. He's got some interesting things going on there that I'm going to look into further.

* for surfaces with real specular rgb textures, I have roughness using an avg of the diffuse rgb & specular rgb grayscales. This adds variation in the pattern. EG: instead of a polished marble floor having a uniform shine, it will have variation based on where the veins are.

* for non-PBR, I switched it over to use fake spec as a spec light instead of a diffuse boost. This makes lighting look more uniform when switching between non-PBR and PBR instead of "whoa, why does non-PBR color pop more?" (if color boosting / color saturation is wanted, it could be added as a feature in post-processing or something.)

 

glprogs.stages.interaction.087.zip

  • Like 2
Link to comment
Share on other sites

On 5/27/2021 at 12:37 AM, totallytubular said:

I don't want to start a discussion over on their forum.

I sound like an a**hole nit-picking their code.

Actually, Robert might appreciate this, there's nothing wrong with honest code review ;)

Link to comment
Share on other sites

On 5/26/2021 at 11:37 PM, totallytubular said:

I don't want to start a discussion over on their forum.

I sound like an a**hole nit-picking their code.

The trick is to focus on how you ask.

If you go in all guns blazing, with something like "Your code is obviously wrong and does not use variable X where it clearly should be" you're likely to piss people off (even if you're correct).

However, nobody (reasonable) will be offended if you ask an honest question in a polite way, e.g. "I am trying to adapt this code for another game but I'm confused about the correct usage of variable X, which I can't find in the code. Is this no longer required?".

It's quite possible that there is a good reason for the code to be written in the apparently "wrong" way, but if not, your asking about it might prompt the developers to notice the mistake without it seeming like you're calling them incompetent.

  • Like 1
Link to comment
Share on other sites

Here are screen-shots with banding or posterization:

https://drive.google.com/file/d/1iV6M0TzUNthj7J3EMd_72Ofo4qQeJ0Rq/view?usp=sharing

There is some sort of hard border between the lit side of normals and unlit side.

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

9 hours ago, OrbWeaver said:

The trick is to focus on how you ask.

If you go in all guns blazing, with something like "Your code is obviously wrong and does not use variable X where it clearly should be" you're likely to piss people off (even if you're correct).

However, nobody (reasonable) will be offended if you ask an honest question in a polite way, e.g. "I am trying to adapt this code for another game but I'm confused about the correct usage of variable X, which I can't find in the code. Is this no longer required?".

It's quite possible that there is a good reason for the code to be written in the apparently "wrong" way, but if not, your asking about it might prompt the developers to notice the mistake without it seeming like you're calling them incompetent.

Well, it's more that I'm trying to avoid another project to work on.

I'm the type of person that likes to dig in and help out.

I started asking questions here, and before I knew it I was staring at PBR tutorials to bolt PBR on the lighting shaders. LOL! No one asked me to. But, it was just interesting experiment. It was also something I felt I could work on and be productive with, because the job hunt has been very demoralizing.

I'd ask questions at the RBDoom3 forums, but, since I already know the PBR code I did, I'd want to just bolt it on and test it out. So, if it was a waste of time, it would be my waste of time instead of theirs.

I'm trying to practice some "proactive quitting" to re-focus my time on my job hunt. I've already got the FUEL shaders in the back of my mind again; wanting to revisit them to see if I can bolt PBR on them. It's like things I want to go do, but I need to stop myself, since I have something I need to do right now that I need to focus on.

Link to comment
Share on other sites

5 hours ago, nbohr1more said:

Here are screen-shots with banding or posterization:

https://drive.google.com/file/d/1iV6M0TzUNthj7J3EMd_72Ofo4qQeJ0Rq/view?usp=sharing

There is some sort of hard border between the lit side of normals and unlit side.

Oh yeah.

I noticed it on doors... There were large, chunky squares. And other textures. (I posted a picture of a ground texture that had what looked like ugly pixelization.)

I disabled parts of the PBR code to see what was doing it, but couldn't figure it out. But, when PBR is disabled as-a-whole, it goes away.

So, I'm not sure what's doing it.

I thought the clamp I had on the distribution term was creating a gating effect, but I disable that and it's fine. Maybe it's a combination of things. I don't know. I have to look into it more.

But, it is annoying.

There's a lamp on Mission 1, you jump down where the 2 guards talk... the lamp has like really black pixelly spots on it... I thought maybe the Visiblity / Geometry term was doing something.

 

The next thing with the PBR would be to bolt on various sub-routines for Visibility/Geometry and GGX/Distribution to see if they are better. Maybe they'd fix something.

I feel it's odd I had to hack in a clamp to keep Distribution term from over-shining things as it is. Ideally, PBR should just take things in and shove them out without any modification.

But, it's doing something...

The fake roughness & specular might have something to do with it. That's why I've been trying to get better algorithms to produce them.

At this point, I just don't know what's causing it.

But, at least I'm not the only one seeing it. So, that means it's not a graphics driver issue or something. (I think).

Link to comment
Share on other sites

  • 2 weeks later...

Hmm.

The posterization is substantially reduced in this version. I looks really good but there are still cases where it manifests here and there. Maybe some sort of dither is needed? (Oof, I forgot to test without any postprocess or bloom. Will try that tomorrow.)

The clamping of the metal speculars makes them look a little more plastic but I sorta understand the balancing act you are working with here.

What I would want to know is whether one can encode true PBR attributes into the specular and diffuse textures so that we can test a hybrid scene. I am guessing that using the specular alpha channel or some other bit segment detection would be too much trouble so it would require new keywords (roughnessmap etc ) on the engine side.

  • Like 1

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

v 0.90

  • tweak to BRDF function to factor out some math & optimize a bit

Been looking at this person's site...

http://filmicworlds.com/blog/optimizing-ggx-shaders-with-dotlh/

He's done work to optimize the Cook-Torrance BRDF. I Implemented it in FUEL (at least the ones that don't require extra texture pulls), but it was super-shiny.

His level 3 optimized BRDF merges Fresnel with Visibility to reduce calculations.. but then it's harder to isolate Fresnel to do the kS/kD ratio without having to have a separate one do extra calcualtions to complete just for that.

So, I tabled that for now. Might bolt it onto TDM later to see how it looks.

 

But, one thing I noticed was in GGX Visibility / Geometry functions, folks seem to do...

  • 1.0 / (stuff1) * 1.0 / (stuff2)

as opposed to the LearnOpenGL & Urho3D way that has

  • NdotV / (stuff1) * NdotL / (stuff2)

Then I realized it's probably because they used NdotV & NdotL to cancel out the ones in the denominator of the C-T equation...

  • 4 * NdotV * NdotL

we can isolate them as...

  • ( Fresnel * ( NdotV/1 * 1/(stuff1) * NdotL/1 * 1/(stuff2) ) * Distribution ) / ( 4 * NdotV * NdotL )

... and that reduces down to...

  • ( Fresnel * ( NdotV * 1/(stuff1) * NdotL * 1/(stuff2) ) * Distribution ) / ( 4 * NdotV * NdotL )

.. which just means the NdotV & NdotL are free to cancel the ones from the denom, leaving us with...

  • ( Fresnel * ( 1/(stuff1) * 1/(stuff2) ) * Distrubution ) / 4

Someone might want to double-check me on that, but it looks valid. Attached shader .zip does that.

glprogs.stages.interaction.090.zip

Link to comment
Share on other sites

On 6/8/2021 at 11:34 PM, nbohr1more said:

Hmm.

The posterization is substantially reduced in this version. I looks really good but there are still cases where it manifests here and there. Maybe some sort of dither is needed? (Oof, I forgot to test without any postprocess or bloom. Will try that tomorrow.)

The clamping of the metal speculars makes them look a little more plastic but I sorta understand the balancing act you are working with here.

What I would want to know is whether one can encode true PBR attributes into the specular and diffuse textures so that we can test a hybrid scene. I am guessing that using the specular alpha channel or some other bit segment detection would be too much trouble so it would require new keywords (roughnessmap etc ) on the engine side.

 

Yeah, noticing the posterization on a few things. Pics of banners in main hub of Training Mission:

2ORi7IJ.jpg

B6UhfOI.jpg

I fiddled with things in PBR, and didn't get it to change. Then I turned PBR off, and...

OVRjrjn.jpg

... it still shows up. So, it's something else. Not sure what. Haven't had time to test other things yet.

It's the same posterization pattern, though, so I wonder if it's specular still.

 

Link to comment
Share on other sites

38 minutes ago, nbohr1more said:

Crucible of Omens: Behind Closed Doors

Treasure room in the final manor.

v 0.91

  • posterization fixed (?)

The "if ( this is 0 and that's 0, etc, etc)" logic branch on GetBRDF() equations seemed to be creating a gating situation causing posterization.

When I commented them out, posterization seemed to clear up. (Tested on the statue on Mission 2: Tears of Lucia).

When I get time, I may get rid of other branches to see if other stuff clears up, too. (EG: the banners in Training Mission hub that still have chunky coloring splotches). Maybe I'm being too liberal with logic branches. I could try running fake specs as vec3's like real specs, and see if things clear up. I don't know.

glprogs.stages.interaction.091.zip

Link to comment
Share on other sites

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).

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

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.

 Share


  • Recent Status Updates

    • duzenko

      CPU benchmark time - compiling DarkRadiant (2nd run)
      i5 8600K 6C/6T@4.4GHz DDR4 2x2133MHz 9MB cache
      Parallel builds: 1. 3:57 Parallel builds: 6 (default). 2:28 r5 1600AF 6C/12T@3.3GHz DDR4 1x2666MHz 16 MB cache, temp folder on HDD
      Parallel builds: 1. 5:05 Parallel builds: 4. 2:47 Parallel builds: 6. 2:55 Parallel builds: 12 (default). 2:57
      · 2 replies
    • nbohr1more

      Status updates are back so it is also a good time to return to contests!
      https://forums.thedarkmod.com/index.php?/topic/21095-christmas-connections-contest-2021
       
      · 0 replies
    • freyk

      Having seen the new scifi stuff from bladeghost/scythwraith, want to continue the cyberpunk project. Only one problem, can't map.
      · 1 reply
    • jaxa

      Behold, the brand new RTX 2060!
      NVIDIA ponders GeForce RTX 2060 re-release with 12 GB VRAM to paper over RTX 30 scarcity
      · 1 reply
    • thebigh

      There are those who are afraid of greatness
      · 2 replies
×
×
  • Create New...