Messin with shaders

[stgatilov 1250]

4 hours ago, peter_spy said:

There's no point in introducing PBR if you're not doing it on correct data. Creating a simple scene in Unreal of Unity, and then using the same images and materials in TDM scene would give more meaningful results to compare.

There is no point in introducing PBR if the whole pipeline is not gamma-correct (both assets and rendering).

[nbohr1more 2170]

Interesting...

If I port just the fresnel part of the latest shader, I have the same problem:

1) Bloom produces black squares

2) Projected Ambients render incorrectly

I am guessing that the fresnel is making assumptions about the light direction vector?

I cannot fathom why bloom would be affected...

[Hooded Lantern 0]

got this weird square problem too on glprogs.stages.interaction.026. version glprogs.stages.interaction.023 works 

[totallytubular 28]

2 hours ago, Hooded Lantern said:

got this weird square problem too on glprogs.stages.interaction.026. version glprogs.stages.interaction.023 works 

game engine is always piping in u_cubic value of 0 regardless of light type, so u_cubic == 1 branch is not being done to attenuate those cubic lights properly.

params[var_DrawId].diffuseColor.rgb sends in a general color shape that needs it's shape attenuated.

Both branches need that param .rgb to color properly. But, without the u_cubic == 1 branch calculating the "a" attenuation variable to shape cubic lights properly, we end up with sharp bright squares.

I can pull the "a" attenuation calculation out of the u_cubic == 1 branch, and apply it to everything as a hack in the shaders. But, then it over-darks the u_cubic == 0 stuff (b/c that stuff gets hit by both "a" variable attenuation and again from the lightProject & lightFalloff light color attenuation).

[nbohr1more 2170]

That is pretty bizarre. "u_cubic" should only affect lights with the "cubicLight" keyword in the light def.

It should probably be renamed "u_spherical" since it has a spherical falloff pattern and uses a cubemap for projections.

Both Point and Projected lights are somehow covered in the other branch. I presume that the shading used in

the ambient is "light orientation" agnostic so both projection types are unaffected but your changes somehow require light direction?

@cabalistic  ?

I will keep tinkering on my end...

[totallytubular 28]

v 0.28

• hacked around u_cubic issue

 

All light needs attenuation.. so the issues were...

1) the AOcolor I added as a final light amount to keep AO from being pitch black (if NdotL = 0, etc) needed to get impacted by attenuation.

2) params[var_DrawId] colors (diffuse & ambientrimcolor) were needing attenuation, too. The vec3 lightcolor wasn't enough to attenuate diffuse for these cubic lights, and ambientlightcolor wasn't getting any attenuation, since it was sitting outside the branches.

Since u_cubic branch was being bypassed, I just pulled its attenuation out, and applied it as a default attenuation amount to everything (diffuse, rimcolor, aocolor) by making a #define CUBIC_HACK and patching it in as-needed. It's CUBIC_HACK, b/c it's def a hack.. ideal case would be to get u_cubic == 1 branch to start getting processed... b/c not sure if this hack will cause other issues.

I messed with common.fs to see if u_cubic lights were lighting up if I applied the u_cubic attenuation to !u_cubic.. but didn't notice anything. (Then again, I just did a cursory run around Training Mission, so...) It seems like these are lit up in ambient.fs only (?) by making them have a bit more ambient light showing than their surroundings.

Code looks like a hot mess, b/c I got brdf/pbr stuff all over the place .. which I also disabled for the time being. That was an interesting experiment, but like everyone pointed out, the results suck. I googled up faking brdf to see if there was some trick to making it work, and it was either folks applying fresnels, or folks giving tuts on taking a single texture, and running it through photoshop to create the others (metallic, gloss, etc) needed to do actual BRDF. So, I'm not gonna work on that anymore.

glprogs.stages.interaction.028.zip

[nbohr1more 2170]

Well...

Positives: No bloom artifacts

Negatives: Now projected ambients in "Caduceus of St Alban" are black

[duzenko 660]

On 3/2/2021 at 1:26 AM, nbohr1more said:

I'll take another look tonight.

I actually fixed this issue once in 2.06 by simply adding the falloff image back to the shaders...

but the GLSL currently is very arcane now so it's hard to tell where the "projected light" branch I'm missing is.

@duzenko ?

Sorry, what are "projected" lights and how are they marked if they have a special designation?

If it's what I think - the frustum planes are simply not parallel - then there's no branch. The relevant code e.g. in ambient interaction fragment shader is

        vec3 lightProjection = textureProj( u_lightProjectionTexture, var_TexLight.xyw ).rgb;

 

[nbohr1more 2170]

7 hours ago, duzenko said:

Sorry, what are "projected" lights and how are they marked if they have a special designation?

If it's what I think - the frustum planes are simply not parallel - then there's no branch. The relevant code e.g. in ambient interaction fragment shader is

        vec3 lightProjection = textureProj( u_lightProjectionTexture, var_TexLight.xyw ).rgb;

 

tr_lightrun.cpp

Point Light: R_ComputePointLightProjectionMatrix

Projected Light: R_ComputeSpotLightProjectionMatrix

I actually tried just using the ambient rim color in our own shaders and the same square artifacts affect the lights in "Caduceus of St Alan". (though more faint) The Fresnel effect is somehow broken at some incident angles.

[nbohr1more 2170]

WHOO!!!

Thank you for the TIP @duzenko  !!!

I cured the square artifact by applying both projection images to the fresnel \ rim phase:

 

if(params[var_DrawId].ambientRimColor.a != 0) { // produces no visible speed difference on nVidia 1060, but maybe on some other hardware?..
        
        light.rgb += params[var_DrawId].ambientRimColor.rgb * NV * NV;
    }
        else {
              vec3 lightProjection = textureProj( u_lightProjectionTexture, var_TexLight.xyw ).rgb;
          vec3 lightFalloff = texture( u_lightFalloffTexture, vec2( var_TexLight.z, 0.5 ) ).rgb;
              vec3 attenhack = ( lightProjection * lightFalloff );
              light.rgb += vec3(0.04) * ( NV * NV) * attenhack ;
              
        }

 

[duzenko 660]

3 hours ago, nbohr1more said:

WHOO!!!

Thank you for the TIP @duzenko  !!!

I cured the square artifact by applying both projection images to the fresnel \ rim phase:

 

if(params[var_DrawId].ambientRimColor.a != 0) { // produces no visible speed difference on nVidia 1060, but maybe on some other hardware?..
        
        light.rgb += params[var_DrawId].ambientRimColor.rgb * NV * NV;
    }
        else {
              vec3 lightProjection = textureProj( u_lightProjectionTexture, var_TexLight.xyw ).rgb;
          vec3 lightFalloff = texture( u_lightFalloffTexture, vec2( var_TexLight.z, 0.5 ) ).rgb;
              vec3 attenhack = ( lightProjection * lightFalloff );
              light.rgb += vec3(0.04) * ( NV * NV) * attenhack ;
              
        }

 

The problem solved? (Other than how to "make it look cooler" - I prefer to deal in school physics formulas)

[nbohr1more 2170]

Yes, this part is fixed.

I am guessing that to make this physically realistic the ambient rim \ fresnel color would need lighting data from the scene ( probes ) rather than using a hard coded value and would also need to be better modulated by specular \ roughness.

Good enough for my own tinkering though.