Jump to content
The Dark Mod Forums

totallytubular

Member
  • Content Count

    55
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by totallytubular

  1. This cured my constipation. Only bug (very minor) was... My only concern with the map is... Still, A+ work on atmosphere and balance between hiding things, but not so much I felt like an idiot. Like Valve said about Portal, you want to make puzzles easy enough for folks to figure out, but hard enough that they feel smart when they do. When I got lost, I looked at the map to see where I haven't been yet. You used sound and such to provide ample prompting on things. When I'd find a switch I felt smart. Didn't have to come over here to look at spoilers. Really good map. L
  2. Yeah. I've noticed that. AI mobs have more curves around their edges, so rimlighting is more prominent on them. And lighter colored textures created lighter grayscale fake spec maps, which make shinier fake specular. So, her edges are highlighted extra prominent, and her skin looks oily / plasticy. Without individual textures having their own built-in, real spec maps, or the game having some kind of surface-type variable to differentiate surface material type (fabric vs. metal vs. stone, etc), all I have to go on is their diffuse map to make fake speculars. If I could do an if/e
  3. I'm gonna chalk those artifacts I'm seeing up to my crappy intel integrated HD gfx chip then. Specular & Rimlight both have been the "never gonna be happy with it all the time" variables for me, b/c when they look decent on one map, they look awkward or non-existent on another. One issue with Specular is when doing it in Ambient.fs, it doesn't occlude when inside buildings or dungeons or what-not. When outside, with the moon in the sky, it's natural to see a specular shine down a building. But, when inside, the shine coming down a wall looks unnatural. So, I try to tweak the spec
  4. 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
  5. 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 the
  6. 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
  7. 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
  8. 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 di
  9. 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
  10. 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 me
  11. 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 am
  12. 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 wit
  13. 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.
  14. 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 r
  15. 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 "int
  16. I'm not getting it, so don't know what it is. Is it this?
  17. 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 anyt
  18. 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
  19. 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
  20. I apologize, HMart. I didn't mean to sound like a d**k. I was just giving reasons on things.
  21. 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 re
  22. 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
  23. 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 th
  24. 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 wind
  25. 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
×
×
  • Create New...