totallytubular

v 0.52 move few more light calc's to vertex-side brought "fake spec map" back, but using it to modify spec dot before adding spec dot to light dot (b/c both mul by diffuse texture then ) ~~~~~~~~~~~~~~ The u_cubic branch light attenuation calculations in ambient.fs & common.fs are pure math until they run into texture pulls that have to get done fragment-side. So, moved their calc's over to vertex-side, passing result from vs to fs as var_CubicAttenuation. Non-cubic light falloff & projection are texture pulls that have to occur fragment-side, so they stay where they are. Also moved the specular map check (IE: if params.specularColor.rgb is not pure black) over to vertex-side after testing to see if it's set by the time it hits vertex shader. It is, so can perform the test there, and create a basic var to pass to fs shaders instead of having to do the test over and over for each pixel. Minor changes. Just offloads processing of these from per-pixel to per-vertex. ~~~~~~~~~~~~~~~ Played a mission or two using spec dot added to light dot w/o fake spec map, and it was annoying. Without some kind of "noise" to modify the specular shine on surfaces, the shine is constant and looks awkward on some things. So, brought back the fake spec map if the texture doesn't have a real spec map. But, this time just multiplying the spec dot float by a single channel of the fake spec map (since fake spec map is grayscale anyways), and then adding spec dot to light dot before mul'ing that by diffuse texture. Sort of splitting the difference, basically. ~~~~~~~~~~~~~~ I'm getting weird artifacts on certain textures, still. I thought it was something I did. So, I loaded all the original TDM 2.09 shaders back in, and double-checked.. still getting them... (pic below has the interaction.common.fs non-cubic branch "totalColor" x10 to make it easier to see.) The things clear-up as I move towards things... I piped variables through, and it seems to be the normal map... pic below has RawN piped straight through.... Again, the artifacts clear up when I move closer to stuff... It only impacts some textures. Not sure what's up. Again, this is using the 2.09 original shaders. Feels like a mip-map thing? Like the mip-map levels aren't interpolating well? Maybe it's a driver issue on my end (I'm running TDM on an Intel integrated HD 4600, and Intel doesn't exactly crank out updated drivers for their integrated chips very often). I don't know. glprogs.stages.interaction.052.zip

v 0.51 ditched fake spec map, and just added float spec dot into float light dot if no real spec.rgb map non-cubic light attenuation is tracked as a float now, b/c the projection & falloff textures are tracking grayscale. So, modified code to just pull single channel as float and generate attenuation. ditched Fake AO.. kept fiddling with it. never happy with it. already have SSAO. moving on. grouped more code into functions (doing so to try to make modifying manylights easier) included all past modules (pbr, pom) in case TDM is angry about them not being there. I'm testing this stuff using stencil shadows + interaction/ambient shaders. So, shadow maps / many lights may be wonky. If you have errors, give me the "file number : line number" from the console. I'll see if I can spot-check and fix. I'm trying to consolidate code chunks into sub-routines to hopefully make it easier to kit-bash manylights into doing what common & ambient are doing. Haven't gotten around to it, though. Mostly just cleaning up the code workspace after I chucked experiments all over the place. glprogs.stages.interaction.051.zip

If you still have the PBR module in your "glprogs/stages/interaction" folder, then it might be trying to use functions in "interactions.funcs" that got changed. Try deleting or moving the PBR module file. All the shaders in that .zip file should be the only ones in your interaction folder when running game. While messing around, I had errors pop up saying the POM files were bad, but I disconnected both POM and PBR from the other code, effectively neutralizing those module files. But, TDM seems to want to try to compile every file it sees in the folder, even ones that don't seem connected anymore. Try moving all of your interaction folder shader files to another temp folder, then just unzipping the .zip from the last version into your interaction folder, that way only those files exist. See if it runs/compiles.

v 0.49 ambient.fs uses rimlighting like common.fs to resolve spazzing water for now while still taking var_Color into account In ambient.fs, the rimlight.rgb has been disabled, and the float rimlight enabled. The float rimlight adds to both light and specular dots. For ambient, the float rimlight just uses the fresnel term and a multiplier to adjust how much to do. Currently the multiplier is at 1.0, b/c I'm trying to experiment with something that will dynamically adjust the amount of rimlight to do based on ambient light level. Reason being.. rimlight looks gaudy when over-done in very bright shadows, and can fade into nothing in very dark shadows. So, the idea was to use the luminance of the ambient lighting to some how scale the rimlighting amount.. tone it down in bright ambient and punch it up a bit in low ambient. The method I'm using doesn't seem to work well (got same results as just mul'ing by 1.0). So, just have the static multiplier there for now. Still not sure why rimlight.rgb was spazzing out on water. Since that part runs outside the cubic/non-cubic branch, I wonder if it's something to do with that... b/c the float rimlight only runs inside the non-cubic branch. Anyways.. feels hackish. But, rimlight does look better when it takes var_Color into account. It blends into the scene better. glprogs.stages.interaction.049.zip

v 0.48 (direction - position) calc's moved to vertex shader if not already there valve-style half-lambert used to even out ambient lighting in shadows zip file contains all files in "interaction", b/c at this point I'm worried only handing out some files might break things if I missing some dependancy or modification to another file I made. Messing around, and finally got cubic attenuation removed from the non-cubic equation, and cubic windows (that use non-cubic lighting branch) still seem to look good. Problem is, water surfaces started borking up with disco lighting (red,green,blue flashes)... which was occuring due to ambient rimlighting, and, more specifically, due to the var_Color being used in the base lighting for rim lighting. I have no clue why it's doing that. But, I decided to remove var_Color from ambient rimlighting. This means the water doesn't spaz out, but grass will show cobblestone rim-lighting highlights once again. ~~~~~~~~~~~~ Merging cubic attenuation with non-cubic was what caused over-darking of ambient lighting. With it removed, levels have brighter light. But, the NdotL was creating stark darkness on the sides of things, like buildings and boxes. The u_minLevel had a half-lambert-style formula to smooth that out, but u_minLevel doesn't seem to be set (on the levels I messed with). The ambient lighting of original shaders start with a 0.5 "directionless half", then add on a specular and NdotL light dot thing to them, so they were forcing a half-lambert style by default anyways. So, decided to make a branch where if u_minLevel isn't set, it'll default to a valve-style half-lambert light dot... sqrt( lightdot * 0.5 + 0.5 ) This evens out the lighting on things, but brightens up lighting, too. So, I compensate by reducing the diffuse.rgb (light color) down by 0.5, too. Half-lambert flattens normals a bit, b/c it reduces the 0 to 1 light dot range to 0.5 to 1. But, the rimlighting and specular in shadows help add body back to the normals in ambient lighting. ~~~~~~~~~~~~~ I shifted the direction calculations to the vertex shader. Those things can be done vertex-side to avoid calc's in fragment shader. They just need to be normalized in the fragment shader. I did this when experimenting with a lighter version of parallax mapping from openGL tutorials.. but it still looked awful, so gave up on that again. ~~~~~~~~~~~~~ I experimented with shifting the TBN mul'ing to vertex by mul'ing it with light, view & world direction.. but it just never quite looked right. It came close, but didn't look exactly like doing TBN muls to normals in frag shader. So, gave up on that. (I even stripped the code out trying to chase down the spazzing water, but I can post that code if anyone's interested.) glprogs.stages.interaction.048.zip

Well, I farted around, and it's the var_Color variable used in ambient rimlighting. For some reason it works fine for everything, but this water spazzes out. I created a base lighting of ... max( diffuse param rgb, mininal ambient light rgb ) * light attenuation (w/o cubic attenuation) * var_Color This gets applied to specular & diffuse texture after they mul by their respective dots. And then that base lighting gets piped out to the rim lighting... and everything is fine except for this water. When I remove var_Color from the base lighting I send to rim lighting, then the water doesn't spaz out.. but then I get this... where the rim-lighting acts like it's highlight cobblestone on grass (red-highlighting is the rim-lighting, which I amped up on red to make it stand out.) If I include var_Color in the rimlighting, then the grass evens out and doesn't show the cobblestone pattern.. but the water spazzes out. I was kind of happy to finally get something where I didn't have to include cubic light attenuation in with the non-cubic path, then I ran into this snag.

Farted with min light level.. once again.. b/c playing Poets and Peasants, noticed the shadows were still pitch black. I mucked around, and think I've got a lighting that will both do a min amount, and no longer needs the cubic attenuation. With cubic attenuaiton removed, most levels go back to their default lighting instead of pitch black. And, the cubic windows still look fine in Training Mission (knock on wood.) But, now I'm dealing with another issue... the water in Training Mission is spazzing out... It flashes red, green, blue like a disco ball.. like the normal map is messing around or something. Does anyone know which shader controls water? I may have messed with it when looking at non-interaction shaders, and borked something up.

v 0.44 tweaked minimum ambient light color removed diffuse texture from specular misc tweaks This doesn't include vertex files (removed modifications to them, so no point in including them), nor PBR/POM files (disconnected code from them). It does include the manylights fragment and funcs. I messed with minimum ambient light color again after trying to play Crystal Grave and it being almost pitch-black in shadows. The original shaders start with an ambient light dot at 0.5, then add things to it. So, in a sense, they're using 0.5 as the base ambient light amount. I messed around with the "AOcolor" variable to do that, but wasn't happy. The u_minLevel variable didn't seem to get set to force a minimum light value. (Level-dependant? Some level authors maybe want pitch-black shadows?) End result was I added a minimum light value to both ambient light dot & cubic attenuation (which is multiplied into non-cubic attenuation, b/c cubic path isn't processing). This helped boost the min light level. Had to boost cubic attenuation, b/c if not, it darkens everything down. I created a #define MIN_AMBIENT_LIGHT variable to tweak. I tuned it based on Training Mission. ~~~~~~~~~~~~~~~~~ Removed diffuse texture from speculars, b/c they were over-coloring the speculars. EG: some doors in torch light would look hyper-yellow, like they were amplifying the light color. The columns in training mission had a dull shine along the reliefs instead of that nice, crisp shine. The diffuse param rgb & var_Color and such are needed for specular, b/c that's light color. (Lightcolor.rgb is light attenuation, and diffuse.rgb is actually light color.. it's confusing). Without any of that, specular is pure white and looks awkward. But, with diffuse texture mixed into it, it darkens and colors too much, looking odd again. Anyways, I kept the old code where matDiffuse texture worked into specular, and it's commented out now. But, the new code doesn't do that. With diffuse texture out of specular, specular brightened up quite a bit, so tweaked it down. The goal was the have a faint, broad shine in ambient light. Didn't want it sticking out like a sore thumb. I also adjusted the ambient specular to show up on floors again, but very faintly. Rim lighting still uses diffuse texture as a base color to keep it from looking like white haze in shadows. Played through Crystal Grave, and the rimlighting and min ambient light made shadows dark but not "keep your lantern all the time" dark. glprogs.stages.interaction.044.zip

v 0.43 started work on "manylights" shaders Ended up on the performance tweaks TDM wiki page, and it talked about setting "r_shadowMapSinglePass" from 0 (which uses ambient/common) to 2 (which uses manylights if you also have shadow maps enabled instead of stencil shadows). What it does is do all the shadow & lighting in a single pass. (Basically passes in a light array and iterates through it, branching on direct vs. ambient light). It can help with performance if folks have shadow maps turned on (I was getting a few extra FPS with it on). So, I started farting with the manylights shaders to sync them up to look like the ambient/common ones if someone is using r_shadowMapSinglePass 2. Also to see if there's a performance hit from the changes I make. All I've done so far is just shuffle code around w/o really changing manylights outputs. I created a "manylights.funcs.glsl" file to dump bindless routines into, but I also #included the "interaction.funcs.glsl" file in it at the top, so it will import and use shared stuff from that. I chucked more shared code into "interaction.funcs,glsl", like calcNorms() and stuff, which both interaction & manylights shaders share. I just organized code around a bit for the time being, so manylights still pretty much does what it's doing. I bound keys to r_shadowMapSinglePass 0 and r_shadowMapSinglePass 2, so I could easily flip back-n-forth between the two for comparisons. Took some screenshots on Training Mission to compare-contrast. These are animated gifs showing "original" (manylights) vs. "modified" (tweaked ambient/common shaders I farted with)... These are ones I consider "good" (subjective, eye-of-the-beholder, but I like them).. blacksmith ... https://i.imgur.com/P8Jv5Ba.gifv archery yard 1 ... https://i.imgur.com/vYJftj4.gifv archery yard 2 ... https://i.imgur.com/KtwgGrq.gifv Now some "bad" comparison shots... gamma room ... https://i.imgur.com/JTv0sIQ.gifv central hall ... https://i.imgur.com/Eh7ofhf.gifv The problem I'm having is getting the final additive ambient light color to look right in both outdoor and indoor areas. Also, the ambient rimlighting amount in my needs to dynamically adjust or something. In really dark areas, you hardly notice the rimlighting, since it's enhancing the final color. If final color is very dark, it won't bump it up much. Then in areas with more light and lighter textures, the ambient rimlight is super bright. In outdoor areas, it blends in, b/c the full moon is out. But, inside... woof. The gamma room is lit up unnaturally. So, I'll have to figure something out. The main difference in my shaders is just applying more fallback specular and rimlighting to everything. Also, all the light colors are multiplied by the diffuse color, hence the colors are a bit deeper (an effect that can be done by just playing with brightness / contrast.. but I was trying to stick with shader tuts that made it seem like all light colors need to mul by diffuse color.) I don't like how muted the rimlight on the column in the main hall looks, though... I like the brighter one from original shaders. I may experiment with going back to using a toned-down diffuse color for specular instead of full diffuse color to let more white-bright show up. One thing I noticed in manylights (and I think ambient.fs was doing it, too).. there's a specular applied to the light dot which essentially does a rimlight effect by applying highlight to the top parts of bricks on walls and things.. before the ambient part even gets to the rimlight part at the end of it's shader. So, I'm going to dig through and see if I can tweak the tweaked shaders to do more of what the originals were doing. I sort of tore things apart to understand them, and piecing things back together. I just have to experiment with more things to figure out what they're doing. Not sure this is worth working on, b/c if 2.10 comes out, I'll just be back to square one starting over on the shaders again trying to figure out what's still used, what's changed, and what's deprecated, since changes aren't merged in to source. glprogs.stages.interaction.043.zip

I appreciate the sentiment, but I broke the code then put it back the way it was. Not exactly praise-worthy work. I'm breaking it to see what it does, then see if doing it other ways adds value at all. Most of the time it doesn't. Sometimes it's hard to tell if anything has changed, or if an error was created, b/c there's a lot of moving parts. Like, I never would have known normalizing the TBN's in vertex shaders caused the black box issue, b/c I wasn't using 64-bit + bloom. But, with that pointed out, I could test and figure out what the issue was via elimination of changes I made.

v 0.40 fixed black-box issue (which I created) After a lot of farting around.. figured out the issue.. In the common and ambient vertex (vs.glsl) files, I normalized the tangent, bitangent (binormal), and normals before dumping them to the TBN matrix for export to pixel shader. TBN tutorials talk about normalizing the TBN's before piping to pixel shader, and didn't seem like that was happening or being done in unconventional way in vertex shaders. So, I added it to experiment. Since I don't use bloom, and use 32-bit or 16-bit, never saw the black-box issue. I got rid of the normalization on the ambient vertex shader, and the black boxes disappeared. So, I just got rid of normalization of TBN in common vertex shader, too, basically putting it back to original code. The TBN's coming into vertex shaders could be getting pre-normalized in the game engine. I don't know. I included the POM module with this, but the FAKE_POM flag is commented out to keep that from being used. Specular is set to run Blinn speculars. Had some experimental code processing, so commented it out to avoid running it if GLSL compiler's not smart enough to skip dead-end code that isn't used for final output. glprogs.stages.interaction.040.zip

I've attached my latest .zip that is a hot-mess of POM code experimentation. There's a separate module called "interaction.pom.glsl" with the main POM code I'm farting around with. There's another called "interaction.pom2.glsl" that just has some pasted in from another source that I looked at but haven't farted with. In ambient.fs & common.fs, the POM code gets called when the normals are being made (calcNormals() and what-not), because the POM code is trying to first modify the normal texture's uv texture coordinates before using it to pull final sample. the "interaction.funcs.glsl" has a #define FAKE_POM flag in it to easily turn POM off & on to experiment I'm applying POM to the normal uv texture coordinates per the learn OpenGL tut here... https://learnopengl.com/Advanced-Lighting/Parallax-Mapping .. and code pulled from here... https://learnopengl.com/code_viewer_gh.php?code=src/5.advanced_lighting/5.3.parallax_occlusion_mapping/5.3.parallax_mapping.fs It shoves the normal's uv texcoords through an obstacle course with a depth map & depth scale to determine new texcoords. I'm using the normal textures to dot-saturate to create a faux depth map via grayscale, which seems to give "best" results (subjective)... depth = saturate(dot(normal,vec3(0.33)) I experimented using diffuse texture, and by adding a cut-off to keep the darks and pump lighter grays up to 1.0 to convert the grayscale to more of a black-n-white... cutoff = 0.2 (arbitrary value to muck with depending on how dark of black-n-white to get) depth = depth > cutoff ? 1.0 : depth; .. but got uglier results. So, stuck with grayscale normals. Here's an animated gif that shows comparisons, b/c hard to tell what's going on unless you see them overlapping... https://i.imgur.com/rsGrtof.gifv The openGL tut code as-is gives wonky results, and I'm not so sure it's b/c of the faux depth map. If I keep the pixel-culling part, then most things in ambient & common become pitch-black. So, it's creating values that many things don't like. But, the pixel-culling part seems paramount, so neutralizing it just to see something is probably causing a lot of wonkiness. The skewing creates these curved designs (as seen in the "divide by .z" part of gif). Some folks in the comments of that openGL POM blog post said to not divide by .z. So, I altered that part of the code, and it got "better" results, but still not good. It looks like the "depth" is skewed upwards, like a stack of cards spread out, instead of outwards like it should. The depth of 0.01 basically makes it blend into the normal map's depth, so pretty much pointless. Using higher depth values just creates that awful skewing. Using lower depth values, might as well not use the POM at all, b/c unnoticeable. I found a PDF ... http://www.d3dcoder.net/Data/Resources/ParallaxOcclusion.pdf with another POM shader, and it has all textures dividing by the POM-modified texcoords (diffuse, specular & normals), not just normals. I experimented with that, but it was just using the modified normals texcoords applied to diffuse & specular, which I'm sure is incorrect (since TDM is creating unique uv's for all three textures in the vertex shader to pipe into the pixel shader.. I'm guessing each one would need to go through the POM modifier to possibly work right.. but that's like 3x the overhead then.) I think I'm missing some prep in the vertex-side of things. Maybe something in the POM code does something I'm not catching in the vertex which I'm not implementing in the TDM vertex code to prep for the pixel-side of POM. Even though using faux depth maps, I'd think some things would look ok. But, it's all still very flat and not "sticking out" like it should. This is why I don't do this stuff for a living. It gets beyond me pretty fast unless it works "off the shelf". glprogs.stages.interaction.039.zip

I'm not getting it, so don't know what it is. Is it this?

I didn't mean to give you PTSD from that one response, HMart. You're spot-on in your reply, though. I have no clue how to access the depth buffer, or what c file to modify to expose it or where and such. So, I gave up. In working on the FUEL shaders, it was a blackbox scenario. I had access to the shaders, but not the game engine code. So, I spent years learning shaders and getting creative with what was piped in, but my knowledge was capped by not being able to mess with the game code to implement more robust things. So, I mess with shaders, but get hesitant to jump into anything that involves digging into game code to expose or add things. I'll look into the places you pointed out to see if I can find something when I get a chance. I'm currently giving parallax occlusion mapping another shot, b/c it seems like all the pieces are there but it's just not looking decent. Gonna try to use another code source; might be easier for me to understand.

Can you post a pic as example, so I know what to look for? I think there was issue with bloom. Nbohr1more said he solved it and rimlighting issue on his end by force-adding the non-u_cubic light attenuation to things. The way I worked around the issue was to multiply both non-cubic and cubic light attenuations together, b/c cubic lighting branch wasn't processing (u_cubic was always 0, so always skipping that branch.. at least in maps I tested, which was mostly Bikerdude's Training Mission.) This let cubic lights get their attenuation, and not create awkward rectangles around windows. But, the hack could be borking up some non-cubic lighting w/o me realizing. I'm running on a potato over here (intel integrated hd 4600 graphics), so I keep bloom and other features off. Something I changed in ambient/common could be borking extra features up w/o me realizing.

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

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

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

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.

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.

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.

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

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

v 0.26 BRDF works now Switched to using regular #defines for it. Had to mess with it a lot. urdo3D code makes it seem like you just... (diffuse + specular ) * lightcolor ... the BRDF result, and you're on your way. But, doing that, I was getting ugly results. Normals were flat. Specular was non-existent. The diffuse terms BRDF uses don't take light dot into account (except for the burley function that uses it more for a tweak). After fiddling around, decided to just let diffuse & specular come out of the BRDF function, and finish going through the lighting gauntlet. So, BRDF-modified specular gets impacted by a spec dot, BRDF-modified diffuse gets impacted by a light dot.. both get light color merged into them.. etc. It was the only way I could get decent-looking results. Feels like I'm doing something wrong doing that, though. Using inverted grayscale specular to generate fake roughness was nullifying speculars, so I switched over to using dot(diffuse) for roughness. It gets better results in that the specular shows up now.. but it's a bit shiny in places. The BRDF is not giving "omg, wow!" results... mostly b/c using normals & diffuse to generate fake maps simply reinforces the those textures. (EG: if you keep using diffuse for every fake map, eventually speculars look super wet.. b/c all you're doing is just reinforcing that texture pattern over and over). Anyways... here's the Builder sneak area in Training Mission using the non-PBR shader branch... And here's PBR shader branch... The burley diffusion term punches up diffuse coloring. The diffuse map generating a faux roughness map helps it impact speculars... the grating on the floor in lower-right has specular shine more in tune with the grating color. There's shine on the wall in the distance from the torch now.. but that can be accomplished by just ramping up specular. But, the specular terms that PBR uses decides to boost and dim specular in various spots, so the scene ends up with shines in areas that didn't have them before. (Not sure if that's a good or bad thing... EG: I noticed a lot of specular seems to hang around lower wall now with PBR on. Not sure why.) Here's the melee / archery outdoor area... no PBR... Notice the clock tower windows... Now notice them when PBR's on... PBR makes the shine on the clock tower look more natural, but it negated the shine on the windows. Not sure if it's the diffuse pbr term or one of the specular terms that's doing it. ~~~~~~~~~~~~~~ The problem with the BRDF / PBR stuff is there's several terms of each type to experiment with, and they can give different results. EG: using the Lambertian diffuse terms, you get dark results. Using the Burley diffuse term, you get results more in sync with the non-PBR colors. So, the catch-22 is that you can end up having to code up a bunch of "if using this term, use this crutch to make up for XYZ that it does" (eg: some specular terms cause LOTS of shine.. others dull things down). I experimented with combinations, and came up with a "preset" that seems to do ok. That was only after I switched to using diffuse as roughness. When I had inverted specular as roughness, I was pulling my hair out for an hour trying to figure out why specular wasn't showing up at all. This was an interesting experiment, but not sure fake PBR / BRDF really adds enough value to be worth it. It's a huge PITA to have to tweak everything. glprogs.stages.interaction.026.zip

Holy s*** ... that is like umpteen times better than what I was doing! I'd modify shader code, start game, load Training Mission (since seeing the same level over and over makes it easy to spot differences), check results, close game... wash-rinse-repeat. It would take a minute or so for Training Mission to load, so it was painful double-checking things, especially when having to chase down something I screwed up. Without a debug log, I'd have to scrub the code for mistakes. I got pretty good at that after working on the FUEL shaders, b/c they didn't have a debug output either. But, sometimes things get so borked up you just can't tell what's hosed w/o a debug log. Like with PBR.. I was pulling my hair out on that. I figured out the issue with it before reading this, though. (wish I would have waited). Basically did massive "#ifdef SKIPCODE" to bypass large chunks of code until I could narrow down the issue. There was an undeclared var in one of the PBR sub-routines due to a typo I made. smh So, got PBR working, and it looks ugly. It's making things really dark. So, now I'm testing / tweaking it. (Mainly tweaking the output of it.. once diffuse & specular are modified by BRDF, have to figure out how to work lightcolor in and combine it all to look decent.) I'll hopefully upload something later today. Can't believe I went a whole week assuming the PBR code was working when it wasn't. I kept playing levels and looking and going "man, is there a difference? I don't know. Is it placebo effect? I don't know." smh Rookie mistake.