totallytubular

Shadow Maps vs Stencil shadows That particular spot on Training Mission is lit up when you have shadow maps turned on, but not when stencil shadows are on. Not sure why. It's like there's an extra light source there that stencil shadows aren't taking into consideration. Not sure if it's supposed to act like the light coming from the window across the water, or ... ??? Level authors often use extra lights that don't seem to have a source to accentuate things or help make ambient light seem more dynamic. (EG: in Training Mission, along the brick corridor leading to the Builder warehouse for sneak training, there's a bright, white dual-line light towards the top of one building that acts like moonlight rays casting down). Why stencil doesn't account for it, though.. not sure.

Here's a better gif comparing the ambient as-is to the under-darkening effect...

v 0.77 ambient light amount matches up to original TDM shader ambient light amount better now ambient rimshine applies to all rimlighting as edge highlighting, and tweaked to hopefully not be too gaudy direct lighting rimshine toned down a bit, b/c it was super-bright fake spec math changed, b/c averaging fakespec + (1-fakespec) was just making 0.5 regardless (d'oh). Switched to using a percent frequency curve to reduce shine on both very bright/dark textures while boosting the mid-tones. This evens out the shine a bit while still giving color variation. tweaked ambient spec floors/ceilings to actually dim them instead of whatever it was I thought they were doing when I wasn't thinking straight while high on vaccine added #define AMBIENT_DARKEN_UNDER ... this slightly darkens light on the underside of objects / surfaces (opposite light direction) in ambient light to help them blend into shadow maps / ssao better My ambient shader created darker shadows than TDM originals. I originally kept it, b/c switching to an ambient light that matched original TDM caused the light gem to brighten slightly. But, after I tested it for a bit on more levels, it was only in a few places and didn't really impact game play. So, I just switched ambient lighting over to look more like original TDM shaders. My goal is to enhance the shaders while still keeping towards the original artistic look & feel. Not force darker shadows on folks. (If you want darker shadows, there's a #define in the "interaction.funcs" file called AMBIENT_LIGHT_DARKER you can play with to do that in optional fashion.) Ambient rim shine was multiplying by specular dot, which basically culled the rim shine too much and accentuated it too much in specular trails up walls. Decided to just use rim shine as a generic boost. It branches on whether things have a real vs fake spec map, so metallic objects and stuff will use their specular texture and specular light color to do the rim shine while other things will use the fake spec map to tone it down. Rimlight in ambient shader didn't take light direction into account. So, we ended up with bright rimlight highlights on the underside of objects (like canvas packages) that looked odd. I created a reverse light direction hack to dim the rimlight on the underside of things. Then I figured to just apply it to all ambient lighting (diffuse, specular, rimlight) to dim the lighting on underside of objects & surfaces. By using the reverse light direction, we have better control over how much gets dimmed (finer control than a half-lambert). I reduced the light slighlly, because too dark and it has opposite effect of sticking out like sore thumb being too dark. So, I faded it slightly to help blend into shadows / shadow maps / ssao. On the under-side of the canvas package, the ambient rimlight, et.al. create an unnatural shine. Shadow maps & SSAO don't get rid of it; there's still a slight unnatural seam of light. So, applying a hack with the reverse light direction, we can tone down the lighting on the underside of it (and other surfaces) to help it blend into shaows & ssao better. This is just a brightness reducer, not an "anti-light" / black-light rgb light source (which I've seen used in some games to create fake shadows, and it always looks fugly.) glprogs.stages.interaction.077.zip

v 0.75 cubic / non-cubic branching added back to common/direct lighting (guess I removed it when sorting out diffuse vs specular light color.. realized it was broken when playing a level and the tiffany-style desk lamps made the room super bright) called rimlight boost "rimshine" (rimlight is the soft fresnel while rimshine is the bright, crisp edgy part) added rimshine to ambient lighting, but there it enhances all not just following specular trail up wall (had to make it enhance more than just the specular trail, b/c the specular trail going straight up becomes too over-powered with specular + rimlight + rimshine) In ambient, ditched the sqrt() part in the lightdot*X+Y linear algorithm. Valve's half-lambert style was meant for light dots in -1 to 1 range, so sqrt(dot*0.5+0.5) was boosting it to 0.7 to 1 range. AMBIENT_HALF_LAMBERT #define lets you decide if you want to do NdotL*X+Y half-lambert, or full-lambert with NdotL. When doing full-lambert, it will create a final, constant ambient light to add to total light at the end (basically diffuse texture * diffuse light color * constant value to create a constant light not impacted by light direction.. this keeps NdotL = 0 surfaces from being pitch-black). Changed linear lightdot*X+Y formula to minBrightness & mulBrightness ... minBrightness is the additive (Y) part, and is used to see if u_minLevel exists (which it will use as an override). mulBrightness is the multiplier (X), which gets calcualted as (1-minBrightness). (it's basically reverse of how I was doing it with p/q, b/c I realized u_minLevel needed to be the additive, not the multiplier .. d'oh). surfaces in specular light color area that don't have a specular texture (it comes back pitch-black) get the fake specular diffuse brightness boost now. (which my previous post was discussing). So, that dark reddish-brown gate door is speculared, but via diffuse dot enhancement. added a test if specular texture does exist after it's pulled, and that flag is used going forward to do real spec parts. This may or may not help performance much, but it's purpose is to skip more specular math on parts that don't have real specular textures. ripped out phong specular from ambient... it's blinn-phong again, but still uses double-speculars to cover both floors & ceiliings and such. (Phong specular is just too hit or miss.. it looks good in some places, then awful the next. Blinn-phong has more consistent look and quality). added #define to switch ambient light back to original TDM specular style. glprogs.stages.interaction.075.zip

Just noticed some surfaces have specular light color set (params[var_DrawId].specularColor.rgb), but don't have a specular texture. In default TDM shaders: ambient does a specular texture pull regardless vec3 matSpecular = textureSpecular( var_TexSpecular ).rgb; .. but, common checks if specular light color is pitch-black first.. if it's not, then it does the specular texture pull if (dot(params[var_DrawId].specularColor, params[var_DrawId].specularColor) > 0.0) specular = textureSpecular(var_TexSpecular).rgb; While messing with specular, I noticed this one dark-reddish-brown door/gate (left-side of image) never had specular, excepte for the metal fittings. Didn't matter what I did, in my shader I couldn't get specular to apply to it. So, I piped specular light color through to see if it was flagged as a specular texture surface. Yup.. it has specular light color param set... With the specular light color set, the specular texture should pull. So, I pipe specular textures through to see what they impact... Only the metal fittings have specular textures. So... specular = specular texture * specular light color * specular dot (brightness) But, if the specular light color isn't set, or the specular texture doesn't exist, specular is 0. So, this dark red-brown door/gate is never getting specular unless there's some double-checking going on to fallback to an alternate method (like applying a generic amount of spec, or, what I've been doing, grayscaling the diffuse texture as a faux spec map). Not sure if surfaces having specular color light set, but not having a specular texture, is by design or a bug. I was going to work some error-checking into my shaders to test if specular texture is pitch-black. But, that's a "meh" prospect, since specular texture maps could literally have pitch-black areas to create shine-free surface details. Not sure how to approach this. (edit) I stared at the default TDM ambient / common shaders more. Ambient doesn't use specular light color at all. It just pulls specular texture, then muls it by specdot & specpow in a way to adjust specular lighting. So, specular light color never comes into that equation. Common does use specular light color, and uses it to decide if a surface has a specular map. Since the dark-brown door/gate is covered by specular light color, it does a specular texture pull, but it doesn't have a specular texture (or it's defaulted to pitch black). So, it ends up with no specular. In my ambient shaders, I added in specular light color, and was using it (like in common) to check if a spec map pull needed to be done. Figured it was good to skip an unnecessary texture call. I think in my shaders, I'll just check if both specular light color & specular texture are pitch-black (empty), and fallback to faux spec maps.

v 0.71 fake spec diffuse light enhancement boosted a bit to be more noticeable added the direct light rimlight boost back in Fake Spec Boost Fake Specs enhance diffuse lighting overall, creating subtle specular shines on things that don't normally have specs, and enhancing stuff that does. When I'm working on them, I'm hyper-focused on them, and notice very subtle amounts. But, regular players are going to be blowing through areas, and won't notice anything that is barely noticeable by me when I'm hyper-focused on them. So, I boosted the amount a bit. The idea isn't for it to be "in your face", but just to add detail that the player might actually notice every now and then as it enhances the scene. Direct Light Rimlight Boost Default TDM shaders have a wonderful effect where the rimlighting in direct light would brighten the more direct line-of-sight the player had with the light source, and the closer the player's eye level was to the surface the light source lit up. When tearing the shaders down and testing each variable to figure out what was doing what, I omitted this, b/c the two parts of it, when tested individually, don't seem like they do much. (one part super-dulls the shine while another part super-brightens). But, going back and looking at default TDM shaders to see what I've missed or did differently, I noticed that when those two var's combine, they create the great rimlight shine boost. So, I added it back in.. but did so by treating rimlight like a two-step light as well. Base rimlight is done, then it's used to create a specular rimlight that gets added into base rimlight.. and then, that all gets added into specular lighting if the surface has a real specular texture map, or diffuse lighting if it doesn't (and shaped by the fake spec map before doing so). So, the nice, bright edge is back on the direct rimlighting... If you're wondering why my rimlighting wraps around more... The normal map intensity has been boosted, making detail pop out more. I don't know I know the normal map adjustment will create more detail to pop out, which means things stick out further and thus get hit by light more. But, other than that, I'm not sure why it wraps more. But, it acts like light bouncing off one pillar onto the backside of the other to extend the rimlight range. I like the effect, so keeping it. glprogs.stages.interaction.071.zip

Interaction shaders were designed with alternate fallback methods in case certain things weren't set. EG: if a surface is missing specular texture, then it would apply a minor amount as fallback. But, it was multiplying all speculars by specular light color params. Surfaces w/o specular had their specular light color set to 0 rgb (pitch-black), which negated any fallback specular amount being applied. The fallback methods basically act as crutches in case something isn't set for whatever reason... a likely scenario is because it would take more effort to do it "right" than it's worth. EG: going through all textures and making sure they all had a proper specular texture.. that's a lot of work, and would possibly add a lot of memory bloat to things.. especially for inconsequential stuff that will just have a very minor amount of specular applied. It's cheaper to just have a catch-all fallback method to do it in the shader. The R2f in default direct light shader is applied regardless, so doesn't look like it was done as a fallback method. But, it could be shifted to being one. I think the problem would be level designers can position lights in all kinds of weird ways. I've seen hooded lamps parked on the ground and shooting upwards to highlight statues. The R2f shapes the light by just boosting the light direction up or down. If a lamp was flagged to boost downwards, but level designer parked it to shoot upwards, it would shape those weird. Who knows. I'm gonna keep the R2f disabled in the shaders I'm farting with.

Is there a way to tell the light sources apart? I was looking over the default TDM shaders again (now that I have a better understanding of what's doing what), and there's a variable called "R2f" in interaction.common.fs that shapes light to make it seem like lamps cast more light downwards than upwards (b/c their glass / metal hoods block some light). But, it looks odd on torches, candles, sconces, etc that would shoot more light upwards and less down due to their implement blocking light downwards. I can use modify the R2f function to make it shoot upwards or downwards.. that was easy enough. But, if I can't build logic into the shader to differentiate light sources, I don't know which should get upwards & which should get downwards.... Here's some picks as example from Coercion... A lamp looks better with light shaped downwards... ... not upwards ... But, a candle looks better with light shaped upwards... ... not downwards ... However, without being able to tell the light sources apart, the shader can't tell how to shape the light to benefit. Original shaders used R2f as-is, and it blended well enough I guess to not be noticeable. But, I'd really like to leverage it for nicer lighting. Do light objects have some flag that could get piped through as a uniform to the shaders? (edit) I should also mention... fireplaces look better without any R2f shaping. So, an ideal variable would be able to tell me if light should get shaped up, down, or not at all. Is there something like that?

Here's a gif of the NdotL vs. Half-Lambert, so you get an idea of the difference. The NdotL seems stark around the bottom of boxes, but when you have SSAO on, it blends them into the ground. NdotL is more true to math / scene, but half-lambert is a crutch technique to help with blending. Again, this is only done on ambient lighting shader. Direct/Common lighting shader does NdotL to provide a stark contrast between light and "not light" (IE: opposite sides of light where AO from lightdot being 0 sets in)

v 0.69 .. (nice) added cap to ambient rimlight, so brighter/lighter surfaces (eg white sheet-covered furniture, status/busts, etc) don't stick out like a sore thumb in the dark added direct light boost option to compensate if ambient light darkening is on everything has fake spec enhancing light dot to act as base layer of specular; real spec maps get layered on top as extra spec enhancement for things that have it. in "interactions.funcs.glsl", added #define AMBIENT_HALF_LAMBERT to swap ambient light dot between doing valve-style half-lambert vs. full NdotL Rimlighting part is self-explanatory. Was messing with Blackgrove Manor with ambient light reduction, and light/white textures had gaudy rimlighting. So, had to set a limit cap. Direct Light Boost Direct light boost option compensates when ambient light darkening is on.. Basically, it does about 1/3 of the opposite of the ambient reduction. EG: if you reduce ambient light to 25%, then direct light will boost 1.0 + (1.0 - 0.25) * 0.33 1.0 + 0.75 * 0.33 1.0 + 0.2475 ~1.25 (125% boost) This is because ambient light doesn't contribute to total light as much as direct light does. So, just b/c we reduce ambient light to 25% doesn't mean we should boost direct light up 75% to compensate. Spec Maps Got tired of "if real spec map use it, else use fake" ... decided to experiment and just put fake spec map light dot enhancement on everything, then layer real speculars on top for things that have it. Turned out pretty nice after tweaking some values. Gets rid of some branching, too. I'll mess with some levels with it, and clean up the code more if I decide to stick with it, b/c that part of the code is a hot mess of experiments right now. Half-Lambert vs Full-Lambert Light Dot When objects multiply by the NdotL light dot for diffuse (color) lighting, if they have a surface angle 90 degrees or more to the light source, then they get an NdotL of 0. This would make the sides of boxes pitch black, ceilings pitch black, etc.. b/c ambient light source direction is coming down from directly overhead. The valve-style half-lambert acts like an all-in-one solution to this, because it takes the 0 to 1 NdotL range, and shifts it to 0.7 to 1.0 (if you use sqrt(lightdot*0.5+05)). So, it prevents pitch-black surfaces by automatically creating a constant minimal light value.. but does so on the light dot. Since it tightens the dot range, it also evens out the lighting more. But, the NdotL provides a greater range, and thus, greater contrast in lighting. In using it, we have to apply a final ambient light constant value to keep things from being pitch black. So, I just use the diffuse lighting a second time... in following fashion... diffuse light = diffuse light * diffuse texture * diffuse light dot (NdotL) ambient light = diffuse light * diffuse texture * "ambient light dot" total ambient light = diffuse light + ambient light That faux "ambient light dot" is just a constant value to determine how much ambient light to add on to keep things from being pitch-black. Even though this method isn't using valve half-lambert, it still calculates the ratios for that, because it uses them to determine that "ambient light dot". I did this, because TDM has a variable to set a minimum level, so I check if that exists and use it.. if it doesn't exist, then I use a different default value.. 0.5 in this case, b/c it works well for both half-lambert and the NdotL methods. 0.25 as default looks more like default TDM shaders, but the added speculars in my shaders make the light gem boost a bit more. So, shifting the default to 0.5 darkens the level a bit but also makes the light gem work well again. Anyways.. there's a bunch of TMI Hopefully this doesn't muck up Bloom again. glprogs.stages.interaction.069.zip

v 0.65 added two #define's in "interactions.funcs.glsl" to adjust overall ambient light level (one to switch override on, and one to set override amount) While messing with the speculars today, I tried to use ambient diffuse luminance to cull and blend things more. Then I decided to apply it to overall ambient light.. and it darkened shadows a lot. But, it was really cool for the level I was testing it on (Alberic's Curse).. so, decided to add the option to let player darken shadows as they wish. Interactions.funcs.glsl has two more #defines now... AMBIENT_LIGHT_DARKER ... set to 1 to turn-on, any other value skips it (but, can just use 0 for off) AMBIENT_LIGHT_AMOUNT ... set to 0.0 or higher for however much ambient light you want to show through (it works as a percent, so 0.0 = 0%, 0.5 = 50%, 1.0 = 100%, etc) When switched on, this adjusts the diffuse + specular ambient light, not the rimlight. The rimlight is still added on last as a final lighting to help player see in the dark. AMBIENT_LIGHT_AMOUNT 0.0 (0%) = pitch-black shadows save for rimlighting. AMBIENT_LIGHT_AMOUNT 1.0 (100%) is like having AMBIENT_LIGHT_DARKER override switched off AMBIENT_LIGHT_AMOUNT > 1.0 (eg: 1.1 or 110%) brightens shadows, making it harder to sneak The catch-22 of this is that you're overriding the level designer's original artistic vision; they set certain lighting levels in their level. But, some users may want darker shadows. So, to each their own. Here we see it in action on Alberic's Curse... Might be hard to see, but the faint rimlighting on the stone window frames stays fairly constant. Also, as the ambient light dims, the rimlighting becomes more apparent on the tiled ground. Since ambient light is added into direct lights (EG: torches), the torch in the distance dims a bit, too. But, it still shines brightly. glprogs.stages.interaction.065.zip

v 0.64 ... more ambient specular changes ambient now has double specular ... spec 1 shining from sky to floor (the one we've had), and now spec 2 is shining up from the floor to the ceiling. I did this to help add continuity to surfaces with specular in ambient lighting. ambient ceiling / floor specs use Phong (that uses reflection), b/c it makes a nice spotlight shine while walls and such use Blinn-Phong (which uses half direction) b/c it's nicer ambient real spec maps create too much shine on floors (spotlight under foot or overhead). Been struggling with a way to kill them some, which I tried doing the NdotL curve with... but, silly me, I already have a flag to differentiate between real & fake spec maps. So, I just used that to tweak the multiplier down on real spec maps for floors / ceilings. (Not sure why I didn't think of that sooner. d'oh) ambient lighting now treats all spec maps like real specular lights instead of using fake spec maps to enhance diffuse color lighting. This is experimental. I've been bothered by the ambient specular, where it shines down walls w/o any indication of it being on the ceiling. It's just cut-off at the seam between wall and ceiling. Reason being.. the main ambient light source (in most levels, the moon) isn't treated like a direct/common light, so it's not blocked by shadows. I'm guessing the reason this is the case is because to create a level-wide direct light overhead which is impacted by shadow maps would be a major processing bottleneck for the game engine. Reading TDM's level design optimization guides, they already recommend limiting the number of dynamic shadow-casting lights in areas. So, having to track a massive one overhead as moonlight blocked by shadows in order to know when the player was indoors vs outdoors, or when overhangs on buildings blocked moonlight... that'd be nuts. So, for pretty much all levels, there's a light direction coming straight down without any way of knowing if anything is blocking it (which is what shadow maps do), and the light color is controlled by a diffuse light color the level designer tweaks based on indoor vs outdoor lighting levels. So, outside, you see specular shine coming down walls. But, when you go into rooms/halls, the shine still comes down from ceilings, b/c the ambient light is not impacted by shadows and know way of knowing when indoors vs outdoors other than the change in diffuse light color... which I used to create a luminance value to try to tone down specular in places when that light goes darker. But, w/o an occlusion factor to know when the light direction coming down has been blocked by something (an overhang, player indoors, etc), all I can do is kit-bash the ambient specular together to try to compensate. Second Breakfast To try to blend ambient specular better, I created a second ambient one using a hard-coded light direction coming up from the ground. "what?!" Yeah, sounds weird. But, what it does is create specular on the bottoms of walls.. and on ceilings now. So, the two speculars do the following spec 1... floor shines, top-of-wall shines (this was what we had already) spec 2... ceiling shines, bottom-of-wall shines (new) Wonder Twin Powers Activate... When the two are combined, they create complementary speculars on walls and ceiling seams to create a more cohesive continuity in shine. (IE: spec 2's wall shine merges with spec 1's floor shine, and vice-versa, so when you look at seams between floors and ceilings, you see a shine that transitions between the two a bit now). The idea here is that ambient light is bouncing all around, even from the ground up.. and even off the player onto other surfaces. So, we simulate that with a bit more specular around the player going onto more surfaces. Blinn Problem The problem is Blinn-Phong half-direction speculars (which look nice) brighten up the entire floor/ceiling for some reason... they create nice shiny trails up walls, but surfaces directly facing the light source.. they light up the whole surface.. they don't just make a spotlight shine or what-not. So, I used light dot to flip between nice Blinn-Phong trails on walls and just Phong spotlights on floors / ceilings. So, each specular is processing both a blinn-phong and phong spec then deciding which to use.. so, that's 4 speculars processing to combine into a single spec dot value that them merges with the spec map to create the specular light. This is some kit-bashed garbage on my part, but it seems to do the trick until a more elegant solution comes around. Oh.. I also got rid of the light dot curves... they seemed to work, but were culling the rimlight & speculars so much that all they did was highlight brick / tile edges. I liked it at first, but after experimenting it just seemed odd. glprogs.stages.interaction.064.zip

Good that it's working. Bad that we're not sure what changed to fix it. I try to document what changes can bork up things, so I know not to do things that way going forward. Without knowing how this bug got fixed, I could inadvertently introduce it again later. I'll mess around a bit more to see if I see anything.

v 0.62 cleaned up code a bit before screwing around some more fake spec maps no longer multiply by diffuse light color, b/c they're a light dot enhancement, not an actual spec light ... so, torches and direct light should no longer seem super-bright / color-saturated created NdotL curves in ambient lighting to tone down rimlight & specular on floors & undersides of things a bit more elegantly, so there's no glowing specular floors or rimlight showing up on the underside of canvase bundles... then spent hours tweaking specular & rimlight to look decent with it (PITA). The rimlight culling should help SSAO blend the bottom-side of things into shadow better. figured out better ambient rimlight booster for dark levels, so rimlighting looks half-way decent whether playing Training Mission or The Ravine glprogs.stages.interaction.062.zip

I'll need time to dig into this, but it gives me a place to start. I've run all around Training Mission, and haven't noticed anything. But, I have my grx options set to minimal due to running on an intel integrated gfx chip. What in-game gfx options do you have switched on? IE: SSAO, Bloom, etc? If you can give me a run-down, then I can go in and switch each on to see if the squares show up for me. Also, have you tweaked a graphics control panel for TDM? IE: Nvidia & AMD control panels often let you select a specific program to adjust adaptive vsync, better anti-aliasing for transparent textures, etc. Do you have anything like that setup? I'm curious if a control panel could be overriding the game and doing something extra.

One thing you can try...disable the NORMAL_INTENSITY It's applied to normal maps before they multiply by TBN matrix in pixel/frag shader. go into the "interaction.funcs.glsl" go to textureNormalCompressed function comment out the "normalSample.xy *= NORMAL_INTENSITY;" line (or set NORMAL_INTENSITY to 1.0) Maybe the change to RawN.xy before it muls by TBN is causing an issue?

Also, can you point out a specific map & location you're seeing the squares? Last time I saw them practically every where (eg: on Training Mission, in the stealth area, the light over the desk in the hall, the light in the warehouse by the metal wall...). Maybe you're seeing them in some specific place I'm not looking.

Ok, dug through forum. Pg 5 shows the discussion on it. The black squares were caused by me adding normalization to the TBN values in the common / ambient vertex shaders before they went into the TBN matrix to pass to pixel/frag shaders. Ever since we found that out, I rid of that normalization in the vertex shaders, and left a comment in the shaders not to do it b/c of that issue. I just tested 64-bit + bloom, and I'm not getting black squares on my end. I'm using an Intel integrated HD 4600. I included all my "interaction" folder shaders in the .zip. Did you dump all of them into your interaction folder, or just the ambient/common frag shaders? I'm guessing it's a PITA to update anything on your end when I keep chucking out a bunch of micro-updates, so maybe you kept some older versions of files around? Check your ambient/common vertex shaders for TBN normalization and comment it out. If that doesn't work.. post your shaders here, and I'll look at them when I have time. Maybe there's a gfx-card-specific issue going on.. something that is fine on my end, but not yours ... that we can pin-point.

Crap. I forgot what caused that. I'll have to look into it.

v 0.58 added normal map intensity to sharpen normals for a bit more faux depth both ambient & direct light use fake spec as a diffuse color enhancement now instead of a shine overlay shuffled diffuse & specular color params around to keep metal speculars from being yellow-glowy Param Shuffle This is something I screwed up a while back that I just noticed & fixed. Original shaders had param.specularColor applied to specular, and param.diffuseColor applied to diffuse. For some reason, when I first started shuffling things around to figure out what was doing what, I got param.diffuseColor mixed into the light attenuation & var_Color sub-proc I made. This put the base diffuse light adjustment value onto everything light color applied to (diffuse, specular, rimlight for ambient). So, metal bands on doors were glowing unnaturally yellow.. the columns in the hub of Training Mission glowed an unnatural orange. This was because the specular was mixing in both specular param & diffuse param, over-saturating the base lighting amount. So, I segregated those back to their respective elements. I also made the diffuse param have a minimum light value.. this is where the final ambient light color amount is "added in" to keep things from being pitch-black. So, if diffuse param is missing (IE: pitch-black) it will revert to a default constant MIN_AMBIENT_LIGHT value. (The light color function was already doing this, but I kept it with the diffuse param after splitting it out where it needed to go). Now surfaces with real specular maps don't glow an unnatural color compared to surrounding lighting. (EG: the metal bands on the door to the right in the image below. The lighting is more natural now, as it should be). Normal Map Intensity Stumbled across this site... https://github.com/mebusy/notes/blob/master/dev_notes/unityShaderEffectCookbook.md .. that talks about multiplying normal map .xy by a value to boost intensity. This enhances the faux depth of the normal map. So, I added it to the normal map algorithm after the .xy generate the .z value. I set a constant in the interaction.funcs file called NORMAL_INTENSITY which I defaulted to 2.0. It's a minor boost w/o looking too gaudy. B/c larger boosts (eg: 5 in the gif above) make the normals look like old-school games when normals first came out.. where they were trying to over-emphasize them to show folks how cool they were... "look at these chonky normal maps, folks! so cool!" Fake Spec 2: Electric Boogaloo Got tired of screwing with the shine of fake specs in ambient light, so just made them into a diffuse color enhancer like they are in direct/common light shader. I still use diffuse texture for the fake spec map, but I use it after the diffuse light color param has been applied to the diffuse texture. I do this, b/c the diffuse texture acts as a replacement for the specular map, and the diffuse light color param acts as a replacement for the specular light color param. But, it gets grayscaled, so ultimately it's just nuances. The grayscale fake map gets multiplied by the specular dot (specular intensity), and that's added to the diffuse light dot (diffuse intensity) to boost its intensity. By doing this, surfaces with real specular maps stand-out a bit more now. EG: metal beams along a brick wall.. the metal beams have a real spec map, so shine, while the brick has a fake spec map, so has a very faded shine / boost. glprogs.stages.interaction.058.zip

Do you mean through my graphics control panel or through an ENB-type program (like ENB or ReShade)? I don't change anything in my graphics panel, nor use any ENB-type program when running TDM. I want to keep everything on my end as neutral as possible to see what TDM looks like as-intended. That way I can try to enhance something ("try" being the operable word ) without getting too ham-fisted about it. If I had ENB shaders and what-not running to drastically change colors, then I could be modifying the lighting shaders to benefit what *I* see, but when others use it it could look awful. If you're instead wondering why my shaders seem to be a bit more "colorful" (colors are a bit more saturated / enhanced.. like torch lights)... That's b/c specular is faked & added to more things. If a surface doesn't have a built-in specular map texture, I fake it by making a grayscale out of the diffuse rgb color texture. But, I apply it differently in ambient (shadow) vs. direct (torch, lantern, etc) lighting passes: Ambient ... fake spec gets multiplied by 1 - color texture (inverted color) to make it a dull shine before adding it to final ambient light mix. Direct ... fake spec shine added to surfaces was making them too shiny (like everything had car clear-coat on it reflecting light .. EG: bricks were having a bright shine come off them). So, as an alternative, I multiply the spec dot (specular intensity) by the fake spec map, then add that to the light dot (light intensity) which gets multiplied by the color texture. This turns the fake specular into a color enhancer. Also, the original shaders were taking the real specular values (EG: for metal surfaces), and multiplying it by ... (diffuse * 0.25 + vec3(0.75)) This would add in a bit of the color texture, but not too much. My shaders don't do that.. but I'm probably going to add it back in, b/c on some metal surfaces (eg: metal banding on some doors) the light shine is very colorful (eg: the reflection looks glowy yellow, and sort of sticks out like a sore thumb). Shaders are art and science.. can apply the math, but need to tweak based on what looks goods. The other thing is the rimlighting is applied to more things in ambient lighting. There's a parameter set for rimlighting, but, while testing, I didn't see it set, so it wasn't getting done. It could be that this is a feature that will be used in the future, so they built-it out in the shaders now. But, I decided to create a fallback method to do rimlighting if that parameter isn't set. The rimlighting uses the parameter color value if it's passed in, otherwise it uses the (once again) color texture value to enhance the lighting. This might enhance the color of surfaces in shadows a bit. But, the main goal is to make things in shadows have a bit more body / depth to keep them from flattening out too much, and also help the player see a bit better in very dark areas. (The rimlighting acts as a very faint "echo vision" highlighting objects in the dark.) TDM does a gamma correction toward the end of the lighting passes, and does an HDR (high-dynamic range) in the post-processing passes for frames. You can adjust gamma & brightness, but not HDR or color saturation inside the game. The HDR just boosts the range of colors, but keeps them inside a range that's displayable. It's just working with the colors already there. Not sure I answered your question.

v 0.57 fixed issue (I caused) on TDM's original ambient rimlight.rgb stopped mul'ing ambient rimlight by inverse diffuse / specular map mix Been a while, but finally had a chance to circle back to the shaders. For ambient light, I have the fake spec map multiply by inverse diffuse color to help dull the shine. I also applied this fake spec / diffuse mix to rimlight to dull them, too. But, while playing some missions, I noticed it made the rimlight look like a monotone, uniform oily or smudgy color covering textures, covering up the underlying texture color. So, I removed the inverse diffuse / spec map mix from ambient rimlight. But, I kept it for ambient specular, because the dulled specular does blend nicer with shadows. I also farted around, and found out the clamp I used on the original rimlight rgb (that gets added at the end of the ambient light shader) was causing the water to disco light. For some reason the var_Color and clamp did not play well together. So, I commented that out. I added that clamp to keep dark textures from neutralizing rimlight / fresnel too much. So, I created a replacement rimlight rgb function. I chucked in the code from the light dot rimlight that uses the diffuse color luminance and light color luminance to enhance rimlight amount as either / both get darker. I tested it on The Ravine, and it did enhance dark areas a bit. Then I tested the water on Training Mission to make sure it wasn't spazzing out.. and it seems to be fine. There might be a more elegant way to do this, but this is what I came up with. glprogs.stages.interaction.057.zip

This cured my constipation. Only bug (very minor) was... My only concern with the map is... Still, A+ work on atmosphere and balance between hiding things, but not so much I felt like an idiot. Like Valve said about Portal, you want to make puzzles easy enough for folks to figure out, but hard enough that they feel smart when they do. When I got lost, I looked at the map to see where I haven't been yet. You used sound and such to provide ample prompting on things. When I'd find a switch I felt smart. Didn't have to come over here to look at spoilers. Really good map. Look forward to the continuation of the story if you choose to do more.

Yeah. I've noticed that. AI mobs have more curves around their edges, so rimlighting is more prominent on them. And lighter colored textures created lighter grayscale fake spec maps, which make shinier fake specular. So, her edges are highlighted extra prominent, and her skin looks oily / plasticy. Without individual textures having their own built-in, real spec maps, or the game having some kind of surface-type variable to differentiate surface material type (fabric vs. metal vs. stone, etc), all I have to go on is their diffuse map to make fake speculars. If I could do an if/else on material type, we could dig up some materials algorithms to apply to things to make fabrics look duller/rougher, metals more metallic/shiny, bricks/stone more "bricky/stoney", etc. I don't think that flag is tracked in the game, though. (I don't know.) So, doing best I can with what I have an know how to do. If I mess with multipliers to make her look good, other things, like walls and such, end up losing so much specular or rimlight that the effects are barely noticeable, if at all. Then tweak things to make them look good, other things stick out. Catch-22. ~~~~~~~~~~~ For things that don't have real spec maps, I thought about just going back to mul'ing fake spec map by diffuse texture rgb again to just give them a color saturation boost. But, I stumbled across a Quake Wars: Enemy Territory wiki that talked about using inverse diffuse texture as specular color to create a more "neutral" (matte/diffused/monochromatic) specular color. https://wiki.splashdamage.com/index.php/Basic_Texture_Overview I tried it with ambient and direct lighting.. and it makes ambient specular look better (not as prominent, more blended into shadows/scene). For direct light.. not so good IMO. So, I only applied it to ambient light... grayscale diffuse texture = fake spec map inverse diffuse texture = fake spec color In doing that, I go back to using the specdot * specular.rgb for fake spec light finalization again. Then I experimented with making rimlight an .rgb again, but only inside the non-cubic branch. I mul the rimlight dot by specular.rgb for color... and it helps diffuse/tone down/blend the rimlight a bit more. And, oddly enough.. when I just keep that rimlight in the non-cubic branch.. my water on Training Mission doesn't disco color on me. So, I'm not sure why the water disco lights when rimlighting is done outside the branching. Everything seems to use non-cubic branch, so .. just gonna keep rimlighting inside there for now. I've attached v 0.56 shader .zip v 0.56 inverse diffuse texture used as fake ambient specular & rimlight color I'm testing it out as I play Blackgrove Manor. glprogs.stages.interaction.056.zip

I'm gonna chalk those artifacts I'm seeing up to my crappy intel integrated HD gfx chip then. Specular & Rimlight both have been the "never gonna be happy with it all the time" variables for me, b/c when they look decent on one map, they look awkward or non-existent on another. One issue with Specular is when doing it in Ambient.fs, it doesn't occlude when inside buildings or dungeons or what-not. When outside, with the moon in the sky, it's natural to see a specular shine down a building. But, when inside, the shine coming down a wall looks unnatural. So, I try to tweak the specular to not be so gaudy. The problem with tweaking specular is that folks like you and me are hyper-focusing on it while modifying things. So, we have a heightened awareness of it as we look around levels, and tweak it as such. But, regular players that aren't hyper-focused on it may not notice it at all if we tweak it too low. That's one reason why I err'ed on the side of "a bit more specular is better than not enough". No sense in processing the effect if it's hardly noticeable by anyone. But, you say it's very strong... can you post a screen shot of what you're seeing? Maybe your getting a different output than I am on your gfx hardware? I mean, if my gfx is giving me weird artifacts while yours isn't, maybe the specular looks different when processed by both, too? Ambient rimlight is also a pain... when I switched over to using the common.fs style of rimlight to avoid the disco lighting of water (still not sure why it's doing it), the rimlight acts as a whole-level brightening. So, I have to tone it down. But then some levels are super-dark (eg: The Ravine), and the rimlight is non-existent. So, I have to kit-bash in a hack to brighten up rimlight when textures/ambient lighting is super-dark. Then there's levels like Marsh of Rahena that don't seem to use Ambient light for the darkness...d'oh. I also had to apply the 1-NdotL hack to rimlight to keep it from over-brighting ground same way specular was doing. Then there's personal preference... some folks may want more specular / rimlight .. some may want less .. so it's just never going to be one-size-fits-all. And, the real solution would just be to go through all the textures and create real spec maps and such that are missing. I wonder if there's an offline batch process algorithm that can do that? They have data sci algorithms that can batch-process upscaled image resolutions. (Folks that play original Doom did that to the graphics to take the original low-res graphics and artificially high-res them into a texture pack, that way the graphics card wouldn't have to waste processing doing it on-the-fly). Even if there was a batch processor to create spec maps, or convert non-PBR stuff into PBR by creating albedo, roughness, etc maps.. it would still take sifting through the results to make sure it all looks decent. An algorithm might be fine for a majority of things, but may not make some stuff look decent. This guy's using a software program, but I wonder if there's like a python lib to code up a batch process... That's beyond the scope right now, though. LOL I've attached a new version of my modifications with a few more tweaks... v 0.55 ambient rimlight takes darker shadows lighting/color textures into account and brightens up a bit to keep from fading into nothing on super-dark maps (only on maps that actually use Ambient light, like The Ravine... not on maps that ignore Ambient light.. like Marsh of Rahena) like ambient specular, ambient rimlight also dims on ground (1-NdotL) to keep ground from being super-bright and awkward. But, added in a max() to cap the negation, so it doesn't get rid of it all. I started experimenting with ManyLights, but no drastic changes in this version. First experiment was finding out that we can create varying arrays to pass arrays of values between vertex & fragment shaders. So, I thought it'd be smart to pre-calc things for each light in the vertex shader like I did in interaction shaders.. so, "for each light in lights, pre-calc TexLight, Attenuations, etc" and pass arrays of that to fragment shader. Got it going, and it killed performance. LOL! (IE: I was getting like 12 FPS in the archery yard on Training Mission, and suddenly I was getting 2 FPS.. LOL) Memory is the constraint. Too much stuff demanding too much gfx memory to pipe over. So, nixed that idea. I run stencil shadows instead of shadowmaps, b/c of my podunk gfx chip, so lost interest in messing with manylights. glprogs.stages.interaction.055.zip