stgatilov 1250 Posted Wednesday at 05:58 PM Report Share Posted Wednesday at 05:58 PM 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). 1 Quote Link to post Share on other sites
nbohr1more 2170 Posted yesterday at 05:13 PM Report Share Posted yesterday at 05:13 PM 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... Quote 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
Hooded Lantern 0 Posted yesterday at 07:11 PM Report Share Posted yesterday at 07:11 PM got this weird square problem too on glprogs.stages.interaction.026. version glprogs.stages.interaction.023 works Quote Link to post Share on other sites
totallytubular 28 Posted yesterday at 09:21 PM Author Report Share Posted yesterday at 09:21 PM 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). Quote Link to post Share on other sites
nbohr1more 2170 Posted yesterday at 09:53 PM Report Share Posted yesterday at 09:53 PM 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... Quote 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
totallytubular 28 Posted yesterday at 10:48 PM Author Report Share Posted yesterday at 10:48 PM 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 1 Quote Link to post Share on other sites
nbohr1more 2170 Posted 19 hours ago Report Share Posted 19 hours ago Well... Positives: No bloom artifacts Negatives: Now projected ambients in "Caduceus of St Alban" are black Quote 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
duzenko 660 Posted 14 hours ago Report Share Posted 14 hours ago 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; Quote Link to post Share on other sites
nbohr1more 2170 Posted 12 hours ago Report Share Posted 12 hours ago 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. Quote 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
nbohr1more 2170 Posted 7 hours ago Report Share Posted 7 hours ago 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 ; } 2 Quote 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
duzenko 660 Posted 3 hours ago Report Share Posted 3 hours ago 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) 1 Quote Link to post Share on other sites
nbohr1more 2170 Posted 3 hours ago Report Share Posted 3 hours ago 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. 1 Quote 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
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.