Messin with shaders

[stgatilov 1302]

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 2226]

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 9]

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

[totallytubular 45]

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 2226]

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 45]

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 2226]

Well...

Positives: No bloom artifacts

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

[duzenko 668]

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 2226]

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 2226]

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 668]

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 2226]

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.

[totallytubular 45]

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

 

That works, b/c everything is using the non-u_cubic branch on interaction.ambient.fs.glsl right now. If the u_cubic branch starts working some day, then it's light attenuation will have to get used instead.

That's why in my shaders I created an attenuation var at the start, and then have it pass thru to capture the attenuation of either cubic or non-cubic lighting, and come out the other side to impact rimlight. But, since u_cubic branch isn't running, I had to do a hack to pull cubic's attenuation outside the u_cubic branch and make it run and apply regardless in order to keep those windows from being funky. So, in my code, I have both u_cubic and non-u_cubic attenuations merge to try to make it all work regardless of cubic or non-cubic lighting.

Looking at 2.09 interaction.ambient.fs.glsl code, you could do something like this..

void main() { 
	vec3 attenuation;

	if (u_cubic == 1) {
		//color.rgb = vec3(var_TexLight.z);
		vec3 tl = vec3(var_TexLight.xy/var_TexLight.w, var_TexLight.z) - .5;
		float a = .25 - tl.x*tl.x - tl.y*tl.y - tl.z*tl.z;
		attenuation = vec3(a*2);
//		light = vec4(vec3(a*2), 1); // FIXME pass r_lightScale as uniform
	} else {
		vec3 lightProjection = textureProj( u_lightProjectionTexture, var_TexLight.xyw ).rgb; 
		vec3 lightFalloff = texture( u_lightFalloffTexture, vec2( var_TexLight.z, 0.5 ) ).rgb;
		attenuation = lightProjection * lightFalloff;
//		light = vec4(lightProjection * lightFalloff, 1);
	}

	light = vec4(attenuation, 1);


	vec3 rimlight;
	float NV = 1-abs(dot(N, nViewDir));
	NV *= NV * NV;

if(params[var_DrawId].ambientRimColor.a != 0)
		rimlight = params[var_DrawId].ambientRimColor.rgb;
else
		rimlight = vec3(0.4);

light.rgb += rimlight.rgb * vec3(NV) * attenuation;

} // end main()

 

The engine needs to get tweaked to start passing u_cubic to the shaders some how, though. Because while that code is technically correct, rimlights will make cubic windows look funky since they won't get cubic attenuation applied since cubic branch never processes.

[totallytubular 45]

14 hours ago, nbohr1more said:

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.

A lot of parts do.

I played around, and noticed the light attenuation, which tracks as an .rgb for non-cubic lighting, is just a grayscale. lightcolor.rrr is the same as lightcolor.rgb for non-cubic lighting.

matSpecular.rgb is also a grayscale spec map. I think even the specular param.rgb is also grayscale. Can't remember. I just started farting around to see what colors things were, and noticed a lot of grayscales posing as rgb's.

That's why on the fake specular map branch I created in my shaders I apply the diffuse color to it to keep specular from being a white shine. For the "else" branch on rimlight I used diffuse color, too, to keep it from being a monochromatic haze in shadows.

I was looking at the urdo3D lighting code, and they apply the diffuse color to every light component separately....

• specular.rgb * diffuse.rgb * spec dot
• rimlight.rgb * diffuse.rgb * rim dot
• etc, etc.

I tried doing that, but using diffuse as-is just started making things look wet, b/c it kept reinforcing the diffuse color over and over using non-NdotL dots. That's why I had to use a multiplier to reduce the diffuse color when used as specular & rimlight colors.

I created a version of the shaders (which I didn't post) that reduced all these grayscales to floats, then merged them all before applying them to diffuse. But, it looked ugly. The things do look better tracked separately, where it's easier to individually tweak their .rgb's (even if they're using modification of diffuse) before combining them with full diffuse color for final color.

[HMart 341]

totallytubular do you know a Doom 3 mod called Sikkmod? Is a mod that implemented a bunch of modern advanced shaders, in Doom3 but unfortunately written in ARB assembly, I'm asking because if you don't know the mod, you could look at it and see what you could transplant into TDM GLSL.

I know the shaders are in ARB but I'm almost certain that a good shader guy like you, even only used to GLSL lang can very easily decipher the ARB code. One shader that I would love to see in TDM is the parallax occlusion mapping or the relief mapping ones, TDM coble stones roads IMO would gain much with it.

[totallytubular 45]

4 hours ago, HMart said:

totallytubular do you know a Doom 3 mod called Sikkmod? Is a mod that implemented a bunch of modern advanced shaders, in Doom3 but unfortunately written in ARB assembly, I'm asking because if you don't know the mod, you could look at it and see what you could transplant into TDM GLSL.

I know the shaders are in ARB but I'm almost certain that a good shader guy like you, even only used to GLSL lang can very easily decipher the ARB code. One shader that I would love to see in TDM is the parallax occlusion mapping or the relief mapping ones, TDM coble stones roads IMO would gain much with it.

I tried implementing parallax occlusion mapping using a GLSL tutorial. Problem is you need a grayscale/black-n-white depth/height map. I tried faking one by grayscaling normals. Didn't turn out good. First got it going, I didn't see any results. Then I fiddled with it, and it barely altered specular surfacs some, and there was a fuzzy scrunched blob of color in the middle of the screen where it looked like it was compressing the output instead of overlaying it on the scene like it should. Not sure what I was doing wrong, so I gave up on it. Faking inputs can only go so far, especially for more complex things like POM. Also, it adds overhead grayscaling a depth map, when it should ideally be baked into the texture.

Also, I'm not going to look into ARB stuff. There's a reason GLSL & HLSL came about, and it's because it made shaders a lot more accessible to folks (like me), where-as Assembly-style langs are hard for a lot of folks to wrap their heads around. Think of driving a car. The steering wheel, shifter, etc are GLSL / HLSL. They provide a simpler, human-understandable interface. There's a difference between what a beginner driver and a pro car driver can do with it, but the interface is still simple and makes it easy for even a beginner to start driving.

ARB is like removing the dash, steering wheel, etc, and just putting a ton of wires and buttons in your face. You want to turn left, you have to figure out what combination to mess with to do that, because there isn't a pre-built "steering wheel" or "turn left" feature. I've got a masters in info sys, and we like using high-level languages that baby-sit us, so we can spend more time kit-bashing solutions and thinking about solving a problem and less time banging our head on the desk trying to piece together nuts and bolts.

The other aspect is just knowledge domain. I do data management & analytics for a living. It's pretty basic monkey bobo stuff compared to what some of these complex shader routines are doing. I start to hit my level of incompetence with a lot of these advanced shader things, because there's a foundation of knowledge you need to understand it all... matrix math, geometry / trigonometry, physics to understand light simulations, etc. There's GLSL tuts that dumb-down phd white papers and provide code, but even those can get pretty technical. And, some of them require knowing where to build the code out in the game engine's C-code to then pipe in the inputs to the shaders, and where to do it on the graphics pipeline, and what-not. There can be a lot of moving parts involved.

Like with POM, if the code doesn't work off-the-shelf, then I tend to be screwed. I don't have enough knowledge domain to trouble-shoot it. So, it gets frustrating. Knowing how to code GLSL doesn't give me that knowledge domain. It just lets me code GLSL. It's like knowing how to write; doesn't make me shakespeare.

I fiddle with the shaders to try to learn stuff. But, I hit a wall a lot of the time, and it's a blow to the old self-esteem.

[totallytubular 45]

v 0.35

• modified fake AO to use blend of diffuse & normal map
• two fake AO's, one for lighting that's smooth & one for speculars that acts as roughness (showing rough patches that reduce shine)
• shuffled lighting around to add diffuse color / texture as modifier to all lights before finalizing
• shuffled lighting takes surface into account better, so rimlighting more naturally adapts to surfaces (IE: no stone paver rimlighting pattern on grass now)

skipped a few versions, b/c they were some dead-end experimentation.

Been tweaking fake AO, b/c it can't rely too heavily on normals or else it doesn't hold up to close inspection (eg: staring at things with lantern, and noticing the shadow isn't moving as you move around object). Ended up making 2 different fake AO...

One acts like a faux roughness for speculars, where it partialls cancels out speculars to show rough patches. Looks best on metal pipes. It relies on a grayscale of the diffuse texture to create patches where darker spots are.

https://i.imgur.com/jqLsJFo.gifv

Other fake AO is for lighting, and tries to mix grayscales of diffuse & normals in a smoother way.

https://i.imgur.com/qlp43dm.gifv

Had to really dial up the brightness to see this, but the pavers on the road end up slightly darker when fake AO is on.

The fake AO's use a cutoff point to turn the grayscale map into more of a black-n-white map, where values below a certain threshhold are kept while values higher get ramped to 1.0. Then this gets normalized to try to blend the entire scene fake AO to be more equalized.

Issue with this fake AO is that it's hardly noticeable in some places. Because it's going off of grayscales, light-colored objects that have very flat normals tend to have little to no AO shading while darker things potentially get over AO'ed. I might experiment more. Seems like when I get it looking good on one thing, it looks awful other places.

Re-shuffled lighting to add diffuse color to all light vals now...

Basically create a "lighting" value of "diffuse color param * diffuse texture * light attenuation" and then use that as the base lighting to mul each of the other lights to (specular.rgb * spec dot * lighting ... rimlight * fresnel * lighting ... lighting * light dot for base lighting), then add diffuse light + specular light + ambient light.

Things are toned more to the diffuse color, like the specular on the rusty grating above.

A lot of speculars got washed out, so I punched them up with the specular multiplier some more. But, still, they're not as shiny.

One issue I noticed was that grass would have a rim-lighting highlight of stone path pavers on some maps. Thought this was odd. The var_Color.rgb has something to do with that. It was at the very end of the lighting equation ...

(diffuse + specular) * var_Color

But, I merged it in with diffuse "lighting" as a base lighting...

diffuse color param * diffuse texture * var_color * light attenuation

And suddenly surfaces rim-light as if they're unique surfaces...

Grass no longer has the stone-paver rim-lighting...

stone paver still have their rim-lighting in shadow.

Cleaned up some code, tried to consolidate "calculate once, use many" things.

Zip file doesn't include PBR module. I still have the module, but got rid of the code in the ambient & common shaders calling it, so no point in including it.

 

 

glprogs.stages.interaction.035.zip

[HMart 341]

2 hours ago, totallytubular said:

I tried implementing parallax occlusion mapping using a GLSL tutorial. Problem is you need a grayscale/black-n-white depth/height map. I tried faking one by grayscaling normals. Didn't turn out good. First got it going, I didn't see any results. Then I fiddled with it, and it barely altered specular surfacs some, and there was a fuzzy scrunched blob of color in the middle of the screen where it looked like it was compressing the output instead of overlaying it on the scene like it should. Not sure what I was doing wrong, so I gave up on it. Faking inputs can only go so far, especially for more complex things like POM. Also, it adds overhead grayscaling a depth map, when it should ideally be baked into the texture.

Sorry if I gave the wrong idea but when I said about trying to make a POM shader, I didn't mean that you add to automatically convert normal maps into heightmaps and such, my idea was, you just make the interaction shader support POM and anyone if he/she wants uses it, but is a giving that a heightmap would need to be created by hand, no automatic conversion stuff because imo that never works well and looks bad. 

btw in the sikkmod POM shader, you put the heightmap in the specular alpha channel.

Also, I'm not going to look into ARB stuff. There's a reason GLSL & HLSL came about, and it's because it made shaders a lot more accessible to folks (like me), where-as Assembly-style langs are hard for a lot of folks to wrap their heads around. Think of driving a car. The steering wheel, shifter, etc are GLSL / HLSL. They provide a simpler, human-understandable interface. There's a difference between what a beginner driver and a pro car driver can do with it, but the interface is still simple and makes it easy for even a beginner to start driving.

ARB is like removing the dash, steering wheel, etc, and just putting a ton of wires and buttons in your face. You want to turn left, you have to figure out what combination to mess with to do that, because there isn't a pre-built "steering wheel" or "turn left" feature. I've got a masters in info sys, and we like using high-level languages that baby-sit us, so we can spend more time kit-bashing solutions and thinking about solving a problem and less time banging our head on the desk trying to piece together nuts and bolts.

Not sure if I'm reading your reply right hard to take intention from text but if I made you mad in some way, not my intention at all, If perhaps my comment felt like a demand that is totally the contrary of what it was, was just a suggestion.

To tell you the truth, I surely didn't expected this reaction, at lest based on the work you have been doing, I though you add the necessary knowhow to look at the stuff, ARB or not, seems I was terribly mistaken my bad, but in my defense, I add that wrong impression, mostly because I have written, very very basic ARB shaders my self, based on this tutorial

http://web.archive.org/web/20050404222925/http://www.planetdoom.com/d3cc/tut06.html

trying to see if I could and they worked, they didn't do much, just change basic colors and stuff but they worked, so I thought, If I could and I know pretty much zero about ARB shader writing, even GLSL and certainly not enough about advanced matrix math and such, I thought, again based on the capabilities you demonstrated in this thread, that would be much easier to someone like you, so again, sorry for assuming wrong.

The other aspect is just knowledge domain. I do data management & analytics for a living. It's pretty basic monkey bobo stuff compared to what some of these complex shader routines are doing. I start to hit my level of incompetence with a lot of these advanced shader things, because there's a foundation of knowledge you need to understand it all... matrix math, geometry / trigonometry, physics to understand light simulations, etc. There's GLSL tuts that dumb-down phd white papers and provide code, but even those can get pretty technical. And, some of them require knowing where to build the code out in the game engine's C-code to then pipe in the inputs to the shaders, and where to do it on the graphics pipeline, and what-not. There can be a lot of moving parts involved.

Like with POM, if the code doesn't work off-the-shelf, then I tend to be screwed. I don't have enough knowledge domain to trouble-shoot it. So, it gets frustrating. Knowing how to code GLSL doesn't give me that knowledge domain. It just lets me code GLSL. It's like knowing how to write; doesn't make me shakespeare.

I fiddle with the shaders to try to learn stuff. But, I hit a wall a lot of the time, and it's a blow to the old self-esteem.

I might sound like a broken record but again sorry for assuming something that was not correct, it was all based on a badly constructed idea, based on your current GLSL work and my own lack of knowhow on this stuff, lesson learned, you will not hear anymore such suggestions from me. Certainly work on what you feel is right, that is what I also do, about blows to the good old self-esteem, I know that feeling,

 

[totallytubular 45]

6 hours ago, HMart said:

 

I apologize, HMart. I didn't mean to sound like a d**k. I was just giving reasons on things.

[HMart 341]

8 hours ago, totallytubular said:

I apologize, HMart. I didn't mean to sound like a d**k. I was just giving reasons on things.

No problem, is in the past already.   

[Hooded Lantern 9]

tried the latest version with cos2 and arena. both fms was pitchblack. ive got everything activated in the graphicoptions btw. switched back to glprogs.stages.interaction.028.

[nbohr1more 2226]

Yes, the latest version seems to be missing some dependencies?

I tried overwriting a clean glprogs/stages/interaction folder and tried overwriting the same folder with the previous build applied. In both cases the screen is black and reloadGLSLprograms complains about missing programs. I didn't dig further yet since I have been doing my own tinkering things...

[totallytubular 45]

v 0.35

• added missing "interaction.funcs.glsl" file (my bad)

v 0.38

• condensed lighting code more
• added gaussian specular
• messed with fake AO & fake Spec map again
• #defines that control fake AO & such moved to funcs.glsl file to make it easier to turn off/on en masse

v 0.38.1

• specular defaulted to Blinn instead of Gaussian (gaussian looks weird in some maps)

 

v 0.35

I forgot to zip up the funcs module, so, with it missing, ambient & common shaders wouldn't compile. When they don't compile TDM bypasses them (which is smart.. b/c at least you don't just crash). Hence all you saw was darkness. Sorry about that.

v 0.38

Since the code is back to adding diffuse light dot & specular dot/map together before mul'ing by a single lighting value (made up of diffuse color param * diffuse texture * var color * light color/attenuation), I consolidated some code down to reduce calc's.

Added a gaussian specular func to see how it looks. Looks pretty much like Blinn specular. It's supposed to take in a "shininess" factor, which lets it shift between duller/rougher vs. smoother/shinier speculars. I defaulted it to 0.5 for now. Might mess with it later. Roughness would need to get faked once again, and already stretching that thin with fake AO & Spec maps via diffuse texture.

Messed with fake AO & spec once again. Fake AO adds a bit more darker highlights a bit more evenly, but it's still dependent on the diffuse texture. So, darker textures cause more darkness. Same result could probably just be done by increasing lowering contrast and brightness. But, it's an experiment. Fake AO is applied to the NdotL light dot fully (to block direct & ambient world light), and half-as-much (AO*05+0.5) to specular.

Fake Spec is simplified a bit more, uses diffuse texture, and tweaked. The issue with fake specular in ambient light is it follows the world light direction, which is straight down. So, adding specular to things like walls can look odd inside buildings where it seems like a shine is coming straight down the wall. Toned down the specular some to blend that, plus it mul'ing by diffuse color helps it blend in. (EG: so looking up a red brick wall you'll see a faint red brick highlight, not a white shine).

I wanted to figure out how to add Depth of Field to the spyglass when you zoom in, but couldn't figure that out. There's shader code online, but not sure how to trigger it when activating spyglass, and how to pass depth values in and what-not. (IE: hit my level of incompetence). Think I'm done farting around for a while.

glprogs.stages.interaction.035.zip glprogs.stages.interaction..038.zip

glprogs.stages.interaction.0381.zip

Edited March 9 by totallytubular

[VanishedOne 550]

I should think adding shader effects to the spyglass overlay would be done by adding a stage to the tdm_spyglass_overlay material to invoke a postprocess shader. You could look at water materials like textures/water_source/water_clear for an example of a stage calling a shader program.

[Hooded Lantern 9]

all the new versions got this wierd flickering black boxes. it seems there is a file missing missiong in those packages. do i have to keep the interaction.pbr.glsl file, just replace the other five?