Jump to content
The Dark Mod Forums

Recommended Posts

Pretty nice!

I'm not sure what issue you are encountering, but here on Nvidia everything appears to be correct projection-wise.

 

The specular response is still very strong but I think I know what might be happening ( other than differences in taste )...

I believe that JC Denton's old HDR-Lite shaders had a non-linear specular response so that small grayscale variation

produced dramatic increases. There also was a small amount of forced specular everywhere to modulate the fresnel.

For this reason, most of the assets were gutted of specular ( and they were already anemic of specular compared to Doom 3).

( I think JC Denton had a similar motivation; showing that proper light shader design can render specular that looks realistic compared to default Doom 3. So he needed to boost specular contribution everywhere to make this model work and the only way he found to do so tastefully was "non-linear amplification".)

 

I have this uncomfortable feeling that to normalize TDM assets to match up to newer specular designs or even PBR we would need to do an offline modulation of all specular maps to add the HDR-Lite offset to them and then correct whatever got too far out of specification. I just don't know how tenable it will be to continue using our current non-linear response. Obviously this is a last resort \ worst case scenario for correcting things.

 

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to post
Share on other sites
  • Replies 158
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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

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 rou

v 0.71 fake spec diffuse light enhancement boosted a bit to be more noticeable added the direct light rimlight boost back in Fake Spec Boost Fake Specs enhance diffuse light

Posted Images

On 3/23/2021 at 10:32 PM, nbohr1more said:

Pretty nice!

I'm not sure what issue you are encountering, but here on Nvidia everything appears to be correct projection-wise.

 

The specular response is still very strong but I think I know what might be happening ( other than differences in taste )...

I believe that JC Denton's old HDR-Lite shaders had a non-linear specular response so that small grayscale variation

produced dramatic increases. There also was a small amount of forced specular everywhere to modulate the fresnel.

For this reason, most of the assets were gutted of specular ( and they were already anemic of specular compared to Doom 3).

( I think JC Denton had a similar motivation; showing that proper light shader design can render specular that looks realistic compared to default Doom 3. So he needed to boost specular contribution everywhere to make this model work and the only way he found to do so tastefully was "non-linear amplification".)

 

I have this uncomfortable feeling that to normalize TDM assets to match up to newer specular designs or even PBR we would need to do an offline modulation of all specular maps to add the HDR-Lite offset to them and then correct whatever got too far out of specification. I just don't know how tenable it will be to continue using our current non-linear response. Obviously this is a last resort \ worst case scenario for correcting things.

 

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 specular to not be so gaudy.

The problem with tweaking specular is that folks like you and me are hyper-focusing on it while modifying things. So, we have a heightened awareness of it as we look around levels, and tweak it as such.

But, regular players that aren't hyper-focused on it may not notice it at all if we tweak it too low. That's one reason why I err'ed on the side of "a bit more specular is better than not enough". No sense in processing the effect if it's hardly noticeable by anyone.

 

But, you say it's very strong... can you post a screen shot of what you're seeing? Maybe your getting a different output than I am on your gfx hardware? I mean, if my gfx is giving me weird artifacts while yours isn't, maybe the specular looks different when processed by both, too?

 

Ambient rimlight is also a pain... when I switched over to using the common.fs style of rimlight to avoid the disco lighting of water (still not sure why it's doing it), the rimlight acts as a whole-level brightening. So, I have to tone it down. But then some levels are super-dark (eg: The Ravine), and the rimlight is non-existent. So, I have to kit-bash in a hack to brighten up rimlight when textures/ambient lighting is super-dark. Then there's levels like Marsh of Rahena that don't seem to use Ambient light for the darkness...d'oh.

I also had to apply the 1-NdotL hack to rimlight to keep it from over-brighting ground same way specular was doing.

Then there's personal preference... some folks may want more specular / rimlight .. some may want less .. so it's just never going to be one-size-fits-all.

 

And, the real solution would just be to go through all the textures and create real spec maps and such that are missing. I wonder if there's an offline batch process algorithm that can do that? They have data sci algorithms that can batch-process upscaled image resolutions. (Folks that play original Doom did that to the graphics to take the original low-res graphics and artificially high-res them into a texture pack, that way the graphics card wouldn't have to waste processing doing it on-the-fly).

Even if there was a batch processor to create spec maps, or convert non-PBR stuff into PBR by creating albedo, roughness, etc maps.. it would still take sifting through the results to make sure it all looks decent. An algorithm might be fine for a majority of things, but may not make some stuff look decent.

This guy's using a software program, but I wonder if there's like a python lib to code up a batch process...

 

That's beyond the scope right now, though. LOL

 

I've attached a new version of my modifications with a few more tweaks...

 

v 0.55

  • ambient rimlight takes darker shadows lighting/color textures into account and brightens up a bit to keep from fading into nothing on super-dark maps (only on maps that actually use Ambient light, like The Ravine... not on maps that ignore Ambient light.. like Marsh of Rahena)
  • like ambient specular, ambient rimlight also dims on ground (1-NdotL) to keep ground from being super-bright and awkward. But, added in a max() to cap the negation, so it doesn't get rid of it all.

 

I started experimenting with ManyLights, but no drastic changes in this version.

First experiment was finding out that we can create varying arrays to pass arrays of values between vertex & fragment shaders. So, I thought it'd be smart to pre-calc things for each light in the vertex shader like I did in interaction shaders.. so, "for each light in lights, pre-calc TexLight, Attenuations, etc" and pass arrays of that to fragment shader.

Got it going, and it killed performance. LOL!

(IE: I was getting like 12 FPS in the archery yard on Training Mission, and suddenly I was getting 2 FPS.. LOL)

Memory is the constraint. Too much stuff demanding too much gfx memory to pipe over. So, nixed that idea.

I run stencil shadows instead of shadowmaps, b/c of my podunk gfx chip, so lost interest in messing with manylights.

glprogs.stages.interaction.055.zip

Link to post
Share on other sites
Quote

But, you say it's very strong... can you post a screen shot of what you're seeing? Maybe your getting a different output than I am on your gfx hardware? I mean, if my gfx is giving me weird artifacts while yours isn't, maybe the specular looks different when processed by both, too?

AI are the biggest issue. See this example from "Inn Business"

 

innbiz_2021-03-26_23_59_50.thumb.jpg.ce3c26702d59dcc2b5f9c76e57d75a61.jpg

Also burlap packages have a little too much sheen.

I think that our current lighting is a little too dry, so the calibration would be only a very very small amount of specular on the burlap and making sure the AI have some specular but aren't plastic figures.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to post
Share on other sites
8 hours ago, nbohr1more said:

AI are the biggest issue. See this example from "Inn Business"

 

innbiz_2021-03-26_23_59_50.thumb.jpg.ce3c26702d59dcc2b5f9c76e57d75a61.jpg

Also burlap packages have a little too much sheen.

I think that our current lighting is a little too dry, so the calibration would be only a very very small amount of specular on the burlap and making sure the AI have some specular but aren't plastic figures.

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/else on material type, we could dig up some materials algorithms to apply to things to make fabrics look duller/rougher, metals more metallic/shiny, bricks/stone more "bricky/stoney", etc. I don't think that flag is tracked in the game, though. (I don't know.)

So, doing best I can with what I have an know how to do. If I mess with multipliers to make her look good, other things, like walls and such, end up losing so much specular or rimlight that the effects are barely noticeable, if at all. Then tweak things to make them look good, other things stick out. Catch-22.

~~~~~~~~~~~

For things that don't have real spec maps, I thought about just going back to mul'ing fake spec map by diffuse texture rgb again to just give them a color saturation boost.

But, I stumbled across a Quake Wars: Enemy Territory wiki that talked about using inverse diffuse texture as specular color to create a more "neutral" (matte/diffused/monochromatic) specular color.

https://wiki.splashdamage.com/index.php/Basic_Texture_Overview

I tried it with ambient and direct lighting.. and it makes ambient specular look better (not as prominent, more blended into shadows/scene). For direct light.. not so good IMO. So, I only applied it to ambient light...

  • grayscale diffuse texture = fake spec map
  • inverse diffuse texture = fake spec color

In doing that, I go back to using the specdot * specular.rgb for fake spec light finalization again.

Then I experimented with making rimlight an .rgb again, but only inside the non-cubic branch. I mul the rimlight dot by specular.rgb for color... and it helps diffuse/tone down/blend the rimlight a bit more.

And, oddly enough.. when I just keep that rimlight in the non-cubic branch.. my water on Training Mission doesn't disco color on me. So, I'm not sure why the water disco lights when rimlighting is done outside the branching.

Everything seems to use non-cubic branch, so .. just gonna keep rimlighting inside there for now.

I've attached v 0.56 shader .zip

v 0.56

  • inverse diffuse texture used as fake ambient specular & rimlight color

I'm testing it out as I play Blackgrove Manor.

 

glprogs.stages.interaction.056.zip

  • Like 1
Link to post
Share on other sites
  • 3 weeks later...

Hey there! I've been using your shaders rather extensively for a bit now after whetting my appetite using the very excellent fresnel mod and eventually desiring a more pronounced effect. These shaders certainly provided that and I have to say that I find them basically a necessity now. Really great work here. I enjoy being able to make out finer details in the dark, like the texture of a surface, but still have that sense of being in extreme darkness that simple gamma/brightness adjustments completely obliterate. For me, with some tweaking of the settings, this totally achieves the look that I personally love.

Compared to most games these days, TDM FMs are rather heavy handed on the darkness (for obvious reasons) and tend to have completely pitch dark areas. That may look great for mood/atmosphere but being completely blind really hurts immersion and gameplay for me. Darkness is rarely ever pitch black, especially outdoors. Eyes adapt and the moon/stars can provide a shocking amount of light. I live in a pretty rural area and most clear nights I can make out individual blades of grass in the complete absence of any artificial lighting. I really love that look in darkness which is rarely present in games, probably because it is ludicrously difficult to achieve, especially without losing the sense of darkness completely.

So, yeah, thank you so much for this! It runs great on my hardware (core i9/RTX2080 super) with no noticeable loss of fps. Even managed to play through The Painter's Wife it. I also can't say that I experienced any artifacts or black squares on some textures or anything of the sort. Absolutely great experience! 😁

Link to post
Share on other sites
  • 2 weeks later...

v 0.57

  • fixed issue (I caused) on TDM's original ambient rimlight.rgb
  • stopped mul'ing ambient rimlight by inverse diffuse / specular map mix

Been a while, but finally had a chance to circle back to the shaders.

For ambient light, I have the fake spec map multiply by inverse diffuse color to help dull the shine. I also applied this fake spec / diffuse mix to rimlight to dull them, too. But, while playing some missions, I noticed it made the rimlight look like a monotone, uniform oily or smudgy color covering textures, covering up the underlying texture color.

So, I removed the inverse diffuse / spec map mix from ambient rimlight. But, I kept it for ambient specular, because the dulled specular does blend nicer with shadows.

I also farted around, and found out the clamp I used on the original rimlight rgb (that gets added at the end of the ambient light shader) was causing the water to disco light. For some reason the var_Color and clamp did not play well together. So, I commented that out.

I added that clamp to keep dark textures from neutralizing rimlight / fresnel too much.

So, I created a replacement rimlight rgb function. I chucked in the code from the light dot rimlight that uses the diffuse color luminance and light color luminance to enhance rimlight amount as either / both get darker. I tested it on The Ravine, and it did enhance dark areas a bit. Then I tested the water on Training Mission to make sure it wasn't spazzing out.. and it seems to be fine. There might be a more elegant way to do this, but this is what I came up with.

glprogs.stages.interaction.057.zip

  • Like 1
  • Thanks 1
Link to post
Share on other sites
6 hours ago, ate0ate said:

Might I ask if you personally adjust the color curve bias or color correction bias and, if so, what you recommend their values to be?

Do you mean through my graphics control panel or through an ENB-type program (like ENB or ReShade)?

I don't change anything in my graphics panel, nor use any ENB-type program when running TDM.

I want to keep everything on my end as neutral as possible to see what TDM looks like as-intended. That way I can try to enhance something ("try" being the operable word :) ) without getting too ham-fisted about it. If I had ENB shaders and what-not running to drastically change colors, then I could be modifying the lighting shaders to benefit what *I* see, but when others use it it could look awful.

If you're instead wondering why my shaders seem to be a bit more "colorful" (colors are a bit more saturated / enhanced.. like torch lights)...

That's b/c specular is faked & added to more things.

If a surface doesn't have a built-in specular map texture, I fake it by making a grayscale out of the diffuse rgb color texture. But, I apply it differently in ambient (shadow) vs. direct (torch, lantern, etc) lighting passes:

  • Ambient ... fake spec gets multiplied by 1 - color texture (inverted color) to make it a dull shine before adding it to final ambient light mix.
  • Direct ... fake spec shine added to surfaces was making them too shiny (like everything had car clear-coat on it reflecting light .. EG: bricks were having a bright shine come off them). So, as an alternative, I multiply the spec dot (specular intensity) by the fake spec map, then add that to the light dot (light intensity) which gets multiplied by the color texture. This turns the fake specular into a color enhancer.

Also, the original shaders were taking the real specular values (EG: for metal surfaces), and multiplying it by ...

  • (diffuse * 0.25 + vec3(0.75))

This would add in a bit of the color texture, but not too much.

My shaders don't do that.. but I'm probably going to add it back in, b/c on some metal surfaces (eg: metal banding on some doors) the light shine is very colorful (eg: the reflection looks glowy yellow, and sort of sticks out like a sore thumb).

Shaders are art and science.. can apply the math, but need to tweak based on what looks goods.

The other thing is the rimlighting is applied to more things in ambient lighting. There's a parameter set for rimlighting, but, while testing, I didn't see it set, so it wasn't getting done. It could be that this is a feature that will be used in the future, so they built-it out in the shaders now. But, I decided to create a fallback method to do rimlighting if that parameter isn't set.

The rimlighting uses the parameter color value if it's passed in, otherwise it uses the (once again) color texture value to enhance the lighting. This might enhance the color of surfaces in shadows a bit. But, the main goal is to make things in shadows have a bit more body / depth to keep them from flattening out too much, and also help the player see a bit better in very dark areas. (The rimlighting acts as a very faint "echo vision" highlighting objects in the dark.)

TDM does a gamma correction toward the end of the lighting passes, and does an HDR (high-dynamic range) in the post-processing passes for frames. You can adjust gamma & brightness, but not HDR or color saturation inside the game. The HDR just boosts the range of colors, but keeps them inside a range that's displayable. It's just working with the colors already there.

Not sure I answered your question.

Link to post
Share on other sites

v 0.58

  • added normal map intensity to sharpen normals for a bit more faux depth
  • both ambient & direct light use fake spec as a diffuse color enhancement now instead of a shine overlay
  • shuffled diffuse & specular color params around to keep metal speculars from being yellow-glowy

 

Param Shuffle

This is something I screwed up a while back that I just noticed & fixed.

Original shaders had param.specularColor applied to specular, and param.diffuseColor applied to diffuse.

For some reason, when I first started shuffling things around to figure out what was doing what, I got param.diffuseColor mixed into the light attenuation & var_Color sub-proc I made. This put the base diffuse light adjustment value onto everything light color applied to (diffuse, specular, rimlight for ambient).

So, metal bands on doors were glowing unnaturally yellow.. the columns in the hub of Training Mission glowed an unnatural orange. This was because the specular was mixing in both specular param & diffuse param, over-saturating the base lighting amount.

So, I segregated those back to their respective elements.

I also made the diffuse param have a minimum light value.. this is where the final ambient light color amount is "added in" to keep things from being pitch-black. So, if diffuse param is missing (IE: pitch-black) it will revert to a default constant MIN_AMBIENT_LIGHT value. (The light color function was already doing this, but I kept it with the diffuse param after splitting it out where it needed to go).

Now surfaces with real specular maps don't glow an unnatural color compared to surrounding lighting. (EG: the metal bands on the door to the right in the image below. The lighting is more natural now, as it should be).

5SudDP5.png

 

 

Normal Map Intensity

Stumbled across this site...

https://github.com/mebusy/notes/blob/master/dev_notes/unityShaderEffectCookbook.md

.. that talks about multiplying normal map .xy by a value to boost intensity. This enhances the faux depth of the normal map.

dTjzoKA.gif

So, I added it to the normal map algorithm after the .xy generate the .z value. I set a constant in the interaction.funcs file called NORMAL_INTENSITY which I defaulted to 2.0. It's a minor boost w/o looking too gaudy. B/c larger boosts (eg: 5 in the gif above) make the normals look like old-school games when normals first came out.. where they were trying to over-emphasize them to show folks how cool they were... "look at these chonky normal maps, folks! so cool!"

 

Fake Spec 2:  Electric Boogaloo

Got tired of screwing with the shine of fake specs in ambient light, so just made them into a diffuse color enhancer like they are in direct/common light shader.

I still use diffuse texture for the fake spec map, but I use it after the diffuse light color param has been applied to the diffuse texture. I do this, b/c the diffuse texture acts as a replacement for the specular map, and the diffuse light color param acts as a replacement for the specular light color param. But, it gets grayscaled, so ultimately it's just nuances.

The grayscale fake map gets multiplied by the specular dot (specular intensity), and that's added to the diffuse light dot (diffuse intensity) to boost its intensity.

By doing this, surfaces with real specular maps stand-out a bit more now. EG: metal beams along a brick wall.. the metal beams have a real spec map, so shine, while the brick has a fake spec map, so has a very faded shine / boost.

 

 

glprogs.stages.interaction.058.zip

Link to post
Share on other sites

I'm not sure why, since you seem to have clamped negative values but...

The last two versions have the rectangle artifact when bloom is enabled again.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to post
Share on other sites
30 minutes ago, nbohr1more said:

I'm not sure why, since you seem to have clamped negative values but...

The last two versions have the rectangle artifact when bloom is enabled again.

Ok, dug through forum. Pg 5 shows the discussion on it.

The black squares were caused by me adding normalization to the TBN values in the common / ambient vertex shaders before they went into the TBN matrix to pass to pixel/frag shaders.

Ever since we found that out, I rid of that normalization in the vertex shaders, and left a comment in the shaders not to do it b/c of that issue.

I just tested 64-bit + bloom, and I'm not getting black squares on my end. I'm using an Intel integrated HD 4600.

I included all my "interaction" folder shaders in the .zip. Did you dump all of them into your interaction folder, or just the ambient/common frag shaders?

I'm guessing it's a PITA to update anything on your end when I keep chucking out a bunch of micro-updates, so maybe you kept some older versions of files around?

Check your ambient/common vertex shaders for TBN normalization and comment it out.

If that doesn't work.. post your shaders here, and I'll look at them when I have time. Maybe there's a gfx-card-specific issue going on.. something that is fine on my end, but not yours ... that we can pin-point.

Link to post
Share on other sites
38 minutes ago, nbohr1more said:

I'm not sure why, since you seem to have clamped negative values but...

The last two versions have the rectangle artifact when bloom is enabled again.

Also, can you point out a specific map & location you're seeing the squares?

Last time I saw them practically every where (eg: on Training Mission, in the stealth area, the light over the desk in the hall, the light in the warehouse by the metal wall...).

Maybe you're seeing them in some specific place I'm not looking.

Link to post
Share on other sites
40 minutes ago, nbohr1more said:

I'm not sure why, since you seem to have clamped negative values but...

The last two versions have the rectangle artifact when bloom is enabled again.

One thing you can try...disable the NORMAL_INTENSITY

It's applied to normal maps before they multiply by TBN matrix in pixel/frag shader.

  • go into the "interaction.funcs.glsl"
  • go to textureNormalCompressed function
  • comment out the "normalSample.xy    *= NORMAL_INTENSITY;" line
  • (or set NORMAL_INTENSITY to 1.0)

Maybe the change to RawN.xy before it muls by TBN is causing an issue?

Link to post
Share on other sites

I am also seeing the squares now as well. They don't seem to be as common as before. Best mission I find to test for them is simply Mission 2: The Tears of St. Lucia. Turn right at the start and you cannot miss them.

squares.jpg.59ef9a837c802bea4ddbe7ed8e96010d.jpg

As a note to your prior response: I really appreciate the detailed answer. It is helpful to someone who is mostly unfamiliar with shaders and how they function. My original question was just referring to your darkmod.cfg settings for the mentioned variables. I don't use reshade myself and almost never touch my graphics panel either but I have used ENB for things in the past, mostly Skyrim.

EDIT: Commenting out the line you mentioned above did not have an effect on the black square artifacts. I'm fairly unfamiliar with much of this but I thought it would be worth a try:)

Edited by ate0ate
Link to post
Share on other sites

I went through the Training Mission and I did not notice any squares in the areas you mentioned above. I did notice them in some odd spots that seem mostly like they would be unrelated to bloom, like the ends and edges of various models as opposed to around lights or windows. I don't know if this information will be helpful in any way, but I figured I'd point it out just in case since it seemed kinda odd. There are a couple spots of note in the jumping/mantling section around the central construction scaffolding you are meant to practice on. I'll spoiler the images to save space...

Wheelbarrow

Spoiler

lTVfZqD.jpg

One is this wheelbarrow off to the side. Looks fine from this angle and is barely even lit, but when viewed from behind things change...

CnEH5FV.jpg

Board

Spoiler

LuumV2v.jpg

This board nearby in the center of the construction area seems fine and the edge of it's end seems to just barely stay in the light. Moving just a hair to the right causes a square to become visible for no discernable reason...

02rPBNT.jpg

Definitely not places where bloom would even be a factor in my opinion. Oh well, hope these are at least helpful in some capacity:)

Link to post
Share on other sites
21 hours ago, ate0ate said:

I went through the Training Mission and I did not notice any squares in the areas you mentioned above. I did notice them in some odd spots that seem mostly like they would be unrelated to bloom, like the ends and edges of various models as opposed to around lights or windows. I don't know if this information will be helpful in any way, but I figured I'd point it out just in case since it seemed kinda odd. There are a couple spots of note in the jumping/mantling section around the central construction scaffolding you are meant to practice on. I'll spoiler the images to save space...

Wheelbarrow

  Hide contents

lTVfZqD.jpg

One is this wheelbarrow off to the side. Looks fine from this angle and is barely even lit, but when viewed from behind things change...

CnEH5FV.jpg

Board

  Reveal hidden contents

LuumV2v.jpg

This board nearby in the center of the construction area seems fine and the edge of it's end seems to just barely stay in the light. Moving just a hair to the right causes a square to become visible for no discernable reason...

02rPBNT.jpg

Definitely not places where bloom would even be a factor in my opinion. Oh well, hope these are at least helpful in some capacity:)

I'll need time to dig into this, but it gives me a place to start.

I've run all around Training Mission, and haven't noticed anything. But, I have my grx options set to minimal due to running on an intel integrated gfx chip.

What in-game gfx options do you have switched on? IE: SSAO, Bloom, etc? If you can give me a run-down, then I can go in and switch each on to see if the squares show up for me.

Also, have you tweaked a graphics control panel for TDM? IE: Nvidia & AMD control panels often let you select a specific program to adjust adaptive vsync, better anti-aliasing for transparent textures, etc. Do you have anything like that setup? I'm curious if a control panel could be overriding the game and doing something extra.

  • Like 1
Link to post
Share on other sites

I just did a fresh install of 2.09 using the default generated config. All I did was turn on the bloom and the squares in the training mission that I pointed out earlier are still there. Thought that might make some things a bit easier.

To answer some of your questions though I do not modify anything externally at all. No reshade or Nvidia control panel settings or anything else like that. I do usually have everything cranked up to max like AA and Anisitropy at 16x, Very high LODs, very high soft shadows, shadowmaps on instead of stencil, SSAO on high usually with the darkmod.cfg adjusting it's radius to 128. The only thing I don't usually have turned on is the sharpen.

I seem to get the same results using the settings mentioned above as well as just default settings with bloom on. I also got bored and tested things on the 2.10 dev build and while the shaders worked perfectly well the squares were still present when the bloom was enabled. I am using Windows 10 with an Nvidia 2080super with a fresh driver update that released today I believe.

Link to post
Share on other sites

v 0.62

  • cleaned up code a bit before screwing around some more
  • fake spec maps no longer multiply by diffuse light color, b/c they're a light dot enhancement, not an actual spec light ... so, torches and direct light should no longer seem super-bright / color-saturated
  • created NdotL curves in ambient lighting to tone down rimlight & specular on floors & undersides of things a bit more elegantly, so there's no glowing specular floors or rimlight showing up on the underside of canvase bundles... then spent hours tweaking specular & rimlight to look decent with it (PITA). The rimlight culling should help SSAO blend the bottom-side of things into shadow better.
  • figured out better ambient rimlight booster for dark levels, so rimlighting looks half-way decent whether playing Training Mission or The Ravine

 

glprogs.stages.interaction.062.zip

  • Thanks 1
Link to post
Share on other sites

Well, whatever you did you fixed it! That new update there works perfectly it seems. I'll test a bit and turn up my settings again but so far it looks good.

Link to post
Share on other sites
2 minutes ago, ate0ate said:

Well, whatever you did you fixed it! That new update there works perfectly it seems. I'll test a bit and turn up my settings again but so far it looks good.

Good that it's working. Bad that we're not sure what changed to fix it. I try to document what changes can bork up things, so I know not to do things that way going forward. Without knowing how this bug got fixed, I could inadvertently introduce it again later.

I'll mess around a bit more to see if I see anything.

Link to post
Share on other sites

Yeah, a good point. Things are still working great after cranking up the settings on 2.09. Even works in the 2.10 dev build, for now at least.

Since you cannot seem to recreate it on your end if you have anything you want me to test to see if the squares come back just let me know. I'll happily help you track down whatever the culprit was if I can. It was definitely somehow tied to the in-game bloom setting as turning it off would always "fix" the issue and turning bloom on promptly brought the squares back.

Link to post
Share on other sites

v 0.64 ... more ambient specular changes

  • ambient now has double specular ... spec 1 shining from sky to floor (the one we've had), and now spec 2 is shining up from the floor to the ceiling. I did this to help add continuity to surfaces with specular in ambient lighting.
  • ambient ceiling / floor specs use Phong (that uses reflection), b/c it makes a nice spotlight shine while walls and such use Blinn-Phong (which uses half direction) b/c it's nicer
  • ambient real spec maps create too much shine on floors (spotlight under foot or overhead). Been struggling with a way to kill them some, which I tried doing the NdotL curve with... but, silly me, I already have a flag to differentiate between real & fake spec maps. So, I just used that to tweak the multiplier down on real spec maps for floors / ceilings. (Not sure why I didn't think of that sooner. d'oh)
  • ambient lighting now treats all spec maps like real specular lights instead of using fake spec maps to enhance diffuse color lighting.

This is experimental.

I've been bothered by the ambient specular, where it shines down walls w/o any indication of it being on the ceiling. It's just cut-off at the seam between wall and ceiling.

Reason being.. the main ambient light source (in most levels, the moon) isn't treated like a direct/common light, so it's not blocked by shadows.

I'm guessing the reason this is the case is because to create a level-wide direct light overhead which is impacted by shadow maps would be a major processing bottleneck for the game engine. Reading TDM's level design optimization guides, they already recommend limiting the number of dynamic shadow-casting lights in areas. So, having to track a massive one overhead as moonlight blocked by shadows in order to know when the player was indoors vs outdoors, or when overhangs on buildings blocked moonlight... that'd be nuts.

So, for pretty much all levels, there's a light direction coming straight down without any way of knowing if anything is blocking it (which is what shadow maps do), and the light color is controlled by a diffuse light color the level designer tweaks based on indoor vs outdoor lighting levels.

So, outside, you see specular shine coming down walls. But, when you go into rooms/halls, the shine still comes down from ceilings, b/c the ambient light is not impacted by shadows and know way of knowing when indoors vs outdoors other than the change in diffuse light color... which I used to create a luminance value to try to tone down specular in places when that light goes darker.

But, w/o an occlusion factor to know when the light direction coming down has been blocked by something (an overhang, player indoors, etc), all I can do is kit-bash the ambient specular together to try to compensate.

Second Breakfast

To try to blend ambient specular better, I created a second ambient one using a hard-coded light direction coming up from the ground.

"what?!"

Yeah, sounds weird.

But, what it does is create specular on the bottoms of walls.. and on ceilings now.

So, the two speculars do the following

  • spec 1... floor shines, top-of-wall shines (this was what we had already)
  • spec 2... ceiling shines, bottom-of-wall shines (new)

Wonder Twin Powers Activate... When the two are combined, they create complementary speculars on walls and ceiling seams to create a more cohesive continuity in shine. (IE: spec 2's wall shine merges with spec 1's floor shine, and vice-versa, so when you look at seams between floors and ceilings, you see a shine that transitions between the two a bit now).

The idea here is that ambient light is bouncing all around, even from the ground up.. and even off the player onto other surfaces. So, we simulate that with a bit more specular around the player going onto more surfaces.

Blinn Problem

The problem is Blinn-Phong half-direction speculars (which look nice) brighten up the entire floor/ceiling for some reason... they create nice shiny trails up walls, but surfaces directly facing the light source.. they light up the whole surface.. they don't just make a spotlight shine or what-not.

So, I used light dot to flip between nice Blinn-Phong trails on walls and just Phong spotlights on floors / ceilings.

So, each specular is processing both a blinn-phong and phong spec then deciding which to use.. so, that's 4 speculars processing to combine into a single spec dot value that them merges with the spec map to create the specular light.

This is some kit-bashed garbage on my part, but it seems to do the trick until a more elegant solution comes around.

Oh.. I also got rid of the light dot curves... they seemed to work, but were culling the rimlight & speculars so much that all they did was highlight brick / tile edges. I liked it at first, but after experimenting it just seemed odd.

 

glprogs.stages.interaction.064.zip

  • Like 1
Link to post
Share on other sites

v 0.65

  • added two #define's in "interactions.funcs.glsl" to adjust overall ambient light level (one to switch override on, and one to set override amount)

While messing with the speculars today, I tried to use ambient diffuse luminance to cull and blend things more. Then I decided to apply it to overall ambient light.. and it darkened shadows a lot. But, it was really cool for the level I was testing it on (Alberic's Curse).. so, decided to add the option to let player darken shadows as they wish.

Interactions.funcs.glsl has two more #defines now...

  • AMBIENT_LIGHT_DARKER  ... set to 1 to turn-on, any other value skips it (but, can just use 0 for off)
  • AMBIENT_LIGHT_AMOUNT ... set to 0.0 or higher for however much ambient light you want to show through (it works as a percent, so 0.0 = 0%, 0.5 = 50%, 1.0 = 100%, etc)

When switched on, this adjusts the diffuse + specular ambient light, not the rimlight. The rimlight is still added on last as a final lighting to help player see in the dark.

  • AMBIENT_LIGHT_AMOUNT 0.0 (0%) = pitch-black shadows save for rimlighting.
  • AMBIENT_LIGHT_AMOUNT 1.0 (100%) is like having AMBIENT_LIGHT_DARKER override switched off
  • AMBIENT_LIGHT_AMOUNT > 1.0 (eg: 1.1 or 110%) brightens shadows, making it harder to sneak

The catch-22 of this is that you're overriding the level designer's original artistic vision; they set certain lighting levels in their level. But, some users may want darker shadows. So, to each their own.

Here we see it in action on Alberic's Curse...

UkXrMM0.gif

Might be hard to see, but the faint rimlighting on the stone window frames stays fairly constant. Also, as the ambient light dims, the rimlighting becomes more apparent on the tiled ground. Since ambient light is added into direct lights (EG: torches), the torch in the distance dims a bit, too. But, it still shines brightly.

glprogs.stages.interaction.065.zip

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...