Jump to content
The Dark Mod Forums

Recommended Posts

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

  • Like 1
Link to post
Share on other sites
  • Replies 86
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

3 days w/o power in texas. Froze my nuts off. But, power's back on. Upgraded to 2.09, then messed with shaders some more. Mainly the glprogs/stages/interaction/ ... common & ambient, b/c they

v 0.22 BRDF & PBR implemented... in faux fashion Snagged code from... https://github.com/urho3d/Urho3D/blob/master/bin/CoreData/Shaders/GLSL/PBR.glsl        // BRDF main rou

A potentially significant difference, though, is that Doom 3 assets all have a coherent source and style. That makes it potentially easier to apply some kind of hacks to make them look decent when com

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

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 post
Share on other sites
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).

Link to post
Share on other sites

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

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 post
Share on other sites

v 0.28

  • hacked around u_cubic issue

FHqVzFw.jpg

 

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

  • Like 1
Link to post
Share on other sites
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;

 

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

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 post
Share on other sites

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 ;
              
        }

 

  • Like 2

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 post
Share on other sites
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" :D - I prefer to deal in school physics formulas)

  • Like 1
Link to post
Share on other sites

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

  • Haha 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 post
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.


×
×
  • Create New...