Jump to content
The Dark Mod Forums

totallytubular

Member
  • Posts

    102
  • Joined

  • Last visited

  • Days Won

    3

totallytubular last won the day on March 16

totallytubular had the most liked content!

Reputation

72 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. v 0.93 LdotH used for BRDF Fresnel, too, if PBR_OPTIMIZE switched on Really minor update. Stumbled across a presentation on "Physically Based Lighting for Black Ops" (SIGGRAPH 2011) that made the distinction between Fresnel for mirror/cubemap that uses NdotV or NdotL, and Fresnel for BRDF microfacet that uses VdotH or LdotH. Since the FilmicWorlds optimization already does LdotH, I just added LdotH Fresnel to the optimization path. So... Optimization off... VdotH gets calc'ed Fresnel uses VdotH Visibility calc's 2 arms, one for NdotV, one for NdotL Optimization on... LdotH gets calc'ed Fresnel uses LdotH Visibility calc's 1 arm with LdotH then squares it The LdotH specular is a bit brighter than the VdotH one. glprogs.stages.interaction.093.zip
  2. I wandered through the Bloom / Volumetric Lights thread, and came across the link to your github https://github.com/duzenko/darkmod-experiments I wanted to check out your Volumetric Light shaders, but don't see a "glprogs" folder anywhere (?) When researching volumetric lights, I came across a a lot of different sites talking about various ways to do them and optimize them. Maybe I can stare-n-compare to see if I can find a way to tweak them?
  3. Do they not realize volumetric lighting would make their job easier? It does all the work in creating god rays w/o having to hand-place them. I wanted to try real volumetric lighting via shadowmaps, but that's beyond me. (IE: not sure how to implement it, and reached my level of incompetence trying to wrap my head around it .. kept finding a lot of Unity examples, and not sure how to translate that into non-Unity). That's why I focused on the easier post-processing version. I can understand the performance issue ... Fallout 4 was Nvidia's big "look at our volumetric lighting using shadow maps!" example, and I remember having awful performance with FO4 with that turned on while using a GTX760. As more TDM graphics get offloaded from CPU / game engine to GPU / shaders, maybe there will be a time when there's a performance surplus folks would then be willing to rethink spending on cadillac features like volumetric lighting. Since I've spent time farting with lighting, just thought I'd try to bolt on a cheap version and see how it goes.
  4. So, new challenge... I'm trying to implement simple post-processing volumetric lighting as per Nvidia's GPU Gems... https://developer.nvidia.com/gpugems/gpugems3/part-ii-light-and-shadows/chapter-13-volumetric-light-scattering-post-process It's a simple plug-n-play algorithm to shove into the post-processing pipeline (the /glprogs/tonemap.fs file). My idea is to create very faint god-rays for moonlighting. We already have hand-placed god-rays for direct-lighting. So, just wanted to have very faint highlighting for overhead moon light as well. Issue I'm running into is the algorithm needs a light direction. I got into tonemap.vs, and tried calculating a var_WorldLightDir (like the way interaction.common.vs does for shadowmaps). I removed the parts in the calcs needing model matrix, b/c I just try to get a basic light direction for scene w/o model impact. So.. like this... // var_WorldLightDir = (params[attr_DrawId].modelMatrix * attr_Position).xyz - u_globalLightOrigin; var_WorldLightDir = attr_Position.xyz - u_globalLightOrigin.xyz; I can't pull in params w/o shader crashing. The u_globalLightOrigin uniform doesn't seem set for the post-processing tonemap shader. So, all the god rays just dump into the lower-left corner regardless of view angle. Is there another global light direction that exists for post-proc? Or, is that something the would require fiddling with the game engine?
  5. v 0.92b shadow map texSize pre-calc'ed one time Filmic Worlds LdotH optimization included in PBR (switch it on/off with #define PBR_OPTIMIZE in funcs file) Stared at the shadow map fs shader a little more, and noticed texSize is calculated in the main() for shadowResolution, then calculated in the shadow Atlas functions again. Made it where main() calc's it one time, and passes it to the Atlas functions. Real minor change, but the atlas functions are called over and over in soft shadow loops. So, just in case compiler doesn't notice a one-n-done value is done over and over, pulled it out of the loops. I also forgot that I implemented the Filmic Worlds LdotH Visibility GGX PBR optimization in 0.92. Basically, instead of having to calculate a GGX "arm" for NdotL and for NdotV, it just has to calc one for LdotH then square it. Helps cut down on calculations. It makes the PBR a bit brighter, but the results look acceptable. glprogs.stages.interaction.092b.zip
  6. Can you post a pic of the posterization you're seeing? I need some place to reference to tell if I'm fixing it or not. See if the shadow map tweak I made fixes it. ~~~~~~~~~~~~~~~~~~ v 0.92 fixed puddles tweaked shadow map (not sure if it fixes anything) Puddles were spazzing from the MIN_AMBIENT_LIGHT amount I try to add to diffuse light color to keep it from being pitch black. Not sure why it spazzes out. I commented out that part of the ambient frag shader until I can think of a way to do that w/o spazzes. I looked at shadow maps. I'm not sure where the posterization issue is, but the cubemap facing function seems to be doing the wrong values in a few spots. I added a new version of the function that emulates what khronos has in the OpenGL pdf for cubemaps. I'm not sure if it fixes anything or not. I dont' notice a difference when I flip between it and the original TDM version. glprogs.stages.interaction.092.zip
  7. v 0.91 posterization fixed (?) The "if ( this is 0 and that's 0, etc, etc)" logic branch on GetBRDF() equations seemed to be creating a gating situation causing posterization. When I commented them out, posterization seemed to clear up. (Tested on the statue on Mission 2: Tears of Lucia). When I get time, I may get rid of other branches to see if other stuff clears up, too. (EG: the banners in Training Mission hub that still have chunky coloring splotches). Maybe I'm being too liberal with logic branches. I could try running fake specs as vec3's like real specs, and see if things clear up. I don't know. glprogs.stages.interaction.091.zip
  8. What map is that? I want to be able to see the same statue (to keep that as a constant) while I fiddle with things to see if any results change.
  9. Yeah, noticing the posterization on a few things. Pics of banners in main hub of Training Mission: I fiddled with things in PBR, and didn't get it to change. Then I turned PBR off, and... ... it still shows up. So, it's something else. Not sure what. Haven't had time to test other things yet. It's the same posterization pattern, though, so I wonder if it's specular still.
  10. v 0.90 tweak to BRDF function to factor out some math & optimize a bit Been looking at this person's site... http://filmicworlds.com/blog/optimizing-ggx-shaders-with-dotlh/ He's done work to optimize the Cook-Torrance BRDF. I Implemented it in FUEL (at least the ones that don't require extra texture pulls), but it was super-shiny. His level 3 optimized BRDF merges Fresnel with Visibility to reduce calculations.. but then it's harder to isolate Fresnel to do the kS/kD ratio without having to have a separate one do extra calcualtions to complete just for that. So, I tabled that for now. Might bolt it onto TDM later to see how it looks. But, one thing I noticed was in GGX Visibility / Geometry functions, folks seem to do... 1.0 / (stuff1) * 1.0 / (stuff2) as opposed to the LearnOpenGL & Urho3D way that has NdotV / (stuff1) * NdotL / (stuff2) Then I realized it's probably because they used NdotV & NdotL to cancel out the ones in the denominator of the C-T equation... 4 * NdotV * NdotL we can isolate them as... ( Fresnel * ( NdotV/1 * 1/(stuff1) * NdotL/1 * 1/(stuff2) ) * Distribution ) / ( 4 * NdotV * NdotL ) ... and that reduces down to... ( Fresnel * ( NdotV * 1/(stuff1) * NdotL * 1/(stuff2) ) * Distribution ) / ( 4 * NdotV * NdotL ) .. which just means the NdotV & NdotL are free to cancel the ones from the denom, leaving us with... ( Fresnel * ( 1/(stuff1) * 1/(stuff2) ) * Distrubution ) / 4 Someone might want to double-check me on that, but it looks valid. Attached shader .zip does that. glprogs.stages.interaction.090.zip
  11. v 0.89 fixed posterization of PBR After some testing, turns out the Distribution term really does need to include PI in it's denominator.. or else it causes this posterization issue. glprogs.stages.interaction.089.zip
  12. Oh yeah. I noticed it on doors... There were large, chunky squares. And other textures. (I posted a picture of a ground texture that had what looked like ugly pixelization.) I disabled parts of the PBR code to see what was doing it, but couldn't figure it out. But, when PBR is disabled as-a-whole, it goes away. So, I'm not sure what's doing it. I thought the clamp I had on the distribution term was creating a gating effect, but I disable that and it's fine. Maybe it's a combination of things. I don't know. I have to look into it more. But, it is annoying. There's a lamp on Mission 1, you jump down where the 2 guards talk... the lamp has like really black pixelly spots on it... I thought maybe the Visiblity / Geometry term was doing something. The next thing with the PBR would be to bolt on various sub-routines for Visibility/Geometry and GGX/Distribution to see if they are better. Maybe they'd fix something. I feel it's odd I had to hack in a clamp to keep Distribution term from over-shining things as it is. Ideally, PBR should just take things in and shove them out without any modification. But, it's doing something... The fake roughness & specular might have something to do with it. That's why I've been trying to get better algorithms to produce them. At this point, I just don't know what's causing it. But, at least I'm not the only one seeing it. So, that means it's not a graphics driver issue or something. (I think).
  13. Well, it's more that I'm trying to avoid another project to work on. I'm the type of person that likes to dig in and help out. I started asking questions here, and before I knew it I was staring at PBR tutorials to bolt PBR on the lighting shaders. LOL! No one asked me to. But, it was just interesting experiment. It was also something I felt I could work on and be productive with, because the job hunt has been very demoralizing. I'd ask questions at the RBDoom3 forums, but, since I already know the PBR code I did, I'd want to just bolt it on and test it out. So, if it was a waste of time, it would be my waste of time instead of theirs. I'm trying to practice some "proactive quitting" to re-focus my time on my job hunt. I've already got the FUEL shaders in the back of my mind again; wanting to revisit them to see if I can bolt PBR on them. It's like things I want to go do, but I need to stop myself, since I have something I need to do right now that I need to focus on.
  14. v 0.87 * switched fake roughness over to use RBDoom3's version (seems to smooth things out better). Thanks for pointing me to his github, Peter_Spy. He's got some interesting things going on there that I'm going to look into further. * for surfaces with real specular rgb textures, I have roughness using an avg of the diffuse rgb & specular rgb grayscales. This adds variation in the pattern. EG: instead of a polished marble floor having a uniform shine, it will have variation based on where the veins are. * for non-PBR, I switched it over to use fake spec as a spec light instead of a diffuse boost. This makes lighting look more uniform when switching between non-PBR and PBR instead of "whoa, why does non-PBR color pop more?" (if color boosting / color saturation is wanted, it could be added as a feature in post-processing or something.) glprogs.stages.interaction.087.zip
  15. Can you post a screenshot of that banding / posterization? I'm running bare-bones 16-bit color, no SSAO, etc, etc. Like with the Bloom issue, others are running other options that may be seeing different results.. which could be borked up w/o me knowing.
×
×
  • Create New...