Jump to content
The Dark Mod Forums

Messin with shaders


totallytubular

Recommended Posts

5 hours ago, VanishedOne said:

I should think adding shader effects to the spyglass overlay would be done by adding a stage to the tdm_spyglass_overlay material to invoke a postprocess shader. You could look at water materials like textures/water_source/water_clear for an example of a stage calling a shader program.

I'm not totally sure but I think that is just the case of getting the depth information, from the depth buffer, but like I said I'm not a shader guy.

If is the depth buffer and if I'm recalling well, TDM has that exposed to the material system, to solve some of the water shaders bugs, like the old case, where the player was looking in some direction and the weapon happened to be on top off some water, from far away obviously but we could see it reflected on the water as if it was in the water itself.

But I will not fall in the same trap again, perhaps he just doesn't know how to access the depth buffer, neither do I or the code he found, uses some other technique, if he can't he can't and that's fine.

Link to comment
Share on other sites

8 hours ago, Hooded Lantern said:

all the new versions got this wierd flickering black boxes. it seems there is a file missing missiong in those packages. do i have to keep the interaction.pbr.glsl file, just replace the other five?

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. But, the hack could be borking up some non-cubic lighting w/o me realizing.

I'm running on a potato over here (intel integrated hd 4600 graphics), so I keep bloom and other features off. Something I changed in ambient/common could be borking extra features up w/o me realizing.

Link to comment
Share on other sites

5 hours ago, HMart said:

I'm not totally sure but I think that is just the case of getting the depth information, from the depth buffer, but like I said I'm not a shader guy.

If is the depth buffer and if I'm recalling well, TDM has that exposed to the material system, to solve some of the water shaders bugs, like the old case, where the player was looking in some direction and the weapon happened to be on top off some water, from far away obviously but we could see it reflected on the water as if it was in the water itself.

But I will not fall in the same trap again, perhaps he just doesn't know how to access the depth buffer, neither do I or the code he found, uses some other technique, if he can't he can't and that's fine.

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 anything that involves digging into game code to expose or add things.

I'll look into the places you pointed out to see if I can find something when I get a chance.

 

I'm currently giving parallax occlusion mapping another shot, b/c it seems like all the pieces are there but it's just not looking decent. Gonna try to use another code source; might be easier for me to understand.

 

Link to comment
Share on other sites

14 hours ago, totallytubular said:

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. But, the hack could be borking up some non-cubic lighting w/o me realizing.

I'm running on a potato over here (intel integrated hd 4600 graphics), so I keep bloom and other features off. Something I changed in ambient/common could be borking extra features up w/o me realizing.

it is the usual blacksquare error flickering around the lights.

Link to comment
Share on other sites

18 hours ago, totallytubular said:

I didn't mean to give you PTSD from that one response, HMart. :)

hahaha :D  It does look like that doesn't it! Hope not! :P 

I'm currently giving parallax occlusion mapping another shot, b/c it seems like all the pieces are there but it's just not looking decent. Gonna try to use another code source; might be easier for me to understand.

How are you applying the POM? Can you show the material text? And how are you assigning the heightmap data? Using a channel of another texture?

 

 

Edited by HMart
Link to comment
Share on other sites

I didn't see this problem but both your work and my experiments have the same problem:

bloom + 64-bit color + any non-standard shaders = black boxes.

Cured by disabling either bloom or 64-bit color.

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 comment
Share on other sites

4 hours ago, HMart said:

 

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 "interaction.funcs.glsl" has a #define FAKE_POM flag in it to easily turn POM off & on to experiment

I'm applying POM to the normal uv texture coordinates per the learn OpenGL tut here...

https://learnopengl.com/Advanced-Lighting/Parallax-Mapping

.. and code pulled from here...

https://learnopengl.com/code_viewer_gh.php?code=src/5.advanced_lighting/5.3.parallax_occlusion_mapping/5.3.parallax_mapping.fs

It shoves the normal's uv texcoords through an obstacle course with a depth map & depth scale to determine new texcoords.

I'm using the normal textures to dot-saturate to create a faux depth map via grayscale, which seems to give "best" results (subjective)...

  • depth = saturate(dot(normal,vec3(0.33))

I experimented using diffuse texture, and by adding a cut-off to keep the darks and pump lighter grays up to 1.0 to convert the grayscale to more of a black-n-white...

  • cutoff = 0.2 (arbitrary value to muck with depending on how dark of black-n-white to get)
  • depth = depth > cutoff ? 1.0 : depth;

.. but got uglier results. So, stuck with grayscale normals.

Here's an animated gif that shows comparisons, b/c hard to tell what's going on unless you see them overlapping...

https://i.imgur.com/rsGrtof.gifv

 

The openGL tut code as-is gives wonky results, and I'm not so sure it's b/c of the faux depth map.

  • If I keep the pixel-culling part, then most things in ambient & common become pitch-black. So, it's creating values that many things don't like. But, the pixel-culling part seems paramount, so neutralizing it just to see something is probably causing a lot of wonkiness.
  • The skewing creates these curved designs (as seen in the "divide by .z" part of gif). Some folks in the comments of that openGL POM blog post said to not divide by .z. So, I altered that part of the code, and it got "better" results, but still not good.
  • It looks like the "depth" is skewed upwards, like a stack of cards spread out, instead of outwards like it should.
  • The depth of 0.01 basically makes it blend into the normal map's depth, so pretty much pointless. Using higher depth values just creates that awful skewing. Using lower depth values, might as well not use the POM at all, b/c unnoticeable.

 

 

I found a PDF ...

http://www.d3dcoder.net/Data/Resources/ParallaxOcclusion.pdf

with another POM shader, and it has all textures dividing by the POM-modified texcoords (diffuse, specular & normals), not just normals. I experimented with that, but it was just using the modified normals texcoords applied to diffuse & specular, which I'm sure is incorrect (since TDM is creating unique uv's for all three textures in the vertex shader to pipe into the pixel shader.. I'm guessing each one would need to go through the POM modifier to possibly work right.. but that's like 3x the overhead then.)

I think I'm missing some prep in the vertex-side of things. Maybe something in the POM code does something I'm not catching in the vertex which I'm not implementing in the TDM vertex code to prep for the pixel-side of POM.

Even though using faux depth maps, I'd think some things would look ok. But, it's all still very flat and not "sticking out" like it should.

This is why I don't do this stuff for a living. :) It gets beyond me pretty fast unless it works "off the shelf".

glprogs.stages.interaction.039.zip

  • Like 2
Link to comment
Share on other sites

1 hour ago, nbohr1more said:

I didn't see this problem but both your work and my experiments have the same problem:

bloom + 64-bit color + any non-standard shaders = black boxes.

Cured by disabling either bloom or 64-bit color.

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 rid of the normalization on the ambient vertex shader, and the black boxes disappeared. So, I just got rid of normalization of TBN in common vertex shader, too, basically putting it back to original code.

The TBN's coming into vertex shaders could be getting pre-normalized in the game engine. I don't know.

I included the POM module with this, but the FAKE_POM flag is commented out to keep that from being used.

Specular is set to run Blinn speculars.

Had some experimental code processing, so commented it out to avoid running it if GLSL compiler's not smart enough to skip dead-end code that isn't used for final output.

glprogs.stages.interaction.040.zip

  • Like 3
Link to comment
Share on other sites

13 minutes ago, Hooded Lantern said:

you doin master builders work totallytubular. 

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.

Link to comment
Share on other sites

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 with the manylights shaders to sync them up to look like the ambient/common ones if someone is using r_shadowMapSinglePass 2. Also to see if there's a performance hit from the changes I make.

All I've done so far is just shuffle code around w/o really changing manylights outputs.

  • I created a "manylights.funcs.glsl" file to dump bindless routines into, but I also #included the "interaction.funcs.glsl" file in it at the top, so it will import and use shared stuff from that.
  • I chucked more shared code into "interaction.funcs,glsl", like calcNorms() and stuff, which both interaction & manylights shaders share.

I just organized code around a bit for the time being, so manylights still pretty much does what it's doing.

I bound keys to r_shadowMapSinglePass 0 and r_shadowMapSinglePass 2, so I could easily flip back-n-forth between the two for comparisons.

Took some screenshots on Training Mission to compare-contrast. These are animated gifs showing "original" (manylights) vs. "modified" (tweaked ambient/common shaders I farted with)...

These are ones I consider "good" (subjective, eye-of-the-beholder, but I like them)..

Now some "bad" comparison shots...

The problem I'm having is getting the final additive ambient light color to look right in both outdoor and indoor areas. Also, the ambient rimlighting amount in my needs to dynamically adjust or something. In really dark areas, you hardly notice the rimlighting, since it's enhancing the final color. If final color is very dark, it won't bump it up much. Then in areas with more light and lighter textures, the ambient rimlight is super bright. In outdoor areas, it blends in, b/c the full moon is out. But, inside... woof. The gamma room is lit up unnaturally. So, I'll have to figure something out.

The main difference in my shaders is just applying more fallback specular and rimlighting to everything. Also, all the light colors are multiplied by the diffuse color, hence the colors are a bit deeper (an effect that can be done by just playing with brightness / contrast.. but I was trying to stick with shader tuts that made it seem like all light colors need to mul by diffuse color.)

I don't like how muted the rimlight on the column in the main hall looks, though... I like the brighter one from original shaders. I may experiment with going back to using a toned-down diffuse color for specular instead of full diffuse color to let more white-bright show up.

One thing I noticed in manylights (and I think ambient.fs was doing it, too).. there's a specular applied to the light dot which essentially does a rimlight effect by applying highlight to the top parts of bricks on walls and things.. before the ambient part even gets to the rimlight part at the end of it's shader. So, I'm going to dig through and see if I can tweak the tweaked shaders to do more of what the originals were doing. I sort of tore things apart to understand them, and piecing things back together. I just have to experiment with more things to figure out what they're doing.

Not sure this is worth working on, b/c if 2.10 comes out, I'll just be back to square one starting over on the shaders again trying to figure out what's still used, what's changed, and what's deprecated, since changes aren't merged in to source.

glprogs.stages.interaction.043.zip

  • Like 1
Link to comment
Share on other sites

Keep in mind the manylight shaders are almost as experimental a feature as it gets. They will almost certainly change for 2.10 or even get ditched entirely, and they have certain issues right now.

So yeah, they have a "high risk" with being revamped for 2.10. Then again, 2.10 isn't going to be released any time soon.

Link to comment
Share on other sites

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 amount.

I messed around with the "AOcolor" variable to do that, but wasn't happy. The u_minLevel variable didn't seem to get set to force a minimum light value. (Level-dependant? Some level authors maybe want pitch-black shadows?)

End result was I added a minimum light value to both ambient light dot & cubic attenuation (which is multiplied into non-cubic attenuation, b/c cubic path isn't processing). This helped boost the min light level. Had to boost cubic attenuation, b/c if not, it darkens everything down.

I created a #define MIN_AMBIENT_LIGHT variable to tweak. I tuned it based on Training Mission.

~~~~~~~~~~~~~~~~~

Removed diffuse texture from speculars, b/c they were over-coloring the speculars. EG: some doors in torch light would look hyper-yellow, like they were amplifying the light color. The columns in training mission had a dull shine along the reliefs instead of that nice, crisp shine.

The diffuse param rgb & var_Color and such are needed for specular, b/c that's light color. (Lightcolor.rgb is light attenuation, and diffuse.rgb is actually light color.. it's confusing). Without any of that, specular is pure white and looks awkward. But, with diffuse texture mixed into it, it darkens and colors too much, looking odd again.

Anyways, I kept the old code where matDiffuse texture worked into specular, and it's commented out now. But, the new code doesn't do that.

With diffuse texture out of specular, specular brightened up quite a bit, so tweaked it down. The goal was the have a faint, broad shine in ambient light. Didn't want it sticking out like a sore thumb.

I also adjusted the ambient specular to show up on floors again, but very faintly.

Rim lighting still uses diffuse texture as a base color to keep it from looking like white haze in shadows.

Played through Crystal Grave, and the rimlighting and min ambient light made shadows dark but not "keep your lantern all the time" dark.

glprogs.stages.interaction.044.zip

  • Like 1
Link to comment
Share on other sites

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...

n20AZ2p.jpg

It flashes red, green, blue like a disco ball.. like the normal map is messing around or something.

Does anyone know which shader controls water? I may have messed with it when looking at non-interaction shaders, and borked something up.

Link to comment
Share on other sites

Normally the shaders used for water are the heatHaze ones at lest in normal idtech 4.

But to be sure, you can see what material is on a surface by opening the console and typing r_showSurfaceInfo 1 that will display the name of the surface the player is currently looking at, be mindful that this detects invisible materials as well, like nodraw, shadow, collision surfaces, etc, so you may have to move the view around, until the ray hits the required surface.  

By knowing what material the surface uses, you can search for it and see what shader it calls, or if it calls a shader at all, many materials don't call a shader they get processed automatically by the engine internal rendering system. 

Edited by HMart
Link to comment
Share on other sites

53 minutes ago, HMart said:

Normally the shaders used for water are the heatHaze ones at lest in normal idtech 4.

But to be sure, you can see what material is on a surface by opening the console and typing r_showSurfaceInfo 1 that will display the name of the surface the player is currently looking at, be mindful that this detects invisible materials as well, like nodraw, shadow, collision surfaces, etc, so you may have to move the view around, until the ray hits the required surface.  

By knowing what material the surface uses, you can search for it and see what shader it calls, or if it calls a shader at all, many materials don't call a shader they get processed automatically by the engine internal rendering system. 

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 lighting, then the water doesn't spaz out.. but then I get this...

l6lw9uT.jpg

where the rim-lighting acts like it's highlight cobblestone on grass (red-highlighting is the rim-lighting, which I amped up on red to make it stand out.)

If I include var_Color in the rimlighting, then the grass evens out and doesn't show the cobblestone pattern.. but the water spazzes out.

I was kind of happy to finally get something where I didn't have to include cubic light attenuation in with the non-cubic path, then I ran into this snag.

 

Link to comment
Share on other sites

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.

eESVElQ.gif

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 disco lighting (red,green,blue flashes)... which was occuring due to ambient rimlighting, and, more specifically, due to the var_Color being used in the base lighting for rim lighting. I have no clue why it's doing that.

But, I decided to remove var_Color from ambient rimlighting. This means the water doesn't spaz out, but grass will show cobblestone rim-lighting highlights once again.

~~~~~~~~~~~~

Merging cubic attenuation with non-cubic was what caused over-darking of ambient lighting. With it removed, levels have brighter light. But, the NdotL was creating stark darkness on the sides of things, like buildings and boxes. The u_minLevel had a half-lambert-style formula to smooth that out, but u_minLevel doesn't seem to be set (on the levels I messed with). The ambient lighting of original shaders start with a 0.5 "directionless half", then add on a specular and NdotL light dot thing to them, so they were forcing a half-lambert style by default anyways.

So, decided to make a branch where if u_minLevel isn't set, it'll default to a valve-style half-lambert light dot...

  • sqrt( lightdot * 0.5 + 0.5 )

This evens out the lighting on things, but brightens up lighting, too. So, I compensate by reducing the diffuse.rgb (light color) down by 0.5, too.

Half-lambert flattens normals a bit, b/c it reduces the 0 to 1 light dot range to 0.5 to 1. But, the rimlighting and specular in shadows help add body back to the normals in ambient lighting.

~~~~~~~~~~~~~

I shifted the direction calculations to the vertex shader. Those things can be done vertex-side to avoid calc's in fragment shader. They just need to be normalized in the fragment shader.

I did this when experimenting with a lighter version of parallax mapping from openGL tutorials.. but it still looked awful, so gave up on that again.

~~~~~~~~~~~~~

I experimented with shifting the TBN mul'ing to vertex by mul'ing it with light, view & world direction.. but it just never quite looked right. It came close, but didn't look exactly like doing TBN muls to normals in frag shader. So, gave up on that. (I even stripped the code out trying to chase down the spazzing water, but I can post that code if anyone's interested.)

glprogs.stages.interaction.048.zip

  • Like 1
Link to comment
Share on other sites

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-done in very bright shadows, and can fade into nothing in very dark shadows. So, the idea was to use the luminance of the ambient lighting to some how scale the rimlighting amount.. tone it down in bright ambient and punch it up a bit in low ambient. The method I'm using doesn't seem to work well (got same results as just mul'ing by 1.0). So, just have the static multiplier there for now.

Still not sure why rimlight.rgb was spazzing out on water. Since that part runs outside the cubic/non-cubic branch, I wonder if it's something to do with that... b/c the float rimlight only runs inside the non-cubic branch.

Anyways.. feels hackish. But, rimlight does look better when it takes var_Color into account. It blends into the scene better.

glprogs.stages.interaction.049.zip

  • Like 2
Link to comment
Share on other sites

23 hours ago, nbohr1more said:

Hmm, the latest build is missing a pbr file dependency and errors out on implicit vec4 to vec4 casts.

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 anymore.

Try moving all of your interaction folder shader files to another temp folder, then just unzipping the .zip from the last version into your interaction folder, that way only those files exist. See if it runs/compiles.

 

Link to comment
Share on other sites

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 there.

I'm testing this stuff using stencil shadows + interaction/ambient shaders. So, shadow maps / many lights may be wonky. If you have errors, give me the "file number : line number" from the console. I'll see if I can spot-check and fix.

I'm trying to consolidate code chunks into sub-routines to hopefully make it easier to kit-bash manylights into doing what common & ambient are doing. Haven't gotten around to it, though. Mostly just cleaning up the code workspace after I chucked experiments all over the place.

glprogs.stages.interaction.051.zip

  • Like 1
Link to comment
Share on other sites

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 where they are.

Also moved the specular map check (IE: if params.specularColor.rgb is not pure black) over to vertex-side after testing to see if it's set by the time it hits vertex shader. It is, so can perform the test there, and create a basic var to pass to fs shaders instead of having to do the test over and over for each pixel.

Minor changes. Just offloads processing of these from per-pixel to per-vertex.

~~~~~~~~~~~~~~~

Played a mission or two using spec dot added to light dot w/o fake spec map, and it was annoying. Without some kind of "noise" to modify the specular shine on surfaces, the shine is constant and looks awkward on some things.

So, brought back the fake spec map if the texture doesn't have a real spec map. But, this time just multiplying the spec dot float by a single channel of the fake spec map (since fake spec map is grayscale anyways), and then adding spec dot to light dot before mul'ing that by diffuse texture.

Sort of splitting the difference, basically.

~~~~~~~~~~~~~~

I'm getting weird artifacts on certain textures, still. I thought it was something I did. So, I loaded all the original TDM 2.09 shaders back in, and double-checked.. still getting them... (pic below has the interaction.common.fs non-cubic branch "totalColor" x10 to make it easier to see.)

WcxSKmh.jpg

The things clear-up as I move towards things...

9Oo7afk.jpg

I piped variables through, and it seems to be the normal map... pic below has RawN piped straight through....

VLKBZTH.jpg

Again, the artifacts clear up when I move closer to stuff...

CAKZgBD.jpg

It only impacts some textures. Not sure what's up.

Again, this is using the 2.09 original shaders.

Feels like a mip-map thing? Like the mip-map levels aren't interpolating well? Maybe it's a driver issue on my end (I'm running TDM on an Intel integrated HD 4600, and Intel doesn't exactly crank out updated drivers for their integrated chips very often).

I don't know.

glprogs.stages.interaction.052.zip

Link to comment
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.


  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...