Jump to content
The Dark Mod Forums

totallytubular

Member
  • Content Count

    31
  • Joined

  • Last visited

  • Days Won

    2

totallytubular last won the day on March 1

totallytubular had the most liked content!

Community Reputation

28 Good

About totallytubular

  • Rank
    Member

Recent Profile Visitors

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

  1. 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 atte
  2. 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 shad
  3. 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 ligh
  4. 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,
  5. (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 hig
  6. 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
  7. 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/LICENS
  8. 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 stil
  9. 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
  10. 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 commo
  11. 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 ex
  12. 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 fin
  13. 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,
  14. 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.
  15. 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
×
×
  • Create New...