Jump to content
The Dark Mod Forums

Recommended Posts

  • Replies 130
  • 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

Oh absolutely. And just to be clear, my interest in PBR isn't really in giving TDM a stylistic overhaul, "next-level graphics" or any such nonsense I'm more interested in if it could make our artists

Posted Images

Got a pm from a user asking me how to install the shaders. I took it for granted folks staring at this part of the forums would know the source code break down and where to stuff them. So, here's some instructs for folks that don't know what to do with the files...

For Dark Mod v2.09, do the following...

1) go to your dark mod game folder (where you installed TDM, and where the .exe executables are)

2) make the following folders / folder path (this is important, b/c it changed for 2.09)

  • glprogs\stages\interaction\

3) if you have those folders, and there's stuff in the "interaction" folder, then either zip up the original files there as a backup archive, or make a sub-folder like "\original" or something to put the following files...

  • interaction.ambient.fs
  • interaction.ambient.vs
  • interaction.common.fs
  • interaction.common.vs

If you don't have those folders or those files, then no big deal. It just means you don't have them (which means the game has been using whatever's in the pk3 resource files that come with it's install).

4) after making that folder structure and/or backing up your original 4 files, unzip the files from the zip in this thread into that "interaction" folder

5) start the game

The game should override pk3 resources with whatever loose files it finds in same folder structure and file name. So, firing up the game with those glprogs sitting out in that folder structure, it'll use those instead of what it has in the pk3's.

You should be good to go.

If you notice the torches don't emit light (pitch black) or the shadows are pitch black, it means something's borked up in the shader files and they're not compiling. (When the game notices a borked up shader file, instead of just crashing like a lot of DX HLSL stuff does, it skips it instead. Since those shaders handle lighting, pitch-black means they're being skipped and not doing the lighting.)

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

Hmm, those artifacts may be due to bindless texture driver issues. Does r_useBindlessTextures 0 fix them?

I will test this tonight.

I don't think it's bindless textures.

I modified the diffuse texture pull functions to make anything in bindless one bright color, and anything not using bindless another bright color... Basically...

  • vec4 diff = (pull texture);
  • diff.r *= 10.;
  • return diff;

That sort of thing. Nothing seemed to use bindless textures. i went and commented out the normalization I added to the TBN matrix in the vertex shaders to see if maybe that was doing something, but nope.

The more I play, the more I notice it. I'm running through The Heart of Saint Mattis right now (jesus christ, great level!), and noticed very detailed textures look "spazzy", then I zoom in and notice it's because the texture has very distinct cut-offs between squares. EG: in the cemetary, the dirt plots over the graves. They're detailed grass or dirt. But, zooming in with spyglass I see stark lines where some pixels of texture seem to be missing or something.

Again, I don't know if it's something I did. Maybe using diffuse as fake AO is causing this. Not sure.

Another thing I'm noticing is that some textures don't have normals.. or, rather.. probably using the normal from the TBN matrix piped in from vertex shader. I notice it via the fresnel. Look down a wall at an angle, and it's like a sheet of glass with smooth fresnel even though it's brick. There's a sub-routine that does either normals * TBN, or just pulls normal from TBN to return as normal. I'm gonna experiment with that branch. If the normal from the vertex is being used, we might be able to branch and skip some of the processing that the full-bodied normal might use. I don't know. Gonna stare at them more later. Wife just came down with strep throat or something, so kind of busy being nurse maid.

Link to post
Share on other sites

I played around with this a little last night.

The ambient improves the appearance of some assets but makes the AI too shiny.

Full disclosure: my interest in this is because your original screens resembled the original TDM 1.03 ambient by JC Denton.

I am hoping that this work can lead to a "legacy mode" where missions like "Inn Business" that rely heavily on

the original Ambient Fresnel can look more like they were intended to.

For forward development, the TDM team is speculating about a PDR pipe-line similar to what RBDoom3BFG is currently working on:

https://github.com/RobertBeckebans/RBDOOM-3-BFG/commit/7f3208adb41d91c41879e2ed3f8eecd2a510ef93

Doom 3 Vanilla:

ZEI4i87.png

 

Doom 3 with PBR materials mixed in:

FC82oOM.png

 

We already sorta have part of this up and working via the ambientCubicLight and our parallax corrected cubemaps can approximate the reflections:

But we really need to create a "proof of concept" branch with a proper PBR pipeline to determine how feasible it will be.

All this said, if nothing comes of this but slightly improved shaders compared to the current TDM design then we can still offer them

in the legacy part of the light pipeline and also put it up on Moddb where 2.09 (etc) players can enjoy them prior to whenever we

"possibly" move to a PBR model.

  • Like 3

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

Moving to PBR will require making roughness maps for all materials. All the base color textures will have to be reauthored too, as they need to use correct intensity range. Since non-pbr TDM stock assets use specular maps in like 1% of the cases, changing from non-pbr to pbr will in essence change the art style of TDM.

Edited by peter_spy
  • Like 1
Link to post
Share on other sites

Robert Beckebans reconciled this in Doom 3 BFG by assigning a default PBR behavior to all non-pbr materials so that the difference

in lighting would not be so jarring. It seems to have worked pretty well. I am not sure whether he also toned down the pbr response of

pbr materials to sorta "meet in the middle".

 

I think we would be OK but we would need to add a few artificial bias factors:

1) Probe lighting in the ambient would need to be limited in legacy maps to retain the darker look

2) Standard lighting in legacy maps would also need to multiply the falloff against the PBR method to limit the light radius closer to light sources

3) Probe based specular \ metal behaviors in legacy maps would be reduced and multiplied with a standard specular constant

 

That is, of course if we go for a hybrid model. We could just offer PBR as a new mapping mode and let mission authors choose to create assets

and missions in that new mode.

 

Whatever happens it needs to be studied for feasibility but Robert's approach shows that it can look great and mixing

asset types doesn't have to be catastrophic.

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
55 minutes ago, VanishedOne said:

Is AmbientRimColor here related to the ambientRimColor material keyword? I'm not aware of that having been used yet except in experiments.

 

Thanks for that! I guess I lost the plot thinking this was related to r_newFrob or for other special features. I'll tinker with Inn Business and see if this feature

is good enough to revive the look!

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
18 minutes ago, nbohr1more said:

Whatever happens it needs to be studied for feasibility but Robert's approach shows that it can look great and mixing

asset types doesn't have to be catastrophic.

A potentially significant difference, though, is that Doom 3 assets all have a coherent source and style. That makes it potentially easier to apply some kind of hacks to make them look decent when combined with PBR. This might be a lot harder to do for TDM, where assets come from various authors with different creation process and style.

Ultimately, though, all of this is pure speculation. We won't know anything until we actually experiment with it in a controlled fashion. Then, and only then, will we see what may or may not be possible and how best to move forward. But either way, before such experiments can happen, there is some ground work to be done, so I feel this is a discussion for another time :)

  • Like 3
Link to post
Share on other sites

Right, I mostly added this to the topic since the author is doing lots of ambitious shader experiments and I wanted to

temper expectations about whether any of them would be included or part of our road-map.

 

Again, even if totallytubular's shaders never get merged they might still be a great add-on pack for players

to experiment with just like my torch glare mod.

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

Don't get me wrong, it would make my model and material workflow like 10x easier :D I already own Substance tools, so with e.g. proper metallic-roughness workflow, I'd export all textures directly from Painter to TDM.

I was just thinking, since TDM doesn't use specular workflow much at all (most surfaces have kind of chalk or powdery properties), switching to PBR makes little sense if you plan to maintain current approach, i.e. mostly no roughness maps. Otherwise, TDM will change style in a way that my custom project differs from current stock TDM assets.

Edited by peter_spy
Link to post
Share on other sites
2 hours ago, cabalistic said:

A potentially significant difference, though, is that Doom 3 assets all have a coherent source and style. That makes it potentially easier to apply some kind of hacks to make them look decent when combined with PBR. This might be a lot harder to do for TDM, where assets come from various authors with different creation process and style.

To add to that, even 'PBR' texture types aren't an assurance that you're actually getting something created with numbers based on physics. On Sketchfab I've seen models with 'metallic' window glass (for reflectivity, I suppose) and even metallic meat. (Well, we do have a quasi-mediaeval setting; maybe we could say it's adulterated...) I think it's just in the nature of the beast that TDM will never have as consistent an art style as projects with dedicated art teams.

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to post
Share on other sites

Oh absolutely. And just to be clear, my interest in PBR isn't really in giving TDM a stylistic overhaul, "next-level graphics" or any such nonsense ;) I'm more interested in if it could make our artists' lives easier, as peter_spy hinted. As an "industry standard" in some sense, it has better tooling and potentially a more consistent look across different scenes, which might need less tinkering. But again, that's all speculative :)

  • Like 3
Link to post
Share on other sites

Replying to various points I see made...

The backup Fresnel would def look better with materials lighting toning it, b/c it's too monochromatic and even-looking. I thought AmbientRimColor was for materials, so when I noticed many things didn't use it I just figured they didn't have materials-based lighting implemented or their textures weren't prepped for it. Hence I chucked in the fallback fresnel. But, since the fallback fresnel is very monotone (monochromatic.. blue/gray haze on everything) and everything looks the same in shadows b/c no variations based on texture or materials I then tried applying the fake AO from dot(diffuse, 0.33) to add in variation to the fresnel (darker parts blocked more). But, lots of stuff just got their fresnel cancelled out when I did that. (EG: there's this dark brick texture on Saint Mattis FM in the underground .. it's so dark it just cancels out the fresenl if I mul it by fake AO). Tried doing a "if AO < 0.5, use 1-AO" to flip it, but it just went back to looking very monotone.

That brick texture was also the one I I thought had no real normal map applied, but when I just piped normals through I saw it did have a normal.. just a very flat-looking normal without much variation. (IE: not as bumpy as, say, a round-rock stone wall texture).

Looking down some walls, it looked like fresnel on a sheet of glass, but that was b/c the normal map on the texture was very flat. EG: wallpaper with the raised pattern..just looking down that wall the fresnel looks flat. But, zoom in with spyglass, and notice the fresnel is hugging the normal, it's just so faint that you don't see it unless zoomed in.

Since missions can be a hodge-podge of assets, the goal was to use the shaders as a "butter knife" smoothing frosting on a cake. If textures can do PBR / materials and other stuff, then they take those branches. If not, then they use fallback methods to try to still add some detail. In a perfect world, every object/texture in the game would have PBR / Materials, specular maps, AO maps, etc. But, it's not perfect. The great part about shaders is we can do hacky fallback stuff if the cool stuff is missing.

My idea is also to try to automatically offload some cool effects onto the shaders, so the FM designers don't have to think about it.

EG: a shader that controls water should always add some default reflection to the surface, or, better yet, do calculations to determine transmission vs. reflection when looking down at the water vs looking parallel to it. And, do some depth calculations to determine where water edge is for edge softening / blending. Maybe also add a default water color value to blend in, so all water isn't crystal clear. That way FM designer just has to slap some water in their level without having to worry about messing with it to make it reflective or realistic-looking.

Or, things like floors where the "tap tap" walking sound occurs, just have the game engine automatically use a shader that applies a slightly reflective cubemap on those textures to make tappy tile floors look polished and slightly reflective.

Just build in some default enhancements that the game engine & shader logic handles, so the FM designer can focus more on making a level instead of trying to mess around with making textures and objects look good.

I am still very much a nub when it comes to shaders. I hit my level of incompetence pretty quick when I start reading some of the white papers nvidia/amd publish on how to implement things in shaders. But, I like messing around with them, and like the idea of the shaders being able to make things look nicer automatically without level designers having to worry about micro-managing details like that.

The shaders I chucked up here are just a WIP of hacks to see if the shaders could help smooth out more enhancement. There's def better / official ways to do things (like PBR). But, also hack alternatives to fallback on that the shaders can do when that's missing.

Link to post
Share on other sites

Having more controls over how water looks might be interesting, but automating tile floor reflections isn't a good idea IMO. As with most materials in non-pbr setup, you have to author specularity and cubemaps per your lighting setup. E.g. cubemap reflections look very pronounced in dark areas and washed out in intensely lit places. There's no one-size-fits-all solution to that.

  • Like 1
Link to post
Share on other sites

On that Doom 3 shots that nbohr1more posted, can someone explain to me how PBR can do such a stark diference in light levels?! Is that really pure material PBR alone or there's some extra fake shader based ambient being done there? Is almost like with PBR on the scene gets radiosity bouces.

About PBR in TDM I know is just a "what if" but imo that would be fantastic.

And btw this is my idea how it could work, sorry if is stupid don't know much about this stuff. OK TDM would have two render paths, one with PBR support and the other vanilla, the PBR one is off by default and not used, unless, mission makers explicitly turn it on, somehow, perhaps by setting something on a config file.

They would be the ones responsible to make sure their missions assets, really support PBR, perhaps using a few converted default materials or making their own.

Why I recommend this, because IMO this way the engine team can, create a pure PBR render and not have to marry/couple the non-PBR and the PBR render together, IMO making the render more complex, more error/bug prone and perhaps making PBR less than what it can be. But this is only a uninformed assumption on my part, perhaps I'm just sub-estimating the abilities of the TDM engine team. 😜 sorry guys. :D 

Edited by HMart
Link to post
Share on other sites
6 minutes ago, peter_spy said:

Having more controls over how water looks might be interesting, but automating tile floor reflections isn't a good idea IMO. As with most materials in non-pbr setup, you have to author specularity and cubemaps per your lighting setup. E.g. cubemap reflections look very pronounced in dark areas and washed out in intensely lit places. There's no one-size-fits-all solution to that.

Yeah, in the FUEL shaders, it was a b**** and a half getting the chrome/clear coat reflections to blend properly in light/shadow. Had to process the final diffuse with lighting / shadow first, then mix/lerp the cubemap in via fresnel that was impacted by shadow to make the lerp use more diffuse in shadows and more clear coat/chrome in light.

I noticed in TDM every now and then there'd be a glass object that's super-bright in ambient shadow light. Thought I'd take a crack at evening that out, but haven't found a shader that controls that yet, though.

I'm not sure what shaders are used / aren't used, or what they impact. So, I've just been dinking around with what I know impacts things so far.

Is there documentation somewhere that says what files control what, and are/aren't used?

Link to post
Share on other sites

Do you know c++? IMO you would gain much by looking at the engine source, to see how the render backend does the shader stuff, even if you have no intention of messing with the c++ code but if there's some docs better. 

Edited by HMart
Link to post
Share on other sites

The "lit" glass is probably a "blend add" or "blend blend" stage in the glass "material".

The material files are mostly in tdm_base01.pk4 under the materials folder with the extension mtr.

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
1 hour ago, HMart said:

On that Doom 3 shots that nbohr1more posted, can someone explain to me how PBR can do such a stark diference in light levels?!

I can only assume the lighting setup was corrected to match textures that were adjusted for PBR. While non-pbr can use full 0-255 intensity range for diffuse (although it shouldn't), PBR base color needs to be between something like RGB 50 and 235.

Link to post
Share on other sites
3 hours ago, HMart said:

On that Doom 3 shots that nbohr1more posted, can someone explain to me how PBR can do such a stark diference in light levels?! Is that really pure material PBR alone or there's some extra fake shader based ambient being done there? Is almost like with PBR on the scene gets radiosity bouces.

RBDoom3BFG is capturing "probes" (cubemaps) of the "area" which are fed to the ambient light shader. A technique as old as HL2 at least.

  • Like 1

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

That technique didn't become widespread until parallax-corrected cubemaps and then Disney's BRDF solution became available. There were custom solutions, like for UE3 there was Remember Me game, but it only around UE4 we're talking about standards. Plus I guess hardware had to catch up as well.

Edited by peter_spy
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...