totallytubular

(tl;dr version) FAKE_PBR is actually not working. The shaders don't seem to register the #pragma tdm_define flags I set, so it's been running the non-FAKE_PBR branch this whole time. (and non-BLINN_SPECULAR, which means it's doing phong speculars). Anyone know where TDM dumps GLSL compile output log or something, so I can debug what's blowing up? (long version) Was modifying code to make it easier to switch between different fresnel, visibility, etc func's. Added red-highlighting to BRDF spec output in a func to make sure branching was working. Nothing was highlighting. Went up the chain to the BRDF function to highlight outputs .r * 100 ... nothing. Went into amb/common to highlight the light output .r from BRDF branch..nothing. Finally realized that the code's been running the !FAKE_PBR branch the whole time. I replaced the ... #pragma tdm_define "FAKE_PBR" ... with... #define FAKE_PBR .. to see if I could force the define that way. Nope. I switched the code to use bool constants for PBR & BLINN... nope, everything in game world decides to be dark, which means ambient & common fs shaders blowing up during compile. I've been commenting out large chunks of code to cut out PBR to just get back to something that will compile and work, so I could go from there.. but something's so borked-up I can't figure out what's borked up. I'd rather not waste time guessing what's borked up. Would rather see GLSL compiler output, so I have some clue what to look for. Not sure how to do that.

I'd never heard of BRDF until I got on these forums, so didn't know where to begin. I came across the OpenGL theory page that talked about BRDF, and, while it gave code snippets, they didn't put it all together the way urho3D did. Urho3D's version was the first complete version I stumbled across that was simple and straight-forward when random googling. Their implementation of BRDF was easy to understand and plug-n-play in-a-day. Right now I'm just doing some quick-n-dirty messing around to see if BRDF teamed with the fake AO/spec maps does anything magical. I'm looking at Disney's a bit and it's ... pretty complex. At least for me. They've got GLSL mixed in with C code to do a whole application to explore things. Would take time to dig in and figure out what parts to use. If real BRDF / PBR was being implemented in TDM, it'd be good to look at Disney's version. But, for now, I'm just messing around. (I'm killing time farting around on this while I'm looking for a job, so I don't go stir crazy.) Disney's license looks pretty open, though. TDM has a LICENSE.txt file. Could just chuck the 3rd-party licenses into that as sections, then in the code make comments like "this code pulled from (web-site), and has license in TDM's LICENSE.txt file, section XYZ". Didn't mean to derail the topic talking about licensing. Just something I suddenly thought about after pasting in and using tons of code I found and going "crap, this is pointless if there's going to be a license issue."

One thing I didn't think about until just now... licensed usage of code I plugged in. I looked at the urho3D github for a license for the BRDF / PBR ... they have a very open-ended MIT license... https://github.com/urho3d/Urho3D/blob/master/LICENSE just asks that the copyright be included with the code. I can paste that into the "interactions.pbr.glsl" code file no problem. The code snippet I copied from the Filament github for specular AO... I went up the tree on their project, and they have an Apache license. https://github.com/google/filament/blob/main/LICENSE Section 4 talks about redistribution of code with several steps to provide notice and attribution. Not quite sure how to do that. Not sure if that's something to think about now or later .. or at all? Since TDM is a big project, just trying to dot the i's and cross the t's to make sure things are done in a semi-official manner to avoid issues.

v 0.23 realized BRDF diffuse & specular outputs are good-to-go as-is, and just needed to add together then mul by lightcolor, so adjusted end routine for BRDF to do so w/o running them through light dots further shuffled code around in ambient/common lighting to skip calc'ing stuff not needed for BRDF switched to dot'ing fake AO/Spec maps by a luminosity rgb instead of 0.33 to try to make them a more natural grayscale figured out (I think) how to apply fake AO to ambient BRDF to impact both diffuse and specular BRDF is uncharted territory for me, so I'm still learning as I go. The github repo I pulled the code from had the BRDF / PBR parts, but didn't explain how to apply AO and such. I stumbled across this site... https://google.github.io/filament/Filament.md.html ... that talks in-depth about stuff, and has a lot of GLSL code snippets. That's where I read-up on the AO. I hard-coded these shaders to use the most "complex" diffuse and specular BRDF functions from the github repo I first used. But, since there's lighter versions of the functions, BRDF could end up with "levels", like SSAO, where end-user could choose how complex of calculations they want. That's something to think about later, though. I'm actually really impressed by the BRDF functions.. not in that they make everything look good (I'm not sure I notice that big of a difference). But, more in that it encapsulates pretty much everything you want to do with lighting. It processes the specular via fresnel, it applies the spec dot to specular, it runs diffuse through a function that applies light dot.. that's at it's most basic. It goes into much more detail in what it does, but it handles a lot of the stuff the amb/common light shaders were doing. Just have to calculate the normals, directions, light color, etc, then shove it through the BRDF in a line of code, and out pops the end-result diffuse & specular that are ready to just add together, mul by light color. glprogs.stages.interaction.023.zip

Experimented more... Disabled all !u_cubic branch so only u_cubic == 1 branch runs (and leaving everything else outside the branch un-touched). Got this with the special window in Training Mission... nothing. Window doesn't show up. Then I disabled all output from both ambient.fs and common.fs (set their final rgb's to 0) to see what shows up. Got the following... So, some windows are bypassing the ambient/common lighting shaders to act as a pass through. It seems like that special window should too? I think there are some windows that do use ambient/common lighting shaders, because they're doing specular effects (shine off glass), etc. But, I'm not sure what's going on with those windows having issues. It's like they should be bypassing, but aren't. But, are not sending a flag or textures or something to the shaders to use. (IE: because they could be calling the shaders correctly, but if the texture they're trying to call and use isn't set, it would return an rgb color of 0.0 which would make it seem like it's not working.) Again.. total noob here.. all I've stared at is shaders. Don't know how game engine works, or what it's piping to shaders.

Conclusion first... "u_cubic" isn't getting set to "1" in game engine, or isn't being piped in properly or something. Experiment 1: I put original 2.09 shaders back into "interaction" folder. For ambient.fs, set final light col in u_cubic branch to .g*100 and other branch is .b*100. For common.fs, set lightcolor u_cubic branch to .b*100 and other branch to .g*100. Swapping them should give us night bright overlaps to see how they interact. I get the following... Our problem window is not lit up bright blue. Experiment 2: set common.fs final output to .rgb = vec3(0.0) to nullify it kept ambient *100's the same. Got the following... Everything's blue, which means everything is using the != u_cubic branch. Experiment 3 .. flip it: ambient.fs final output .rgb = vec3(0.0) common.fs *100's returned Problem window is pitch black when it should be blue. So, it's using the non-cubic branch, but since that's not pulling the cubic light texture, it's pitch-black I'm guessing. I did experiments like this when first mucking with the shaders, and got same results. That's why I commented shader code that it seemed like u_cubic branch wasn't used. I never saw color changes for it. Figured it was pre-coded for a future feature enhancement. But, it looks broken. I don't know where it's broken. I haven't looked at game source code. I just stare at shaders. Someone else more knowledgeable about the game source could look into this?

If it's just a light source parked next to a window to make it look like the window is giving off light, then it makes sense. It shouldn't have diffuse color or specular. Heck, it shouldn't have normals or anything. It should just be a light source. There's windows that have "shine" coming out of them, and those will have diffuse color for the "rays", but they shouldn't do normals or speculars. Should just be a diffuse color piped through with a reduced alpha transparency. They're just simple sfx that don't need as much processing as, say, a texture on a wall or such. I don't know exactly how the game engine works or how it processes these things. I just know what I've seen in the shaders for TDM, and how I've seen things work in other games. So, I'm kind of at a loss for figuring out what's causing the pyramid lights to bork up and how to fix it.

Is that all in the "interaction.ambient.fs" shader file? main() branches with a "if ( u_cubic == 1 )", and I set a "light.r *= 10.0;" on that first branch to see if anything lit up, so I'd know where that branch was being used. Nothing lit up red. Made me assume the cubic branch wasn't used. Or at least not used in Training Mission. Everything I've done in ambient.fs has been in the 2nd part of the branch, and outside the logic branch with fresnels wrap-up and such. Everything made me assume those windows/lights were tied to some other legacy shader that I couldn't find, or were still being handled by the game engine's built-in graphics or something. I can mess around with it more. But, I'd like to confirm first that that branch is indeed running those windows, so I'm not wasting time fixing something that isn't the cause. I don't know how to confirm what shader runs those windows.

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 routine https://github.com/urho3d/Urho3D/blob/master/bin/CoreData/Shaders/GLSL/BRDF.glsl // BRDF sub-routines ...and chucked it in a file called "interaction.pbr.glsl" that gets imported in ambient.fs & common.fs. Can switch it on off by commenting / uncommenting the "FAKE_PBR" define. Can't tell much of a difference (imo), because using faux Specular & Roughness maps. But, the code is there now. Bit of a hit to FPS, but I'm running TDM on an integrated Intel HD 4600 (my GTX760 crapped out). I'm still getting around 20-30 FPS, though, using stencil shadows & med SSAO. glprogs.stages.interaction.022.zip

You mean this...? .. where it looks like a rectangle shape that's not taking the shaders into account? I have no clue what's causing that. I see it randomly. On some levels it's like a massive volumetric fog effect is floating around causing cut-off seams to show up. Other times it's just windows. In Training Mission, some windows are fine, but others have this issue. It feels like some level assets are using old shaders or other shaders than what I'm messing with. I don't know.

v 0.20 More of a cleanup and refactor than anything else, since code changes I made started looking like a hot mess. created interaction.funcs.glsl to consolidate common funcs across common.fs & ambient.fs 1.0 - x*x - y*y = 1.0 + dot( xy, -xy ) ... so switched normals partial derivative formula over to dot() glprogs.stages.interaction.020.zip

I downloaded Visual Studio and opened the source code, but haven't dug around much. Got sucked into the shaders, since I know a bit about those. But your explanation confirms what I thought. Sort of makes me think that the fresnel backlight effect also needs a 1-NdotL to make it not glow underfoot, too, if it will start making it harder for player to sneak. But, I lowered the AO color and the speculars in ambient got 1-NdotL, which both toned down the shine underfoot. I tried a cubemap as a rain sheen... in glprogs/parallaxCubeReflect.fs, there's "u_texture0" that says it's an environment cubemap. Figured since it was a uniform, I could tack it on another shader and have it pipe in (if I'm understanding uniforms correctly? They're sitting in register, and you can access them in a shader by calling them via uniform?) Anyways, it didn't look good. I got it where objects, like tables, benches, chairs, etc.. all looked halfway decent with a cubemap sheen on them.. looked like clear-coat varnish was applied to them. But, things like floors, walls... it's like nothing was applied to them even though they were going through same processing. I could barely see any reflection on them. The cubemap reflection comes through looking like quicksilver / liquid metal, so have to tone down how much to use and then merge it with the diffuse. And, by the time you get something looking nice on one thing, everything else is bleh. So, I gave up on that for the time-being. My next hack was trying to use the fake AO/spec map derived from dot(normal,0.33) as a depth map for parallax occlusion mapping. I followed the opengl tutorial for it. Basically had it mutli-sampling the dot(normal,0.33) over and over as the depth map for POM layers... it didn't go well, either.. lol. I think I've pushed the limits of how far my little fake map hack can go. I thought about hacking in PBR code ... already got diffuse which can be used as albedo, got a normal map, can fake an AO map, and use it as fake spec / smoothness / roughness map. ... only thing missing is the metallic map which might be faked some how. Figured I'd just hack it and see how it looks. Haven't gotten around to that yet. My career as a data analyst revolves around making ad-hoc reports that fill a need quickly until a more robust reporting solution can get built. So, fake it until you make it. Sometimes it works, sometimes not. Issue in the working world is when the ad-hoc becomes the main solution rather than what it is: a glorified band-aid. But, a glorified band-aid might look nice temporarily, or as a fallback.

If things don't have custom textures for it, just use a fallback method of mixing in a reflective cubemap of the game world. That way if the game upgrades to PBR later, old levels still using old non-PBR assets will have a cheap fallback method to help blend in. For the FUEL shaders, textures didn't have any wetness materials textures or such. I just added a % of reflective cubemap to sun light and shadow light as the rain increased. This gave everything a default wet look. I would tweak it if I could. EG: I was able to capture a flag to determine asphalt vs. dirt/ground. So, that let me tone down dirt sheen (b/c dirt becomes more mud, while asphalt tends to keep water on the surface). My idea is to just find alternative, cheap approximation methods to simulate something if it can't be done the more technical way. Is there a reflective cubemap vec3 I could pipe into the interaction & ambient fs shaders? I could mock up something as a proof-of-concept

Yeah, kind of agree with this. Fresnel is one of those things where everyone's gonna want to fiddle with it. Some want none or very small amounts. Others will want a lot. Fresnel can be a "cheat" to see in the dark. Makes player feel like they have "echo vision" to sense surroundings in darkness. For a sneaking game, it can annoy some players. It can also bring back PTSD for old gamers that remember playing games when fresnel first became a thing, and game companies were slapping tons of it in things making gamers go "why is everything lit up in darkness? what is this?!" (eg: jason brody in Far Cry 3 going into caves... I think they use amped up fresnel to give him "night vision", and it's odd). I think Thief 3 also did this. Def did fresnel with the frob-highlight, but I think they slapped it on a lot of things, and in monotone fashion, so everything had a dark blue cast to it beyond just ambient light. I guess they were trying to be atmospheric. The other issue.. I think the lightgem works based on overall lighting (?).. so anything that amps up lighting could potentially impact player's ability to sneak. Fresnel is an additive effect (ie: final light color + fresnel enhancement). In small amounts it doesn't impact, but when ramped up it could possibly mess with light gem in what are supposed to be dark shadows. I don't know how light gem works, just guessing based on my testing. When I was messing with fresnels in ambient light, the light-gem could never go completely dark, making it harder to sneak in the hammer area of Bikerdude's Training Mission. When I added in faux AO map to darken shadows up, it seemed to counter the brightening of the fresnel, so the light gem darkened again. I definitely feel the "backlight" effect (if used in TDM) needs an on/off switch. Some folks hated that effect in Thief 4; they didn't want to feel like a dim spotlight was hovering over the player. I added that effect in to help the player see in very dark areas ... eg: trying to read a sign or look for something on a shelf in a very dark area.. that very small amount of lighting is just enough to help the player see something, as if their vision has focused in. But, the 1-NdotL to kill speculars on the shiny floors in ambient light (b/c they made player look like they had a spotlight at their feet) killed the effect some.

v 0.14 Switched fake AO & fallback Spec maps to use dot(raw normal map, 0.33) in both ambient & common fs. Switched specular over to use diffuse.rgb color as specular color if no specular.rgb / map texture instead of default static value Normals as fake maps... wasn't happy with how over-dark some things were, eg: the pillars on BikerDude's Training MIssion, when using dots of specular or diffuse as fake maps. So, decided to check out normals instead. I knew normals provide edges to help create the bump-mapping. However, using the normalized & TBN'ed version, I got some surfaces that were pitch black. But, when I dotted the raw normal, I got this... This is a more even-tempered grayscale map for the whole scene. (cut-off seam are from piping the dot product straight through w/o light impacting it). Compared to this... Which was using dot of specular map if it had it, otherwise using dot of diffuse. The over-darkening can possibly be considered a half-arsed materials type of variation on surfaces. But, I'd prefer all surfaces having a more even grayscale to them for a fake AO / specular. Reason being.. I got aggravated with FUEL when vehicles and riders would look over-dark in overcast skies. They looked out of place. Couldn't figure out what the deal was until I piped some materials lighting values directly through, and realized they were applying a default dark gray to some objects lighting.. which over-darked them. When I ripped that out, it was easier to blend things together to look more natural in a scene. (crappy base "materials lighting" FUEL game piped to shaders, which made some things over-dark in overcast skies) So, decided to go with the more equalized fake AO / Specular map. The variations in detail should come from diffuse color, lighting, etc, not from drastic differences in fake maps. (The fake maps are crutches. Shouldn't create drastic differences.) Diffuse for Specular Color TDM shaders did variations on this, mixing in diffuse*0.75+0.25 and such to specular. I pulled that out when I decoupled specular from diffuse, because ideally specular shine amount would be set per-surface / texture. So, dull objects would have a dull shine to let more diffuse color mix in. But, there's static params in the shaders setting amount of specular to use. For shiny metals, it looks ok having white shine come off. But, dull rusty pipes, walls, etc.. not so much. So, if the specular.rgb is missing (which acts as both specular map and specular color), I made the shaders fallback to using the diffuse.rgb as the specular color. Using diffuse as-is, everything looks wet like it's raining or just rained. So, toning it down... Diffuse * 0.1 as fallback spec color. Now it's looking normal again. The color variation is more noticeable in shadows, b/c both specular fallback color and fresnel highlight fallback color rely on diffuse colo rnow. So, the brick is a darker highlight. The bronze metal is more orangish. The white metal door is grayish. Vanity shot... fake AO is darkening seams more now while leaving the "body" of objects to shine through. (IE: the stones on the ground are now having a bit easier time having their highlights on top show up, b/c the normal map as fake AO is more interested in darkening the already dark seams between stones. But, the wet-looking speculars brings up the idea of using a value piped in from the game engine to lerp between dry and wet specular values if environment is raining / damp or not. I'm not sure how level designers flag areas to do rain, or if the value could get piped into the shaders. But, it could create more dynamic environments. EG: walking in the streets in rain, and the streets look wet. Then walk inside some place, and the inside uses dry speculars. The next step on that would be to mix in environmental reflection to make the rain sheen look more rain sheeny. (Because just over-shining speculars tends to make a cheap but tacky wet look.) outval = mix( dryval.rgb, wetval.rgb, vec3(rainamount) ) (EG: The dark rain sheen on the road ahead and the white sheen on the tires is from a cubemap reflection that increases as the game engine's rain value increases, which is used as a lerp factor between dry and wet shading. The FUEL game engine piped in a rain value, and did cubemap reflection for water fresnel reflection. I just put them together in other object shaders to create rain effects on ground, vehicles, etc.) Anyways, shaders are attached. glprogs.stages.interaction.014.zip

New version (see attached .zip) Uses texture diffuse color as fresnel highlight color for the fallback fresnel branch in interaction.ambient.fs. This helps fresnel blend into the surfaces and scene better, instead of looking like a monochromatic haze on everything. Also, in some missions I'm seeing a pink / red sky (eg: Lord Edgar's Bathhouse). I looked at screenshots of the mission, and it's supposed to be blue. Not sure if something in my shaders is doing that. I thought I had set something to .r *= 10 to highlight what the shader impacts. But, sifted through the shaders and I had all those parts commented out. It could be that the sky is using a branch of shading that I thought wasn't used any more, and I mucked up something. Not sure. That's the main problem I'm having.. I can't tell which textures are using which shaders. So, I can't tell which shaders are worth messing with, and which ones I messed with having adverse impact later. That's why I was hoping there was a project document that maps out what hooks to what. glprogs.stages.interaction.012.zip

Yeah, in the FUEL shaders, it was a b**** and a half getting the chrome/clear coat reflections to blend properly in light/shadow. Had to process the final diffuse with lighting / shadow first, then mix/lerp the cubemap in via fresnel that was impacted by shadow to make the lerp use more diffuse in shadows and more clear coat/chrome in light. I noticed in TDM every now and then there'd be a glass object that's super-bright in ambient shadow light. Thought I'd take a crack at evening that out, but haven't found a shader that controls that yet, though. I'm not sure what shaders are used / aren't used, or what they impact. So, I've just been dinking around with what I know impacts things so far. Is there documentation somewhere that says what files control what, and are/aren't used?

Replying to various points I see made... The backup Fresnel would def look better with materials lighting toning it, b/c it's too monochromatic and even-looking. I thought AmbientRimColor was for materials, so when I noticed many things didn't use it I just figured they didn't have materials-based lighting implemented or their textures weren't prepped for it. Hence I chucked in the fallback fresnel. But, since the fallback fresnel is very monotone (monochromatic.. blue/gray haze on everything) and everything looks the same in shadows b/c no variations based on texture or materials I then tried applying the fake AO from dot(diffuse, 0.33) to add in variation to the fresnel (darker parts blocked more). But, lots of stuff just got their fresnel cancelled out when I did that. (EG: there's this dark brick texture on Saint Mattis FM in the underground .. it's so dark it just cancels out the fresenl if I mul it by fake AO). Tried doing a "if AO < 0.5, use 1-AO" to flip it, but it just went back to looking very monotone. That brick texture was also the one I I thought had no real normal map applied, but when I just piped normals through I saw it did have a normal.. just a very flat-looking normal without much variation. (IE: not as bumpy as, say, a round-rock stone wall texture). Looking down some walls, it looked like fresnel on a sheet of glass, but that was b/c the normal map on the texture was very flat. EG: wallpaper with the raised pattern..just looking down that wall the fresnel looks flat. But, zoom in with spyglass, and notice the fresnel is hugging the normal, it's just so faint that you don't see it unless zoomed in. Since missions can be a hodge-podge of assets, the goal was to use the shaders as a "butter knife" smoothing frosting on a cake. If textures can do PBR / materials and other stuff, then they take those branches. If not, then they use fallback methods to try to still add some detail. In a perfect world, every object/texture in the game would have PBR / Materials, specular maps, AO maps, etc. But, it's not perfect. The great part about shaders is we can do hacky fallback stuff if the cool stuff is missing. My idea is also to try to automatically offload some cool effects onto the shaders, so the FM designers don't have to think about it. EG: a shader that controls water should always add some default reflection to the surface, or, better yet, do calculations to determine transmission vs. reflection when looking down at the water vs looking parallel to it. And, do some depth calculations to determine where water edge is for edge softening / blending. Maybe also add a default water color value to blend in, so all water isn't crystal clear. That way FM designer just has to slap some water in their level without having to worry about messing with it to make it reflective or realistic-looking. Or, things like floors where the "tap tap" walking sound occurs, just have the game engine automatically use a shader that applies a slightly reflective cubemap on those textures to make tappy tile floors look polished and slightly reflective. Just build in some default enhancements that the game engine & shader logic handles, so the FM designer can focus more on making a level instead of trying to mess around with making textures and objects look good. I am still very much a nub when it comes to shaders. I hit my level of incompetence pretty quick when I start reading some of the white papers nvidia/amd publish on how to implement things in shaders. But, I like messing around with them, and like the idea of the shaders being able to make things look nicer automatically without level designers having to worry about micro-managing details like that. The shaders I chucked up here are just a WIP of hacks to see if the shaders could help smooth out more enhancement. There's def better / official ways to do things (like PBR). But, also hack alternatives to fallback on that the shaders can do when that's missing.

I don't think it's bindless textures. I modified the diffuse texture pull functions to make anything in bindless one bright color, and anything not using bindless another bright color... Basically... vec4 diff = (pull texture); diff.r *= 10.; return diff; That sort of thing. Nothing seemed to use bindless textures. i went and commented out the normalization I added to the TBN matrix in the vertex shaders to see if maybe that was doing something, but nope. The more I play, the more I notice it. I'm running through The Heart of Saint Mattis right now (jesus christ, great level!), and noticed very detailed textures look "spazzy", then I zoom in and notice it's because the texture has very distinct cut-offs between squares. EG: in the cemetary, the dirt plots over the graves. They're detailed grass or dirt. But, zooming in with spyglass I see stark lines where some pixels of texture seem to be missing or something. Again, I don't know if it's something I did. Maybe using diffuse as fake AO is causing this. Not sure. Another thing I'm noticing is that some textures don't have normals.. or, rather.. probably using the normal from the TBN matrix piped in from vertex shader. I notice it via the fresnel. Look down a wall at an angle, and it's like a sheet of glass with smooth fresnel even though it's brick. There's a sub-routine that does either normals * TBN, or just pulls normal from TBN to return as normal. I'm gonna experiment with that branch. If the normal from the vertex is being used, we might be able to branch and skip some of the processing that the full-bodied normal might use. I don't know. Gonna stare at them more later. Wife just came down with strep throat or something, so kind of busy being nurse maid.

Got a pm from a user asking me how to install the shaders. I took it for granted folks staring at this part of the forums would know the source code break down and where to stuff them. So, here's some instructs for folks that don't know what to do with the files... For Dark Mod v2.09, do the following... 1) go to your dark mod game folder (where you installed TDM, and where the .exe executables are) 2) make the following folders / folder path (this is important, b/c it changed for 2.09) glprogs\stages\interaction\ 3) if you have those folders, and there's stuff in the "interaction" folder, then either zip up the original files there as a backup archive, or make a sub-folder like "\original" or something to put the following files... interaction.ambient.fs interaction.ambient.vs interaction.common.fs interaction.common.vs If you don't have those folders or those files, then no big deal. It just means you don't have them (which means the game has been using whatever's in the pk3 resource files that come with it's install). 4) after making that folder structure and/or backing up your original 4 files, unzip the files from the zip in this thread into that "interaction" folder 5) start the game The game should override pk3 resources with whatever loose files it finds in same folder structure and file name. So, firing up the game with those glprogs sitting out in that folder structure, it'll use those instead of what it has in the pk3's. You should be good to go. If you notice the torches don't emit light (pitch black) or the shadows are pitch black, it means something's borked up in the shader files and they're not compiling. (When the game notices a borked up shader file, instead of just crashing like a lot of DX HLSL stuff does, it skips it instead. Since those shaders handle lighting, pitch-black means they're being skipped and not doing the lighting.)

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 control bulk of lighting. broke out diffuse & specular lighting from each other again.. and figured out why specular was getting cut-off seams last time. It's because I didn't mul specular by light source, which takes attenuation into account. Did that this time. ambient.fs specular is generated from world light shining straight down, so was creating a spotlight under player on shiney floors (eg: gamma room floor on Training Mission). So, applied a 1-NdotL to have it use the light dot and not apply to surfaces perpendicular to the world light source (IE: ground). common & ambient .vs files didn't look like they were normalizing T,B,N before loading them into TBN matrix, so normalized them. (I think one was using a clamp, but switched it to normalize). Not sure it makes a difference or not. common.fs generated the normalized & TBN'ed "N" variable, but then used RawN in the NdotX calculations. Switched it over to using N instead. Not sure it makes a difference or not. ambient.fs was using AmbientRimColor to apply a fresnel highlight to final color, but after testing, didn't seem AmbientRimColor.a was ever > 0, so no fresnel effect was occuring. So, added an "else" branch to fallback on a generic fresnel highlight. (The velour-style fresnel I used in previous shader). Tweaked it to try not to look gaudy. Got rid of most of the fresnel effects I slapped in, or shifted them around a bit. The "eye adapt" was just half-arsed specular effect, so ditched it. The backlighting I just use on ambient.fs, but gets washed out a bit in darker levels and because specular is negated on floors in ambient.fs now. Still, it blends with fresnel to help out some. The velour fresnel was moved as alt fresnel effect in ambient.fs when AmbientRimColor not set or pitch black. switched ambient.fs to use halfdir Blinn-Phong specular like common.fs does. instead of just using generic default specular amount for things w/o specular texture maps, decided to BS specular maps for them by using the diffuse texture map.. did a dot(diffuse.rgb,0.33) to get diffuse lum and create a faux specular grayscale map which I then mul the default specular amount by to tone it. Also did that to create faux AO maps... initially used diffuse to do all AO maps, but noticed pillars in Training Mission looked awkward, b/c the AO was following the dark seams in the marble instead of the carved lines. So, if anything has a real specular texture map, used that for the AO map, and if it didn't, used the diffuse map as both faux specular and faux AO map. The faux AO blocks the ambient shadow light, but a final AOcolor is added to keep AO areas from being pitch black. This helps darken areas down some. Might be tacky in some places. I've attached a .zip that contains interaction.ambient.vs, interaction.ambient.fs, interaction.common.vs & interaction.common.fs ... main files I farted around with. Here's some screen shots.. noticed some issues...not sure if my messing around caused them or what... ambient world light seems to always come straight down regardless of level designers placement of moon in sky. This puts the ambient specular always underfoot like a spotlight. Without some kind of occlusion factor for it to know when player is indoors or not, dark dungeon floors get lit up with ambient world light. That's why I used a 1-NdotL to kill specular on floors. The ambient world light is still nice to make speculars shine on walls and objects. Just had to kill it on floors, like the one here in gamma room on Training mission. (This was done before I clamped specular color down to be a dull shine). Some windows have a weird rectangle shape that doesn't blend well with the scene. It's like something that isn't controlled by ambient or common is not taking light attenuation into account. I experimented to see what ambient and common control, and there's some window textures that would stick out, which meant there's another shader being used to draw some textures. Couldn't seem to find it. I didn't spend much time digging.. but just looking in teh stages shaders, I didn't see anything else that could be doing that. The manylights shader doesn't seem to be used (?), so skipped messing with it. Not sure what's causing this. Seeing how Faux AO map will impact things. It uses either specular map (if object has specular texture) or diffuse map otherwise. Basically just getting the dot luminance of either to create a single float value gray-scale to mul light dot by to add more darkness to things. A final AO color is added in to keep things from being pitch black. Certain diffuse textures are missing .. something.. or processing is casuing this chunky issue. I noticed it intiially on some tile floors and windows on some levels.. in the distance the textures seemed to have a weird "acne" on them. But, when closing in, it would disappear. I thought it was specular. But, in testing fake AO map using diffuse, I noticed this. I have no clue what's causing it. A lot of these things blend into shadows, so don't notice them.. only reeally notice them in light (which is why I noticed them on windows and such). This one stuck out, b/c it's using the diffuse map as a fake AO grayscale map. Not sure what's causing it. Fallback fresnel used when AmbientRimColor is 0 or not set. Tried to keep it subtle. It's more noticeable when moving around. Have to keep it subtle, b/c too much will make things in light appear ashy, and things in shadows look glowy. Too little, and it's as if it's not even there. Has to be just a little to help add depth to shadows. I figure enhancements are "death of a thousand" cuts... lots of little enhancements add up instead of one big honking one looking gaudy. Fake AO. Most things don't have specular texture maps, so using diffuse map as fake AO means darker things darken up more.. hence the wall and grass are darker. Stone path is darkened in shadows more, too, though. With fresnel highlights and such going, the darkened areas still have depth. This is a WIP. Just farting around, and trying to apply stuff I learned when dinking around with other game shaders, and experimenting to see what happens when I try different things. glprogs.states.interaction.011.zip

I saw a similar problem working on the FUEL: Refueled shaders. It happened when trying to do a half lambert on the light dot. IE sundot*0.5+0.5 This is valve's half lambert technique. It alters the light dot from 0-1 to 0.5-1 to keep shadow side of objects from being pitch black. Sort of acts like pre-adding ambient light. In Fuel, it caused a, stark cut off / seam on objects in mid distance. Not sure why. They did some janky math to try to smooth it out. I simply switched back to using full light dot, and added ambient light value as final addition to light. So, they had this... Sun color * (sundot*0.5+0.5) * shadow + sky color (color of shadows) And i switched it to this... Sun color * sundot * shadow + sky color * sundot * ao + ambient color = light color Got rid of seam, and gave me more control over shadow and ao impact. The sky color by sun dot also prevented normals from flattening out in shadows. Then the final color was... Diffuse * light color + specular * specdot * sun color * shadow * ao Which prevented sundot from killing speculars. With shadow and ao as separate vars, i could max(0.2,shadow) and such to soften shadows and let a bit of specular show up in shadows to simulate ambient light in shadows creating faint shines. Speculars have to be treated as a separate "light" added in doing their own thing. If added to diffuse too early they get severely toned down from other light processing that, shouldnt impact them. Fresnel i've found works best as a final modifier to a final light color. Otherwise it too gets washed out too much in the mix. Ideall with, fresnels youd use R0, but if you dont know or have an R0, you can, just assume R0 of 1.0 for air which cancels out the R0 materials part of the equation leaving you with the pow(1-x, power) part. Then you plug in various modificationa of dots to see what results you get. Fresnel is also good for blending reflective cubemaps to surfaces. Fuel did it with water and clear coats /chrome. But, i added rain sheen to things by just using a set value based on how much it was raining. Anyways, power's out here in texas, so it will be a while before i can explore more. Ideally would like to solve that specular cut off bug before trying to enhance anything else. I looked for some half lambert stuff, but nothing stood out. And its only speculars, which is odd. Theres a lot of shader code to dig into and wrap my head around. Gonna be a while before i can stare at stuff more.

How about some fresnel highlights then? Red-shaded areas show the highlight... Pic below is a velour-style that highlights more as the surface becomes more parallel to the view angle. Here's the effect applied to .rgb Next is an ambient "spotlight / backlight" effect that slightly brightens the area around the player based on surfaces perpendicular to the viewing angle Here it is applied to .rgb It's a subtle effect. It simulates ambient light reflecting off the player back onto surfaces. When combined with velour fresnel, it helps add depth/body to surfaces as you move around them. Some folks may not like the backlight effect. Thief 4 did a similar thing. When you'd crouch to go into stealth mode it lit up a hidden "lantern" light to light up the area around the player to help offset the darkening stealth haze. Some folks hated it and found ways to disable it. So, this might be something to add an option to enable/disable as the user wishes. When combining the effects the ambient lighting has more depth. ~~~~~~~~~~~~~~~~~~ Issue with shadows is they tend to flatten out normals. So, adding in highlights and such helps bring some body back to them. I applied the fresnel effects to the "tdm_interaction.fs.glsl" and "ambientinteraction.fs" files. It helps the most in the ambient lighting, b/c that's where it helps things stand out. Gets too washed out in the tdm_interaction lighting. Might want to disable the fresnel effects from tdm_interaction.fs.glsl, though, b/c not very noticeable in lamp/torchlight, and the ambient fresnel already adds some. (I added them to tdm_interaction to see if they'd boost the highlights in lights. They do, but can over-bright the lights.) ~~~~~~~~~~~~~~~~~~~~~~~~ I messed around with specular in tdm_interaction.fs.glsl to try to make it pop more. I noticed you had a work-around for specular. I re-worked the algorithm to add specular later in the chain, and, while it pops more now, it gets a stark cut-off ... which I'm guessing you noticed and were trying to sort out with work-arounds (?) (gamma room in Training Mission.. floor is shiney & wet now from specular, but shadow is cutting specular off unnaturally) It does it for Blinn and Phong dots either way. Not sure what's going on there or how to fix it. The cut off moves as the camera moves, so it feels like it has somethign to do with view direction. I don't know. I made tdm_interaction specular = 0.1 if there was no specular texture in order to highlight speculars more. Image above has torches to the left and right off-screen.. middle shows a cut-off of specular into the shadows. It's like the light blending is not working for specular. But when the cut-off isn't in the way, the specular looks better now. The wood is unnaturally shiney due to the 0.1 default I put in place. But, the metal rings on the barrels shine and reflect now. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I've attached the two files I messed with, and also a 3rd file I used for #include to chuck glsl cheat-sheet stuff for myself, and a normal map partial derivative equation function to single-source on things I was working on. shaderedits.zip

Where do I upload a revision? Do I just attach a file here?

I just copy-pasted the mega code snippet as an example of what I thought might be redundant code calculations in the code base. As others pointed out, the compiler seems to be smart enough to optimize that stuff away at compile time. And, even if there's redundant calculations, chances are they're not making that big of a difference. And, as you pointed out, Carmack, et.al., coded this stuff up to begin with, so chances are it's probably already good. I'm a nub when it comes to C++ programming, so I don't have the experience to know how the compiler optimizes, etc. But, I stared at some shaders. A lot of them just have complex stuff going on that has to get done, and no way around it. (EG shadows, SSAO, etc). But, things like Tonemap.fs.. it's taking a color sample, and running each RGB component through a color mapping function separately as individual floats. I plugged the code into shader playground (where I just mess with small shader code for quick testing) and turned it into a vec3 function to do it in one-shot, and it seemed to cut the instruction set use in half. I have no idea if that shader's used, though. And, as another said, the big issue with shaders is texture pulls and memory management these days. So, meh.