Thank You for the information! Unfortunately I've got my next problem with toggling. When I reported that it worked I have made tests with disbaling another shader than the one I have fixed (was easier to spot). I copied the code to the shader I have fixed and wanted to toggle but it didn't work. I have made many tests and it seems to me that the shader gets broken as soon as there are certain lines of the code between if_eq and endif. Unfortunately the fix (texld r2, r0, s13) and the original code (texld r2, r0, s2) belong to it. If I disable the complete shader (mov oC0.xyzw, c3.wwww) or other lines with texld everything works fine. But with other parts of the shader not only toggleing doesn't work but also the complete shader is ignored and the original shader used instead. Even if by the default value in DX9Settings.ini the same parts of the shader are enabled that are working perfectly when I use them without if_eq code. Are there restrictions what kind of code can be used between if_eq and endif?
The only lines regarding this specific shader in Log.txt are:
[code]CreatePixelShader CRC: 0x68D76126
.\ShaderOverride\PixelShaders\68D76126.txt.1
pD3DXAssembleShaderFromFile
pixel Shader overrode without errors CRC: 0x68D76126
luaL_openlibs
luaL_loadfile cannot open PSscript.lua: No such file or directory [/code]
The lua error is mentioned for every PS loaded. These lines are always the same whether the shader override works or not.
Thank You for the information! Unfortunately I've got my next problem with toggling. When I reported that it worked I have made tests with disbaling another shader than the one I have fixed (was easier to spot). I copied the code to the shader I have fixed and wanted to toggle but it didn't work. I have made many tests and it seems to me that the shader gets broken as soon as there are certain lines of the code between if_eq and endif. Unfortunately the fix (texld r2, r0, s13) and the original code (texld r2, r0, s2) belong to it. If I disable the complete shader (mov oC0.xyzw, c3.wwww) or other lines with texld everything works fine. But with other parts of the shader not only toggleing doesn't work but also the complete shader is ignored and the original shader used instead. Even if by the default value in DX9Settings.ini the same parts of the shader are enabled that are working perfectly when I use them without if_eq code. Are there restrictions what kind of code can be used between if_eq and endif?
The only lines regarding this specific shader in Log.txt are:
CreatePixelShader CRC: 0x68D76126
.\ShaderOverride\PixelShaders\68D76126.txt.1
pD3DXAssembleShaderFromFile
pixel Shader overrode without errors CRC: 0x68D76126
luaL_openlibs
luaL_loadfile cannot open PSscript.lua: No such file or directory
The lua error is mentioned for every PS loaded. These lines are always the same whether the shader override works or not.
My original display name is 3d4dd - for some reason Nvidia changed it..?!
Yes, the Lua error lines are logging noise, they happen always when there is no lua script. Not an error, and won't affect this scenario.
There are some weird restrictions on what can be used in if_eq statements, but it's unlikely that is the problem here. Always possible, as I've run into this in the past as well, where statements will assemble properly, with no error, but fail at runtime. As an example that took me days to figure out, an "add r0.w, c200.x, c201.x" statement will silently fail on the GPU because it's apparently not possible to use two constants in an add. This is the really bad part of ASM, but it's not helped by the Microsoft assembler being fairly brain-dead about stuff it should flag as errors.
Now the reason I say it seems unlikely to be an ASM problem here is because when you get the error, it reverts back to the original shader, instead of being blank or dead. That suggests a problem with HelixMod instead, and its overriding mechanism.
Try setting up the way you like, but don't use F10, relaunch the game. Launching sometimes is a cleaner load for the code, and might be a different load scenario in HelixMod.
Change the texld instructions for the sampler load to be texldl instead. That's the SM3 version of the instruction, and should have no effect, but...
Speaking of which, this is ps_3_0 right? Older versions have a lot more restrictions.
Another thing to try, that I've often thought of, but never tried, is to change the shader model to 4.0 instead. Try changing to ps_4_0 instead with the same code. The only reason to use 3.0 is for DX9 hardware support, but we all have SM5 hardware nowadays, so that's an arbitrary restriction.
I don't think the game itself will care one way or the other, and SM4 has far lower restrictions on code. There is no restriction on mixing SM3 and SM4 shaders I don't think, but don't hold me to that, it's a complicated environment.
I'll be very interested to know if that works.
If none of that helps, post your code here in a <code> block and we'll take a look.
Yes, the Lua error lines are logging noise, they happen always when there is no lua script. Not an error, and won't affect this scenario.
There are some weird restrictions on what can be used in if_eq statements, but it's unlikely that is the problem here. Always possible, as I've run into this in the past as well, where statements will assemble properly, with no error, but fail at runtime. As an example that took me days to figure out, an "add r0.w, c200.x, c201.x" statement will silently fail on the GPU because it's apparently not possible to use two constants in an add. This is the really bad part of ASM, but it's not helped by the Microsoft assembler being fairly brain-dead about stuff it should flag as errors.
Now the reason I say it seems unlikely to be an ASM problem here is because when you get the error, it reverts back to the original shader, instead of being blank or dead. That suggests a problem with HelixMod instead, and its overriding mechanism.
Try setting up the way you like, but don't use F10, relaunch the game. Launching sometimes is a cleaner load for the code, and might be a different load scenario in HelixMod.
Change the texld instructions for the sampler load to be texldl instead. That's the SM3 version of the instruction, and should have no effect, but...
Speaking of which, this is ps_3_0 right? Older versions have a lot more restrictions.
Another thing to try, that I've often thought of, but never tried, is to change the shader model to 4.0 instead. Try changing to ps_4_0 instead with the same code. The only reason to use 3.0 is for DX9 hardware support, but we all have SM5 hardware nowadays, so that's an arbitrary restriction.
I don't think the game itself will care one way or the other, and SM4 has far lower restrictions on code. There is no restriction on mixing SM3 and SM4 shaders I don't think, but don't hold me to that, it's a complicated environment.
I'll be very interested to know if that works.
If none of that helps, post your code here in a <code> block and we'll take a look.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
Thank You for Your suggestions!!! Finally replacing texld with texldl worked :)
With ps_4_0 the shader was completely ignored even when there was no if_eq in the code. I had the same issue with ps_2_0 shaders I wanted to disable with mov oC0.xyzw. I thought that Helixmod only handles ps_3_0?
Thank You for Your suggestions!!! Finally replacing texld with texldl worked :)
With ps_4_0 the shader was completely ignored even when there was no if_eq in the code. I had the same issue with ps_2_0 shaders I wanted to disable with mov oC0.xyzw. I thought that Helixmod only handles ps_3_0?
My original display name is 3d4dd - for some reason Nvidia changed it..?!
[quote="3d4dd"]Thank You for Your suggestions!!! Finally replacing texld with texldl worked :)
With ps_4_0 the shader was completely ignored even when there was no if_eq in the code. I had the same issue with ps_2_0 shaders I wanted to disable with mov oC0.xyzw. I thought that Helixmod only handles ps_3_0?[/quote]Good to know, thanks for the info. I would not have expected that texldl to be the difference, but we are down at the lowest levels and small things can matter.
Yeah, the ps_4_0 was more of a flyer, it depends upon how Helix calls the assemble function. It should use the in-shader definition to compile, but he might force it to ps_3_0 at the call. Sounds like that is probably the case here.
Please do me a favor, and that as a 'gotcha' on the wiki. http://wiki.bo3b.net/index.php?title=HelixMod_Feature_List
3d4dd said:Thank You for Your suggestions!!! Finally replacing texld with texldl worked :)
With ps_4_0 the shader was completely ignored even when there was no if_eq in the code. I had the same issue with ps_2_0 shaders I wanted to disable with mov oC0.xyzw. I thought that Helixmod only handles ps_3_0?
Good to know, thanks for the info. I would not have expected that texldl to be the difference, but we are down at the lowest levels and small things can matter.
Yeah, the ps_4_0 was more of a flyer, it depends upon how Helix calls the assemble function. It should use the in-shader definition to compile, but he might force it to ps_3_0 at the call. Sounds like that is probably the case here.
Hello Friends of 3D, it's time again for a new lesson. Apologies for being a bit late with this one.
[b]Lesson 6 - [i]prime directive[/i] is up![/b]
This one is about the main code or formula that we use to fix stereo effects, and shows a couple of examples of using the formula to fix an effect.
I go into some depth about why we use the formula and why it works, but nothing to heavy.
Realistically, it doesn't really matter what it is, it's a bit of a black-box to us to use it, but I think it helps make it more clear where to apply your experimentation.
Hello Friends of 3D, it's time again for a new lesson. Apologies for being a bit late with this one.
Lesson 6 - prime directive is up!
This one is about the main code or formula that we use to fix stereo effects, and shows a couple of examples of using the formula to fix an effect.
I go into some depth about why we use the formula and why it works, but nothing to heavy.
Realistically, it doesn't really matter what it is, it's a bit of a black-box to us to use it, but I think it helps make it more clear where to apply your experimentation.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
Great! Hang in there!
I'm not too stoked with how Lesson 4 turned out, but hopefully it was still worth the time. Overall, I expect there will be some good and some bad, but mostly I think these are saying what I think is helpful to learn.
I can promise that Lesson 6 will be very interesting. And for Pirate in particular, you will find out why moving the z parameter didn't work, and why we move the x parameter instead.
I'm not too stoked with how Lesson 4 turned out, but hopefully it was still worth the time. Overall, I expect there will be some good and some bad, but mostly I think these are saying what I think is helpful to learn.
I can promise that Lesson 6 will be very interesting. And for Pirate in particular, you will find out why moving the z parameter didn't work, and why we move the x parameter instead.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
Fantastic! Today I'll spend quite a chunk of time on the newly added lesson 6.
Actually I'm getting this "butterfly feeling" in my stomach.
Yes, I'm that excited. hehe :)
Fantastic! Today I'll spend quite a chunk of time on the newly added lesson 6.
Actually I'm getting this "butterfly feeling" in my stomach.
Yes, I'm that excited. hehe :)
CAB : Lian Li Tyr X-2000B | PSU : Cooler Master V1200 (1200W) | MB : Asus Rampage IV Extreme ROG | CPU : INTELi7 3930K @ 4,5GHz | FAN : Noctua NH-D14 SE | GPU(s) : (Tri-SLI) EVGA Geforce GTX 980Ti SC+ ACX 2.0 | MEM : Corsair Vengeance DDR3 1600MHz (16GB) | SSD : OCZ Vertex 2 (120GB) | SSD(s) : Samsung EVO 850 Pro (2x500GB RAID0 | SSD : Kingston HyperX 3K (2x240GB RAID0, 1x120GB) | SSD : Samsung EVO 840 (1TB) | SCR : Eizo Flexscan SX2461WK (IPS/Editing) | SCR : Eizo Flexscan EV2736W (IPS/1440p/Gaming/Editing) | SCR : Wacom Cintiq Companion Hybrid (Photo Editing/Illustration/Drawing) | SCR : Asus ROG Swift PG278Q (1440p/144Hz/G-Sync/3DV 2/Gaming) | SCR : Asus PB287Q (4K Gaming/DAW) | SCR/TV : Philips 55" PUS9109/12 UHD (4K Gaming) | NAS : QNAP TS-419PII /w Lian Li EX-503B Drive Bay | HID : (Keyboard) Corsair K95 RGB Brown Cherry (Mouse) Corsair M95 Performance & Generic Logitech HID Devices | NIC : Asus RT-AC66U (with Asus repeaters| NIC : Jensen Scandinavia 8-port Gigabit switch | SYS : NVIDIA SHIELD Portable | SYS : NVIDIA SHIELD Tablet (16 GB version/non-LTE) | Oculus Rift DK2
EDIT!!
Jeez, obviously I've been bumping my head in the wall for all the wrong reasons.
I should've just started out by finding the vertex shader through searching in the
dumps folder, like you mentioned, since something is obviously off when I try to
find the actual vertex shader in the game.
But I must admit, I'm slightly confused about the method you demonstrated. I searched
for texcoord5, and get a ton of hits in the vertexshader folder, but I'm a little
unsure how to proceed from here. I understand the going through the code and commenting
out aspect, but uncertain about the actual procedure for effectively going through such
an enormous amount of vertex shaders. There are a total of 797 vertex shader files with
the function "texcoord5". :/
Original post :
I'm having a little problem finding the correct vertex shader for the water layer(s).
The closest would be "VertexShader_67_CRC32_40451D4D".
None of the other vertex shaders seem to do anything remotely close to affect any
layers or elements relating to the water, neither the halos around the weapon when
pointing towards/over the water.
"VertexShader_67_CRC32_40451D4D" is the only shader that disabled the thick black halos
around the weapon when I pointed/aimed the weapon directly on top of the water. For
every other VS, when aiming over the water surface, the thick black halos would appear.
So I thought this had to be the shader responsible for the refraction/offset for
one of the layers on the water, causing the halos on the weapon.
However I cannot seem to disable the halos by altering the code in the vertex shader.
Upon inspection, I noticed input location "dcl_position v0" was related to
[code]mad r1.xyz, v0, r1, c235[/code]
, which was the only statement that had a r1 with three
parameters. In other words due to its three parameters, it could be associated with
position (dimensions).
The code I've used in the shader file (just for the toggle mechanism and nulling with
local reg c201 to output location o0) :
[code]def 201, 0, 1, 0.0625, 0
mov r30.z, c250.z
if_eq r30.z, c201.x
mov o0, c201.wwww
endif[/code]
I'm using 250 as the DefVSConst1 in dx9settings for toggling the effect on and off,
in addition to const3 (z). So I've assigned an additional key for toggling the effect
on/off. Just for the sake of good habits.
Continuing : Following the path of r1 (with its three dimensions), the last statement
[code]mad o0, c3, r0.w, r1[/code]
suggests position o0 (being correlated in the same
statement), which is the only output position used in the shader file.
Still the effect is not disabled when I refresh with F10 in-game, neither by
restaring the game. Furthermore there are no texcoord outputs in the VS,
which cannot be correct? This must be the wrong shader. I've also tried
to change UseRenderedShaders = true, to UseRenderedShaders = false, since
it could be that somehow the shader responsible for the refraction on the
water layer wouldn't show when navigating through them. (I've paid close
attention to every single shader number also by the way).
The odd thing is, that when starting up the game, loading the level, when
standing by the water, there are an equal amount of vertex shaders (81),
even when setting UseRenderedShaders to "false".
Commenting out different parts of the code doesn't work, since generel
disabling won't work. Maybe they don't necessarily co-exist.
So I don't know. Maybe I'm just tired in my head, or something odd is
happening, say some kind of a bug/glitch that I have no control over. :(
Original code (shader file content) :
[code]// halos around "gun" (only affected when pointing towards water; over water)
// not visible when overlapping other textures.
// could be related to one of the underlying layers in the water causing "refraction/offset"
//
// Generated by Microsoft (R) HLSL Shader Compiler 9.27.952.3022
//
// Parameters:
//
// float4x3 BoneMatrices[75];
// float4x4 LocalToWorld;
// float3 MeshExtension;
// float3 MeshOrigin;
// float4x4 ViewProjectionMatrix;
//
//
// Registers:
//
// Name Reg Size
// -------------------- ----- ----
// ViewProjectionMatrix c0 4
// BoneMatrices c6 225
// LocalToWorld c231 4
// MeshOrigin c235 1
// MeshExtension c236 1
//
vs_3_0
def c4, 3, 1, 0, 0
dcl_position v0
dcl_blendindices v1
dcl_blendweight v2
dcl_position o0
mul r0, c4.x, v1
mova a0, r0
mul r0, v2.y, c7[a0.y]
mad r0, v2.x, c7[a0.x], r0
mad r0, v2.z, c7[a0.z], r0
mad r0, v2.w, c7[a0.w], r0
mov r1.xyz, c236
mad r1.xyz, v0, r1, c235
mov r1.w, c4.y
dp4 r0.x, r1, r0
mul r0, r0.x, c232
mul r2, v2.y, c6[a0.y]
mad r2, v2.x, c6[a0.x], r2
mad r2, v2.z, c6[a0.z], r2
mad r2, v2.w, c6[a0.w], r2
dp4 r2.x, r1, r2
mad r0, c231, r2.x, r0
mul r2, v2.y, c8[a0.y]
mad r2, v2.x, c8[a0.x], r2
mad r2, v2.z, c8[a0.z], r2
mad r2, v2.w, c8[a0.w], r2
dp4 r1.x, r1, r2
mad r0, c233, r1.x, r0
add r0, r0, c234
mul r1, r0.y, c1
mad r1, c0, r0.x, r1
mad r1, c2, r0.z, r1
mad o0, c3, r0.w, r1
// approximately 28 instruction slots used
[/code]
Jeez, obviously I've been bumping my head in the wall for all the wrong reasons.
I should've just started out by finding the vertex shader through searching in the
dumps folder, like you mentioned, since something is obviously off when I try to
find the actual vertex shader in the game.
But I must admit, I'm slightly confused about the method you demonstrated. I searched
for texcoord5, and get a ton of hits in the vertexshader folder, but I'm a little
unsure how to proceed from here. I understand the going through the code and commenting
out aspect, but uncertain about the actual procedure for effectively going through such
an enormous amount of vertex shaders. There are a total of 797 vertex shader files with
the function "texcoord5". :/
Original post :
I'm having a little problem finding the correct vertex shader for the water layer(s).
The closest would be "VertexShader_67_CRC32_40451D4D".
None of the other vertex shaders seem to do anything remotely close to affect any
layers or elements relating to the water, neither the halos around the weapon when
pointing towards/over the water.
"VertexShader_67_CRC32_40451D4D" is the only shader that disabled the thick black halos
around the weapon when I pointed/aimed the weapon directly on top of the water. For
every other VS, when aiming over the water surface, the thick black halos would appear.
So I thought this had to be the shader responsible for the refraction/offset for
one of the layers on the water, causing the halos on the weapon.
However I cannot seem to disable the halos by altering the code in the vertex shader.
Upon inspection, I noticed input location "dcl_position v0" was related to
mad r1.xyz, v0, r1, c235
, which was the only statement that had a r1 with three
parameters. In other words due to its three parameters, it could be associated with
position (dimensions).
The code I've used in the shader file (just for the toggle mechanism and nulling with
local reg c201 to output location o0) :
I'm using 250 as the DefVSConst1 in dx9settings for toggling the effect on and off,
in addition to const3 (z). So I've assigned an additional key for toggling the effect
on/off. Just for the sake of good habits.
Continuing : Following the path of r1 (with its three dimensions), the last statement
mad o0, c3, r0.w, r1
suggests position o0 (being correlated in the same
statement), which is the only output position used in the shader file.
Still the effect is not disabled when I refresh with F10 in-game, neither by
restaring the game. Furthermore there are no texcoord outputs in the VS,
which cannot be correct? This must be the wrong shader. I've also tried
to change UseRenderedShaders = true, to UseRenderedShaders = false, since
it could be that somehow the shader responsible for the refraction on the
water layer wouldn't show when navigating through them. (I've paid close
attention to every single shader number also by the way).
The odd thing is, that when starting up the game, loading the level, when
standing by the water, there are an equal amount of vertex shaders (81),
even when setting UseRenderedShaders to "false".
Commenting out different parts of the code doesn't work, since generel
disabling won't work. Maybe they don't necessarily co-exist.
So I don't know. Maybe I'm just tired in my head, or something odd is
happening, say some kind of a bug/glitch that I have no control over. :(
Original code (shader file content) :
// halos around "gun" (only affected when pointing towards water; over water)
// not visible when overlapping other textures.
// could be related to one of the underlying layers in the water causing "refraction/offset"
//
// Generated by Microsoft (R) HLSL Shader Compiler 9.27.952.3022
//
// Parameters:
//
// float4x3 BoneMatrices[75];
// float4x4 LocalToWorld;
// float3 MeshExtension;
// float3 MeshOrigin;
// float4x4 ViewProjectionMatrix;
//
//
// Registers:
//
// Name Reg Size
// -------------------- ----- ----
// ViewProjectionMatrix c0 4
// BoneMatrices c6 225
// LocalToWorld c231 4
// MeshOrigin c235 1
// MeshExtension c236 1
//
It seems to me like you are thinking about this correctly, looking for the halo to be missing is a good idea. It's not quite complete though, because the halo should disappear when the texture disappears, and in this case the texture never disappears.
The shader hunting is sometimes really hard and not clear, because games do all sorts of wacky stuff with them. As an example, the shader for lava in Lesson 6 is not at all obvious, because the whole room goes dark except for the fire and lava fountains. The room goes dark because the Lava itself is the source of the light in the room, so by killing the lava, we've killed the primary light.
This water looks to be one of those cases where it's doing something really weird.
For your shader there, that won't be the right one, because the outputs don't match the inputs to the PixelShader associated with the effect. The PixelShader can't do anything standalone, it needs data input as the vertices+triangles to paint its textures upon.
So, with no match on the output, not even a partial match, this can't be the right one. It's possible to have a partial match, but the VertexShader outputs would need to be a superset of the PixelShader inputs. So, for example, the VS might have extra texcoord outputs that don't show in the PS, but it must at least provide all inputs used by the PS, otherwise the PS would have undefined data and produce random results.
The other clue there that this is not the right shader is the BoneMatrices matrix. I wouldn't expect you to know this, but that is almost always used for creatures, as a matrix hooking together arms and legs and teeth and stuff. Most likely this shader is for the worm itself.
To use the alternate approach of looking through dumps for the VS, you can expect your search criteria to include other inputs to the PS. So, texcoord5 is the one that affects it, but we can also require that texcoord4 and texcoord6 be output from the VS too. That will shrink the list. But maybe not enough.
The last thing that comes to mind is to try to go through all the ones that make the screen go black. So go ahead and mark those and move them to ShaderOverride and make them active for experiments. In general full black screen shaders are something else, but if this is like the lava effect, it could make it fully dark.
Both are water/liquid type effects with multiple layers, and the game makers tend to re-use their code, so finding something similar to the lava VS is the most likely approach.
It seems to me like you are thinking about this correctly, looking for the halo to be missing is a good idea. It's not quite complete though, because the halo should disappear when the texture disappears, and in this case the texture never disappears.
The shader hunting is sometimes really hard and not clear, because games do all sorts of wacky stuff with them. As an example, the shader for lava in Lesson 6 is not at all obvious, because the whole room goes dark except for the fire and lava fountains. The room goes dark because the Lava itself is the source of the light in the room, so by killing the lava, we've killed the primary light.
This water looks to be one of those cases where it's doing something really weird.
For your shader there, that won't be the right one, because the outputs don't match the inputs to the PixelShader associated with the effect. The PixelShader can't do anything standalone, it needs data input as the vertices+triangles to paint its textures upon.
So, with no match on the output, not even a partial match, this can't be the right one. It's possible to have a partial match, but the VertexShader outputs would need to be a superset of the PixelShader inputs. So, for example, the VS might have extra texcoord outputs that don't show in the PS, but it must at least provide all inputs used by the PS, otherwise the PS would have undefined data and produce random results.
The other clue there that this is not the right shader is the BoneMatrices matrix. I wouldn't expect you to know this, but that is almost always used for creatures, as a matrix hooking together arms and legs and teeth and stuff. Most likely this shader is for the worm itself.
To use the alternate approach of looking through dumps for the VS, you can expect your search criteria to include other inputs to the PS. So, texcoord5 is the one that affects it, but we can also require that texcoord4 and texcoord6 be output from the VS too. That will shrink the list. But maybe not enough.
The last thing that comes to mind is to try to go through all the ones that make the screen go black. So go ahead and mark those and move them to ShaderOverride and make them active for experiments. In general full black screen shaders are something else, but if this is like the lava effect, it could make it fully dark.
Both are water/liquid type effects with multiple layers, and the game makers tend to re-use their code, so finding something similar to the lava VS is the most likely approach.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
Thank you so much for these tips. I actually had an idea that the chosen vertex shader wasn't the right one due to some of the reasons you mentioned (so that is kind of promising in and by itself), but I guess I wasn't too sure about it. Part of the learning process. :) But with your input it is more clear now. :) Especially the section you mentioned where the responsible shader could turn a lot of the screen dark, due to the effect being responsible for operating as a light source for the room. Some vertex shaders did cause a lot of the room to get darker, thus not entirely, so I'll have a closer look. Your suggestions regarding searching, and narrowing down the hits on the amount of shader files will be extremely useful. Back to the drawing board. ;)
Thank you so much for these tips. I actually had an idea that the chosen vertex shader wasn't the right one due to some of the reasons you mentioned (so that is kind of promising in and by itself), but I guess I wasn't too sure about it. Part of the learning process. :) But with your input it is more clear now. :) Especially the section you mentioned where the responsible shader could turn a lot of the screen dark, due to the effect being responsible for operating as a light source for the room. Some vertex shaders did cause a lot of the room to get darker, thus not entirely, so I'll have a closer look. Your suggestions regarding searching, and narrowing down the hits on the amount of shader files will be extremely useful. Back to the drawing board. ;)
CAB : Lian Li Tyr X-2000B | PSU : Cooler Master V1200 (1200W) | MB : Asus Rampage IV Extreme ROG | CPU : INTELi7 3930K @ 4,5GHz | FAN : Noctua NH-D14 SE | GPU(s) : (Tri-SLI) EVGA Geforce GTX 980Ti SC+ ACX 2.0 | MEM : Corsair Vengeance DDR3 1600MHz (16GB) | SSD : OCZ Vertex 2 (120GB) | SSD(s) : Samsung EVO 850 Pro (2x500GB RAID0 | SSD : Kingston HyperX 3K (2x240GB RAID0, 1x120GB) | SSD : Samsung EVO 840 (1TB) | SCR : Eizo Flexscan SX2461WK (IPS/Editing) | SCR : Eizo Flexscan EV2736W (IPS/1440p/Gaming/Editing) | SCR : Wacom Cintiq Companion Hybrid (Photo Editing/Illustration/Drawing) | SCR : Asus ROG Swift PG278Q (1440p/144Hz/G-Sync/3DV 2/Gaming) | SCR : Asus PB287Q (4K Gaming/DAW) | SCR/TV : Philips 55" PUS9109/12 UHD (4K Gaming) | NAS : QNAP TS-419PII /w Lian Li EX-503B Drive Bay | HID : (Keyboard) Corsair K95 RGB Brown Cherry (Mouse) Corsair M95 Performance & Generic Logitech HID Devices | NIC : Asus RT-AC66U (with Asus repeaters| NIC : Jensen Scandinavia 8-port Gigabit switch | SYS : NVIDIA SHIELD Portable | SYS : NVIDIA SHIELD Tablet (16 GB version/non-LTE) | Oculus Rift DK2
Yeah, this is the part where it's genuine hacking. We just don't know how it works in a game, and have no good way to find out, so we just have to keep trying stuff.
I may have sand-bagged you there with that water shader, it seems much harder than I would have thought given the rest of the game.
If you want a simpler variant, take a look at the oil shader in the lava+bomb room. I know for sure that one can be solved.
The water one is less clear if we can solve it. I've looked a bit, and will take a close look soon. The primary problem is that the water surface is at the wrong depth. It looks like refraction because of the transparency, but the actual problem is it's at the wrong depth in 3D.
The reason I think that is because if you look at where the water hits the stairs, you can see it diverge on both left and right, get wider as it goes into the water. If it were refraction, we'd expect the angle to change, but not the width. That's our .x parameter being widened on both left and right eyes, which is exactly what we'd do to add depth. If you look at it carefully, you can see it's at the wrong depth relative to the stairs. If you stare directly into water and nothing else, it actually looks OK.
Thus, if we can shrink its .x location, we can make it line back up. Not sure of course, but that is presently my best guess. Good luck!
Yeah, this is the part where it's genuine hacking. We just don't know how it works in a game, and have no good way to find out, so we just have to keep trying stuff.
I may have sand-bagged you there with that water shader, it seems much harder than I would have thought given the rest of the game.
If you want a simpler variant, take a look at the oil shader in the lava+bomb room. I know for sure that one can be solved.
The water one is less clear if we can solve it. I've looked a bit, and will take a close look soon. The primary problem is that the water surface is at the wrong depth. It looks like refraction because of the transparency, but the actual problem is it's at the wrong depth in 3D.
The reason I think that is because if you look at where the water hits the stairs, you can see it diverge on both left and right, get wider as it goes into the water. If it were refraction, we'd expect the angle to change, but not the width. That's our .x parameter being widened on both left and right eyes, which is exactly what we'd do to add depth. If you look at it carefully, you can see it's at the wrong depth relative to the stairs. If you stare directly into water and nothing else, it actually looks OK.
Thus, if we can shrink its .x location, we can make it line back up. Not sure of course, but that is presently my best guess. Good luck!
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
The water shader is easily fixable but it's difficult to pinpoint by cycling shaders. It's VS A2E7F5BC. When it's disabled, you get multi-colored flashes:
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/61726/[/img]
I only found it because I edited all of the vertex shaders currently on the screen at once, since I couldn't locate it via cycling.
fixed reflections:
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/61728/[/img]
Because of the stuff like this, I think that dumping all of the shaders & having a script to mass edit them all at once seems like the way to go.
The water shader is easily fixable but it's difficult to pinpoint by cycling shaders. It's VS A2E7F5BC. When it's disabled, you get multi-colored flashes:
I only found it because I edited all of the vertex shaders currently on the screen at once, since I couldn't locate it via cycling.
fixed reflections:
Because of the stuff like this, I think that dumping all of the shaders & having a script to mass edit them all at once seems like the way to go.
@4everAwake
EDIT.
Never mind what I wrote about nothing happening on the screen. I noticed on your screenshot that it was the vs number 40, so I tried to disable it and I couldn't notice any color fluctuations. I forgot that "UseRenderedShaders = true" will change the amount of shaders based on what is happening in the scene at a specific point in time. The currently active shaders :) I fired it up again, and noticed the changes on screen. A2E7F5BC was number 64 at my current location. Ahhh, still fresh in the learning curve.
So I've skipped that shader previously since there was no change on screen, except the color fluctuations, so I would never have thought that could be the shader associated with the water.
But what did happen was that when I disabled that shader, and looked around, aimed at a different surface, the whole game crashed! Very strange. I'm very new at this, so I don't know anything about the script you're using. Would you mind telling me how it works? Sounds interesting.
EDIT.
Never mind what I wrote about nothing happening on the screen. I noticed on your screenshot that it was the vs number 40, so I tried to disable it and I couldn't notice any color fluctuations. I forgot that "UseRenderedShaders = true" will change the amount of shaders based on what is happening in the scene at a specific point in time. The currently active shaders :) I fired it up again, and noticed the changes on screen. A2E7F5BC was number 64 at my current location. Ahhh, still fresh in the learning curve.
So I've skipped that shader previously since there was no change on screen, except the color fluctuations, so I would never have thought that could be the shader associated with the water.
But what did happen was that when I disabled that shader, and looked around, aimed at a different surface, the whole game crashed! Very strange. I'm very new at this, so I don't know anything about the script you're using. Would you mind telling me how it works? Sounds interesting.
CAB : Lian Li Tyr X-2000B | PSU : Cooler Master V1200 (1200W) | MB : Asus Rampage IV Extreme ROG | CPU : INTELi7 3930K @ 4,5GHz | FAN : Noctua NH-D14 SE | GPU(s) : (Tri-SLI) EVGA Geforce GTX 980Ti SC+ ACX 2.0 | MEM : Corsair Vengeance DDR3 1600MHz (16GB) | SSD : OCZ Vertex 2 (120GB) | SSD(s) : Samsung EVO 850 Pro (2x500GB RAID0 | SSD : Kingston HyperX 3K (2x240GB RAID0, 1x120GB) | SSD : Samsung EVO 840 (1TB) | SCR : Eizo Flexscan SX2461WK (IPS/Editing) | SCR : Eizo Flexscan EV2736W (IPS/1440p/Gaming/Editing) | SCR : Wacom Cintiq Companion Hybrid (Photo Editing/Illustration/Drawing) | SCR : Asus ROG Swift PG278Q (1440p/144Hz/G-Sync/3DV 2/Gaming) | SCR : Asus PB287Q (4K Gaming/DAW) | SCR/TV : Philips 55" PUS9109/12 UHD (4K Gaming) | NAS : QNAP TS-419PII /w Lian Li EX-503B Drive Bay | HID : (Keyboard) Corsair K95 RGB Brown Cherry (Mouse) Corsair M95 Performance & Generic Logitech HID Devices | NIC : Asus RT-AC66U (with Asus repeaters| NIC : Jensen Scandinavia 8-port Gigabit switch | SYS : NVIDIA SHIELD Portable | SYS : NVIDIA SHIELD Tablet (16 GB version/non-LTE) | Oculus Rift DK2
The only lines regarding this specific shader in Log.txt are:
The lua error is mentioned for every PS loaded. These lines are always the same whether the shader override works or not.
My original display name is 3d4dd - for some reason Nvidia changed it..?!
There are some weird restrictions on what can be used in if_eq statements, but it's unlikely that is the problem here. Always possible, as I've run into this in the past as well, where statements will assemble properly, with no error, but fail at runtime. As an example that took me days to figure out, an "add r0.w, c200.x, c201.x" statement will silently fail on the GPU because it's apparently not possible to use two constants in an add. This is the really bad part of ASM, but it's not helped by the Microsoft assembler being fairly brain-dead about stuff it should flag as errors.
Now the reason I say it seems unlikely to be an ASM problem here is because when you get the error, it reverts back to the original shader, instead of being blank or dead. That suggests a problem with HelixMod instead, and its overriding mechanism.
Try setting up the way you like, but don't use F10, relaunch the game. Launching sometimes is a cleaner load for the code, and might be a different load scenario in HelixMod.
Change the texld instructions for the sampler load to be texldl instead. That's the SM3 version of the instruction, and should have no effect, but...
Speaking of which, this is ps_3_0 right? Older versions have a lot more restrictions.
Another thing to try, that I've often thought of, but never tried, is to change the shader model to 4.0 instead. Try changing to ps_4_0 instead with the same code. The only reason to use 3.0 is for DX9 hardware support, but we all have SM5 hardware nowadays, so that's an arbitrary restriction.
I don't think the game itself will care one way or the other, and SM4 has far lower restrictions on code. There is no restriction on mixing SM3 and SM4 shaders I don't think, but don't hold me to that, it's a complicated environment.
I'll be very interested to know if that works.
If none of that helps, post your code here in a <code> block and we'll take a look.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
With ps_4_0 the shader was completely ignored even when there was no if_eq in the code. I had the same issue with ps_2_0 shaders I wanted to disable with mov oC0.xyzw. I thought that Helixmod only handles ps_3_0?
My original display name is 3d4dd - for some reason Nvidia changed it..?!
Yeah, the ps_4_0 was more of a flyer, it depends upon how Helix calls the assemble function. It should use the in-shader definition to compile, but he might force it to ps_3_0 at the call. Sounds like that is probably the case here.
Please do me a favor, and that as a 'gotcha' on the wiki. http://wiki.bo3b.net/index.php?title=HelixMod_Feature_List
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
Lesson 6 - prime directive is up!
This one is about the main code or formula that we use to fix stereo effects, and shows a couple of examples of using the formula to fix an effect.
I go into some depth about why we use the formula and why it works, but nothing to heavy.
Realistically, it doesn't really matter what it is, it's a bit of a black-box to us to use it, but I think it helps make it more clear where to apply your experimentation.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
Dual boot Win 7 x64 & Win 10 (1809) | Geforce Drivers 417.35
I'm not too stoked with how Lesson 4 turned out, but hopefully it was still worth the time. Overall, I expect there will be some good and some bad, but mostly I think these are saying what I think is helpful to learn.
I can promise that Lesson 6 will be very interesting. And for Pirate in particular, you will find out why moving the z parameter didn't work, and why we move the x parameter instead.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
Actually I'm getting this "butterfly feeling" in my stomach.
Yes, I'm that excited. hehe :)
CAB : Lian Li Tyr X-2000B | PSU : Cooler Master V1200 (1200W) | MB : Asus Rampage IV Extreme ROG | CPU : INTELi7 3930K @ 4,5GHz | FAN : Noctua NH-D14 SE | GPU(s) : (Tri-SLI) EVGA Geforce GTX 980Ti SC+ ACX 2.0 | MEM : Corsair Vengeance DDR3 1600MHz (16GB) | SSD : OCZ Vertex 2 (120GB) | SSD(s) : Samsung EVO 850 Pro (2x500GB RAID0 | SSD : Kingston HyperX 3K (2x240GB RAID0, 1x120GB) | SSD : Samsung EVO 840 (1TB) | SCR : Eizo Flexscan SX2461WK (IPS/Editing) | SCR : Eizo Flexscan EV2736W (IPS/1440p/Gaming/Editing) | SCR : Wacom Cintiq Companion Hybrid (Photo Editing/Illustration/Drawing) | SCR : Asus ROG Swift PG278Q (1440p/144Hz/G-Sync/3DV 2/Gaming) | SCR : Asus PB287Q (4K Gaming/DAW) | SCR/TV : Philips 55" PUS9109/12 UHD (4K Gaming) | NAS : QNAP TS-419PII /w Lian Li EX-503B Drive Bay | HID : (Keyboard) Corsair K95 RGB Brown Cherry (Mouse) Corsair M95 Performance & Generic Logitech HID Devices | NIC : Asus RT-AC66U (with Asus repeaters| NIC : Jensen Scandinavia 8-port Gigabit switch | SYS : NVIDIA SHIELD Portable | SYS : NVIDIA SHIELD Tablet (16 GB version/non-LTE) | Oculus Rift DK2
Jeez, obviously I've been bumping my head in the wall for all the wrong reasons.
I should've just started out by finding the vertex shader through searching in the
dumps folder, like you mentioned, since something is obviously off when I try to
find the actual vertex shader in the game.
But I must admit, I'm slightly confused about the method you demonstrated. I searched
for texcoord5, and get a ton of hits in the vertexshader folder, but I'm a little
unsure how to proceed from here. I understand the going through the code and commenting
out aspect, but uncertain about the actual procedure for effectively going through such
an enormous amount of vertex shaders. There are a total of 797 vertex shader files with
the function "texcoord5". :/
Original post :
I'm having a little problem finding the correct vertex shader for the water layer(s).
The closest would be "VertexShader_67_CRC32_40451D4D".
None of the other vertex shaders seem to do anything remotely close to affect any
layers or elements relating to the water, neither the halos around the weapon when
pointing towards/over the water.
"VertexShader_67_CRC32_40451D4D" is the only shader that disabled the thick black halos
around the weapon when I pointed/aimed the weapon directly on top of the water. For
every other VS, when aiming over the water surface, the thick black halos would appear.
So I thought this had to be the shader responsible for the refraction/offset for
one of the layers on the water, causing the halos on the weapon.
However I cannot seem to disable the halos by altering the code in the vertex shader.
Upon inspection, I noticed input location "dcl_position v0" was related to
, which was the only statement that had a r1 with three
parameters. In other words due to its three parameters, it could be associated with
position (dimensions).
The code I've used in the shader file (just for the toggle mechanism and nulling with
local reg c201 to output location o0) :
I'm using 250 as the DefVSConst1 in dx9settings for toggling the effect on and off,
in addition to const3 (z). So I've assigned an additional key for toggling the effect
on/off. Just for the sake of good habits.
Continuing : Following the path of r1 (with its three dimensions), the last statement
suggests position o0 (being correlated in the same
statement), which is the only output position used in the shader file.
Still the effect is not disabled when I refresh with F10 in-game, neither by
restaring the game. Furthermore there are no texcoord outputs in the VS,
which cannot be correct? This must be the wrong shader. I've also tried
to change UseRenderedShaders = true, to UseRenderedShaders = false, since
it could be that somehow the shader responsible for the refraction on the
water layer wouldn't show when navigating through them. (I've paid close
attention to every single shader number also by the way).
The odd thing is, that when starting up the game, loading the level, when
standing by the water, there are an equal amount of vertex shaders (81),
even when setting UseRenderedShaders to "false".
Commenting out different parts of the code doesn't work, since generel
disabling won't work. Maybe they don't necessarily co-exist.
So I don't know. Maybe I'm just tired in my head, or something odd is
happening, say some kind of a bug/glitch that I have no control over. :(
Original code (shader file content) :
CAB : Lian Li Tyr X-2000B | PSU : Cooler Master V1200 (1200W) | MB : Asus Rampage IV Extreme ROG | CPU : INTELi7 3930K @ 4,5GHz | FAN : Noctua NH-D14 SE | GPU(s) : (Tri-SLI) EVGA Geforce GTX 980Ti SC+ ACX 2.0 | MEM : Corsair Vengeance DDR3 1600MHz (16GB) | SSD : OCZ Vertex 2 (120GB) | SSD(s) : Samsung EVO 850 Pro (2x500GB RAID0 | SSD : Kingston HyperX 3K (2x240GB RAID0, 1x120GB) | SSD : Samsung EVO 840 (1TB) | SCR : Eizo Flexscan SX2461WK (IPS/Editing) | SCR : Eizo Flexscan EV2736W (IPS/1440p/Gaming/Editing) | SCR : Wacom Cintiq Companion Hybrid (Photo Editing/Illustration/Drawing) | SCR : Asus ROG Swift PG278Q (1440p/144Hz/G-Sync/3DV 2/Gaming) | SCR : Asus PB287Q (4K Gaming/DAW) | SCR/TV : Philips 55" PUS9109/12 UHD (4K Gaming) | NAS : QNAP TS-419PII /w Lian Li EX-503B Drive Bay | HID : (Keyboard) Corsair K95 RGB Brown Cherry (Mouse) Corsair M95 Performance & Generic Logitech HID Devices | NIC : Asus RT-AC66U (with Asus repeaters| NIC : Jensen Scandinavia 8-port Gigabit switch | SYS : NVIDIA SHIELD Portable | SYS : NVIDIA SHIELD Tablet (16 GB version/non-LTE) | Oculus Rift DK2
The shader hunting is sometimes really hard and not clear, because games do all sorts of wacky stuff with them. As an example, the shader for lava in Lesson 6 is not at all obvious, because the whole room goes dark except for the fire and lava fountains. The room goes dark because the Lava itself is the source of the light in the room, so by killing the lava, we've killed the primary light.
This water looks to be one of those cases where it's doing something really weird.
For your shader there, that won't be the right one, because the outputs don't match the inputs to the PixelShader associated with the effect. The PixelShader can't do anything standalone, it needs data input as the vertices+triangles to paint its textures upon.
So, with no match on the output, not even a partial match, this can't be the right one. It's possible to have a partial match, but the VertexShader outputs would need to be a superset of the PixelShader inputs. So, for example, the VS might have extra texcoord outputs that don't show in the PS, but it must at least provide all inputs used by the PS, otherwise the PS would have undefined data and produce random results.
The other clue there that this is not the right shader is the BoneMatrices matrix. I wouldn't expect you to know this, but that is almost always used for creatures, as a matrix hooking together arms and legs and teeth and stuff. Most likely this shader is for the worm itself.
To use the alternate approach of looking through dumps for the VS, you can expect your search criteria to include other inputs to the PS. So, texcoord5 is the one that affects it, but we can also require that texcoord4 and texcoord6 be output from the VS too. That will shrink the list. But maybe not enough.
The last thing that comes to mind is to try to go through all the ones that make the screen go black. So go ahead and mark those and move them to ShaderOverride and make them active for experiments. In general full black screen shaders are something else, but if this is like the lava effect, it could make it fully dark.
Both are water/liquid type effects with multiple layers, and the game makers tend to re-use their code, so finding something similar to the lava VS is the most likely approach.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
CAB : Lian Li Tyr X-2000B | PSU : Cooler Master V1200 (1200W) | MB : Asus Rampage IV Extreme ROG | CPU : INTELi7 3930K @ 4,5GHz | FAN : Noctua NH-D14 SE | GPU(s) : (Tri-SLI) EVGA Geforce GTX 980Ti SC+ ACX 2.0 | MEM : Corsair Vengeance DDR3 1600MHz (16GB) | SSD : OCZ Vertex 2 (120GB) | SSD(s) : Samsung EVO 850 Pro (2x500GB RAID0 | SSD : Kingston HyperX 3K (2x240GB RAID0, 1x120GB) | SSD : Samsung EVO 840 (1TB) | SCR : Eizo Flexscan SX2461WK (IPS/Editing) | SCR : Eizo Flexscan EV2736W (IPS/1440p/Gaming/Editing) | SCR : Wacom Cintiq Companion Hybrid (Photo Editing/Illustration/Drawing) | SCR : Asus ROG Swift PG278Q (1440p/144Hz/G-Sync/3DV 2/Gaming) | SCR : Asus PB287Q (4K Gaming/DAW) | SCR/TV : Philips 55" PUS9109/12 UHD (4K Gaming) | NAS : QNAP TS-419PII /w Lian Li EX-503B Drive Bay | HID : (Keyboard) Corsair K95 RGB Brown Cherry (Mouse) Corsair M95 Performance & Generic Logitech HID Devices | NIC : Asus RT-AC66U (with Asus repeaters| NIC : Jensen Scandinavia 8-port Gigabit switch | SYS : NVIDIA SHIELD Portable | SYS : NVIDIA SHIELD Tablet (16 GB version/non-LTE) | Oculus Rift DK2
I may have sand-bagged you there with that water shader, it seems much harder than I would have thought given the rest of the game.
If you want a simpler variant, take a look at the oil shader in the lava+bomb room. I know for sure that one can be solved.
The water one is less clear if we can solve it. I've looked a bit, and will take a close look soon. The primary problem is that the water surface is at the wrong depth. It looks like refraction because of the transparency, but the actual problem is it's at the wrong depth in 3D.
The reason I think that is because if you look at where the water hits the stairs, you can see it diverge on both left and right, get wider as it goes into the water. If it were refraction, we'd expect the angle to change, but not the width. That's our .x parameter being widened on both left and right eyes, which is exactly what we'd do to add depth. If you look at it carefully, you can see it's at the wrong depth relative to the stairs. If you stare directly into water and nothing else, it actually looks OK.
Thus, if we can shrink its .x location, we can make it line back up. Not sure of course, but that is presently my best guess. Good luck!
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
I only found it because I edited all of the vertex shaders currently on the screen at once, since I couldn't locate it via cycling.
fixed reflections:
Because of the stuff like this, I think that dumping all of the shaders & having a script to mass edit them all at once seems like the way to go.
Dual boot Win 7 x64 & Win 10 (1809) | Geforce Drivers 417.35
EDIT.
Never mind what I wrote about nothing happening on the screen. I noticed on your screenshot that it was the vs number 40, so I tried to disable it and I couldn't notice any color fluctuations. I forgot that "UseRenderedShaders = true" will change the amount of shaders based on what is happening in the scene at a specific point in time. The currently active shaders :) I fired it up again, and noticed the changes on screen. A2E7F5BC was number 64 at my current location. Ahhh, still fresh in the learning curve.
So I've skipped that shader previously since there was no change on screen, except the color fluctuations, so I would never have thought that could be the shader associated with the water.
But what did happen was that when I disabled that shader, and looked around, aimed at a different surface, the whole game crashed! Very strange. I'm very new at this, so I don't know anything about the script you're using. Would you mind telling me how it works? Sounds interesting.
CAB : Lian Li Tyr X-2000B | PSU : Cooler Master V1200 (1200W) | MB : Asus Rampage IV Extreme ROG | CPU : INTELi7 3930K @ 4,5GHz | FAN : Noctua NH-D14 SE | GPU(s) : (Tri-SLI) EVGA Geforce GTX 980Ti SC+ ACX 2.0 | MEM : Corsair Vengeance DDR3 1600MHz (16GB) | SSD : OCZ Vertex 2 (120GB) | SSD(s) : Samsung EVO 850 Pro (2x500GB RAID0 | SSD : Kingston HyperX 3K (2x240GB RAID0, 1x120GB) | SSD : Samsung EVO 840 (1TB) | SCR : Eizo Flexscan SX2461WK (IPS/Editing) | SCR : Eizo Flexscan EV2736W (IPS/1440p/Gaming/Editing) | SCR : Wacom Cintiq Companion Hybrid (Photo Editing/Illustration/Drawing) | SCR : Asus ROG Swift PG278Q (1440p/144Hz/G-Sync/3DV 2/Gaming) | SCR : Asus PB287Q (4K Gaming/DAW) | SCR/TV : Philips 55" PUS9109/12 UHD (4K Gaming) | NAS : QNAP TS-419PII /w Lian Li EX-503B Drive Bay | HID : (Keyboard) Corsair K95 RGB Brown Cherry (Mouse) Corsair M95 Performance & Generic Logitech HID Devices | NIC : Asus RT-AC66U (with Asus repeaters| NIC : Jensen Scandinavia 8-port Gigabit switch | SYS : NVIDIA SHIELD Portable | SYS : NVIDIA SHIELD Tablet (16 GB version/non-LTE) | Oculus Rift DK2