@4everAwake:
I was able to use 3dmigoto with The Golf Club. I played it on Win7 64bit and used the version for debugging either Watch Dogs or CoD Ghosts (sorry, can't remember :( ). I just wanted to see if there is a simple way to disable disturbing shadows but it turned out that I had to disable so many shaders that the game would have become extremly uggly and almost unplayable. Besides from that it uses the Unity engine which is said to be very hard to fix. So I deinstalled the game...
@4everAwake:
I was able to use 3dmigoto with The Golf Club. I played it on Win7 64bit and used the version for debugging either Watch Dogs or CoD Ghosts (sorry, can't remember :( ). I just wanted to see if there is a simple way to disable disturbing shadows but it turned out that I had to disable so many shaders that the game would have become extremly uggly and almost unplayable. Besides from that it uses the Unity engine which is said to be very hard to fix. So I deinstalled the game...
My original display name is 3d4dd - for some reason Nvidia changed it..?!
[quote="DHR"]Suppose you try this also:
[code]o0.x += stereo.x * 0.9;[/code]
You can change the 0.9 value from any between 0 - 1
Also delete the .BIN file related to that fixed shader in ShaderCache and ShaderFixed (just in case). Fixing AC Liberation one fix don't applies because i have .BIN file in ShaderCache (the wrapper override with the .BIN)
[/quote]
Tried that too, absolutely no change whatsoever. And my shaderfixes folder doesn't have any .bin files, I've disabled caching.
You can change the 0.9 value from any between 0 - 1
Also delete the .BIN file related to that fixed shader in ShaderCache and ShaderFixed (just in case). Fixing AC Liberation one fix don't applies because i have .BIN file in ShaderCache (the wrapper override with the .BIN)
Tried that too, absolutely no change whatsoever. And my shaderfixes folder doesn't have any .bin files, I've disabled caching.
[quote="3d4dd"]@4everAwake:
I was able to use 3dmigoto with The Golf Club. I played it on Win7 64bit and used the version for debugging either Watch Dogs or CoD Ghosts (sorry, can't remember :( ). I just wanted to see if there is a simple way to disable disturbing shadows but it turned out that I had to disable so many shaders that the game would have become extremly uggly and almost unplayable. Besides from that it uses the Unity engine which is said to be very hard to fix. So I deinstalled the game...[/quote]Ah! That's the answer there, the game is x64, which means that the 0.77 x32 version of 3Dmigoto won't load.
Microsoft does not give me any way to package both x64 and x32 in the same code base because the filename 'd3d11.dll' has to be the same for both.
I think what I'll do is to package both x64 and x32 versions in the same zip file, so you can choose which to install, and that will keep them both at the same revision. I'll change the build process to generate this tomorrow.
3d4dd said:@4everAwake:
I was able to use 3dmigoto with The Golf Club. I played it on Win7 64bit and used the version for debugging either Watch Dogs or CoD Ghosts (sorry, can't remember :( ). I just wanted to see if there is a simple way to disable disturbing shadows but it turned out that I had to disable so many shaders that the game would have become extremly uggly and almost unplayable. Besides from that it uses the Unity engine which is said to be very hard to fix. So I deinstalled the game...
Ah! That's the answer there, the game is x64, which means that the 0.77 x32 version of 3Dmigoto won't load.
Microsoft does not give me any way to package both x64 and x32 in the same code base because the filename 'd3d11.dll' has to be the same for both.
I think what I'll do is to package both x64 and x32 versions in the same zip file, so you can choose which to install, and that will keep them both at the same revision. I'll change the build process to generate this tomorrow.
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
[quote="ForgottenProdigy"]After countless hours I've given up on saints row for now, and am trying to fix sniper elite 3 which now opens with the 0.77 version. [/quote]Sorry to hear that, no question that SR is a weird beast. If it's any consolation, that was my go-to game for the past year while learning, and I ultimately took Mike's fix because I could not decipher it. Learned a lot, but never did find the fix.
[quote="ForgottenProdigy"]I checked that it reloads properly by disabling it first and that worked. Also I've noticed it makes sounds when saving fixes and reloading. If that's intentional, it's a pretty cool feature especially the sound notifying that the shaderfix is already in the folder.[/quote]Yep, I made that on purpose. I don't like the silent fail nature of HelixMod, so I wanted to make this more clear when it succeeds or fails. It also only compiles shaders that you've modified, by time stamp, so that it's fast.
If people have other suggestions or 3Dmigoto, don't hesitate to let me know. I want to build whatever works for people.
ForgottenProdigy said:After countless hours I've given up on saints row for now, and am trying to fix sniper elite 3 which now opens with the 0.77 version.
Sorry to hear that, no question that SR is a weird beast. If it's any consolation, that was my go-to game for the past year while learning, and I ultimately took Mike's fix because I could not decipher it. Learned a lot, but never did find the fix.
ForgottenProdigy said:I checked that it reloads properly by disabling it first and that worked. Also I've noticed it makes sounds when saving fixes and reloading. If that's intentional, it's a pretty cool feature especially the sound notifying that the shaderfix is already in the folder.
Yep, I made that on purpose. I don't like the silent fail nature of HelixMod, so I wanted to make this more clear when it succeeds or fails. It also only compiles shaders that you've modified, by time stamp, so that it's fast.
If people have other suggestions or 3Dmigoto, don't hesitate to let me know. I want to build whatever works for people.
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
[quote="ForgottenProdigy"]This does have 2 pixel shaders that affect it so could the problem lie there? There's this one which I feel like is part of the problem:
[code]SamplerState g_xTrilinearWrap_s : register(s2);
Texture2D<float4> g_xTransparencyMap : register(t7);
Texture2D<float4> StereoParams : register(t125);
void main(
float4 v0 : SV_Position0,
float2 v1 : TEXCOORD0,
out float4 o0 : SV_Target0)
{
float4 r0;
uint4 bitmask;
r0.xyzw = g_xTransparencyMap.Sample(g_xTrilinearWrap_s, v1.xy).xyzw;
r0.x = -1.960784346e-001 + r0.w;
r0.x = r0.x < 0.000000000e+000;
if (r0.x != 0) discard;
o0.xyzw = float4(1.000000e+000,1.000000e+000,1.000000e+000,1.000000e+000);
return;
}[/code]
The [code]if r0.x != 0[/code]
part in particular. I think that it throws away any values of the separation other than nothing which is why modifying the vertex shader does nothing (as I'm assuming pixel shader takes over the vertex shader values as the vertex shader exports SV_Position0 and the pixel shader imports it). However with my limited knowledge I don't know how to go about fixing this.
Here are the 2 pixel shaders and 1 vertex shader that is responsible for the lightning if you want to take a look at it.
https://www.mediafire.com/folder/txcse5vjwecwm/Documents[/quote]I'm not certain, but I think what is happening here is that the fire is actually a 2D effect.
That sequence you show there is not discarding the shader based on separation. The game doesn't know that it is 3D, as it's running in automatic mode, and thus the x parameter there is something else.
Also that instruction "r0.x = r0.x < 0.000000000e+000;" is making a boolean compare of x<0, and assigning that true/false to r0.x. The next "if (r0.x != 0) discard;" is then just checking true/false for whether to discard. So, really, the code is discarding if x<0.
The last line, when it's not discarded is also just setting the output to all ones instead.
The SV_Target0 is the same thing as COLOR in this case, so a better way to see that would be:
[code]o0.rgba = float4(1.000000e+000,1.000000e+000,1.000000e+000,1.000000e+000);[/code]
So, that's clearing all transparency, and making it fully white, or at least all bits set. This is probably a mask operation. Also confirmed by the use of g_xTransparencyMap. Assuming that's true, this will be unrelated to the problem.
This looks like some sort of threshhold sampler to decide whether to show pixels or not, probably a dynamic mask to make the fire flicker.
ForgottenProdigy said:This does have 2 pixel shaders that affect it so could the problem lie there? There's this one which I feel like is part of the problem:
part in particular. I think that it throws away any values of the separation other than nothing which is why modifying the vertex shader does nothing (as I'm assuming pixel shader takes over the vertex shader values as the vertex shader exports SV_Position0 and the pixel shader imports it). However with my limited knowledge I don't know how to go about fixing this.
Here are the 2 pixel shaders and 1 vertex shader that is responsible for the lightning if you want to take a look at it.
https://www.mediafire.com/folder/txcse5vjwecwm/Documents
I'm not certain, but I think what is happening here is that the fire is actually a 2D effect.
That sequence you show there is not discarding the shader based on separation. The game doesn't know that it is 3D, as it's running in automatic mode, and thus the x parameter there is something else.
Also that instruction "r0.x = r0.x < 0.000000000e+000;" is making a boolean compare of x<0, and assigning that true/false to r0.x. The next "if (r0.x != 0) discard;" is then just checking true/false for whether to discard. So, really, the code is discarding if x<0.
The last line, when it's not discarded is also just setting the output to all ones instead.
The SV_Target0 is the same thing as COLOR in this case, so a better way to see that would be:
So, that's clearing all transparency, and making it fully white, or at least all bits set. This is probably a mask operation. Also confirmed by the use of g_xTransparencyMap. Assuming that's true, this will be unrelated to the problem.
This looks like some sort of threshhold sampler to decide whether to show pixels or not, probably a dynamic mask to make the fire flicker.
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'll take another look at the other shaders and get back to you later today. [s]My initial reaction is that this shader looks to be a strictly 2D effect, which would make it not fixable.[/s]
Edit: actually that's probably not right. It's most likely deferred rendering.
I'll take another look at the other shaders and get back to you later today. My initial reaction is that this shader looks to be a strictly 2D effect, which would make it not fixable.
Edit: actually that's probably not right. It's most likely deferred rendering.
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
Please keep in mind that I'm not really expert here, so I could easily be wrong...
[s]As I noted before, I'm sorry to say, but I think this effect is entirely 2D. When I see this:[/s]
[code]void main(
float4 v0 : SV_Position0,
out float4 o0 : SV_Target0)
{
float4 r0,r1,r2,r3,r4,r5,r6,r7,r8,r9;
uint4 bitmask;
r0.xy = (int2)v0.xy;
r0.zw = float2(0.000000e+000,0.000000e+000);
...
[/code]
You see that it only uses as input from the Position variable the x,y. That's consistent for screen images, but with no depth, it can only be at screen depth.
Also I see in the ASM section:
[code]// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_Position 0 xyzw 0 POS float xy
[/code]
Which confirms that it only uses the xy of the float4 passed in. And I see math in other parts of that shader that only decides on an x,y which would be consistent with matching to pixels on screen, not anything in the 3D model of the world.
[s]It's fairly rare to have a strictly 2D effect, but it happens, especially on older game engines.
[/s]
If I'm right about it being a 2D effect, that will mean that even if we can move it to depth, it will look like a carboard cutout. Maybe that's better than nothing though.
To try moving it to depth, the only thing I think you can do would be to move the x being used to sample the texture used for the fire effect. In a given texture, the x,y is sampled across the surface of the texture to show given pixels, so if we move the x we'll get a different part of the texture to start, which can add depth. (pretty sure, haven't tried this myself, just read about it.)
So in this case, try changing the x at input to the pixel shader. Try doing some part of the maximum depth for x, to see if it moves at all. Like:
[code]void main(
float4 v0 : SV_Position0,
out float4 o0 : SV_Target0)
{
float4 r0,r1,r2,r3,r4,r5,r6,r7,r8,r9;
uint4 bitmask;
// r0.xy = (int2)v0.xy;
// Try accessing different part of texture to fake depth.
input.xy = (int2)v0.xy;
float4 stereo = StereoParams.Load(0);
input.x += stereo.x * (0.5);
r0.xy = input.xy;
r0.zw = float2(0.000000e+000,0.000000e+000);
...
[/code]
Good luck! And thanks again for taking a look at some of these other games.
Edit: I'm quite a bit less sure that this is 2D effect. Probably this is just normal deferred rendering. More detail below.
You see that it only uses as input from the Position variable the x,y. That's consistent for screen images, but with no depth, it can only be at screen depth.
Also I see in the ASM section:
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_Position 0 xyzw 0 POS float xy
Which confirms that it only uses the xy of the float4 passed in. And I see math in other parts of that shader that only decides on an x,y which would be consistent with matching to pixels on screen, not anything in the 3D model of the world.
It's fairly rare to have a strictly 2D effect, but it happens, especially on older game engines.
If I'm right about it being a 2D effect, that will mean that even if we can move it to depth, it will look like a carboard cutout. Maybe that's better than nothing though.
To try moving it to depth, the only thing I think you can do would be to move the x being used to sample the texture used for the fire effect. In a given texture, the x,y is sampled across the surface of the texture to show given pixels, so if we move the x we'll get a different part of the texture to start, which can add depth. (pretty sure, haven't tried this myself, just read about it.)
So in this case, try changing the x at input to the pixel shader. Try doing some part of the maximum depth for x, to see if it moves at all. Like:
void main(
float4 v0 : SV_Position0,
out float4 o0 : SV_Target0)
{
float4 r0,r1,r2,r3,r4,r5,r6,r7,r8,r9;
uint4 bitmask;
// r0.xy = (int2)v0.xy;
// Try accessing different part of texture to fake depth.
input.xy = (int2)v0.xy;
float4 stereo = StereoParams.Load(0);
input.x += stereo.x * (0.5);
r0.xy = input.xy;
r0.zw = float2(0.000000e+000,0.000000e+000);
...
Good luck! And thanks again for taking a look at some of these other games.
Edit: I'm quite a bit less sure that this is 2D effect. Probably this is just normal deferred rendering. More detail below.
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
@bo3b @DHR
I tried both of your suggestions and the texture just stays identical. Wouldn't move a centimeter. Well at least I've learned a bunch of things so something good came out of it.
@bo3b @DHR
I tried both of your suggestions and the texture just stays identical. Wouldn't move a centimeter. Well at least I've learned a bunch of things so something good came out of it.
Let me back up some here (and I edited the above posts to reflect my uncertainty). I'm not at all sure this is a 2D effect. This level of fix is presently beyond my skill level, so I'm pretty much guessing here based on what I know of other fixes.
The part that is confusing me is that the VS creates an xy coordinate on its output. That looks like 2D, but could also easily be the screen pixel/fragment location. Normally that xy is calculated in the PS, but I'd guess there is no requirement that that be done.
If that's true, then the fix would be the same as for any other deferred rendering glitch. Also worth noting that fixing deferred rendering glitches is the very hardest fix to make, you are a jedi-master once you fix these without an example.
Here's what I know for deferred rendering fix.
You start with the on screen fragment/pixel location of xy, then you need to unproject that xy back into the 3D scene to get the z location (and w by inversion). We need that, because in order to stereoize an output, we need to stereoize the original 3D space location, in View space. (not positive, maybe ViewProj space)
Then, once that location/position has been stereoized, we reproject that location back to screen space, and finish whatever work it needs to, based on the adjusted fragment/pixel location.
There are numerous examples of this being done, but they are all subtly different, which makes it hard to find an example.
In this case, your pixel shader 5db426686b596f4a-ps_replace.txt, has the information you'd need to deproject. Pretty sure, not expert here of course.
I'm not clear to me on whether this needs to be the InvView, or InvViewProj to get to the right model space. But trying both would not be terrible.
So the idea would be to do this on input:
1) run the x,y input coordinate through that InvViewProj to back to model space.
2) Use the stereoize formula on that position.
3) run the x,y,z,w back through the ViewProj matrix to get back to screen space.
Hope that helps. As noted, I'm not quite there with this type of fix.
Edit: I also notice that it already deprojects back to View space at:
[quote="bo3b"]Let me back up some here (and I edited the above posts to reflect my uncertainty). I'm not at all sure this is a 2D effect. This level of fix is presently beyond my skill level, so I'm pretty much guessing here based on what I know of other fixes.
The part that is confusing me is that the VS creates an xy coordinate on its output. That looks like 2D, but could also easily be the screen pixel/fragment location. Normally that xy is calculated in the PS, but I'd guess there is no requirement that that be done.
If that's true, then the fix would be the same as for any other deferred rendering glitch. Also worth noting that fixing deferred rendering glitches is the very hardest fix to make, you are a jedi-master once you fix these without an example.
Here's what I know for deferred rendering fix.
You start with the on screen fragment/pixel location of xy, then you need to [i]unproject[/i] that xy back into the 3D scene to get the z location (and w by inversion). We need that, because in order to stereoize an output, we need to stereoize the original 3D space location, in View space. (not positive, maybe ViewProj space)
Then, once that location/position has been stereoized, we [i]reproject [/i]that location back to screen space, and finish whatever work it needs to, based on the adjusted fragment/pixel location.
There are numerous examples of this being done, but they are all subtly different, which makes it hard to find an example.
In this case, your pixel shader 5db426686b596f4a-ps_replace.txt, has the information you'd need to deproject. Pretty sure, not expert here of course.
[code]// campfire
cbuffer FrameConstants : register(b0)
{
float4x4 g_xView : packoffset(c0);
float4x4 g_xProj : packoffset(c4);
float4x4 g_xViewProj : packoffset(c8);
float4x4 g_xInvView : packoffset(c12);
float4x4 g_xInvProj : packoffset(c16);
float4x4 g_xInvViewProj : packoffset(c20);
float3 g_xCamPos : packoffset(c24);
float4 g_xTwoOverScreenDimensions : packoffset(c25);
float2 g_xCameraTanHalfFOV : packoffset(c26);
float2 g_xPadding : packoffset(c26.z);
float2 g_xRcpScreenDims : packoffset(c27);
float2 g_xDepthProjViewUnpack : packoffset(c27.z);
float4 g_axViewFrustumPlanes[6] : packoffset(c28);
int4 g_xScreenDimensions : packoffset(c34);
}
cbuffer ShadowReadConstants : register(b5)
{
float g_f2DFilterSize : packoffset(c0);
float g_fCubeFilterSize : packoffset(c0.y);
float g_fCubeClampWidth : packoffset(c0.z);
float g_fSunWidth : packoffset(c0.w);
}
cbuffer PointParams : register(b4)
{
float4x4 g_xLightOrientation : packoffset(c0);
float4x4 g_xCustomVolumeMatrix : packoffset(c4);
float4 g_xTwoOverScreenDims : packoffset(c8);
float2 g_xUnusedCameraTanHalfFOV : packoffset(c9);
float2 g_xDepthProjection : packoffset(c9.z);
float3 g_xLightPos : packoffset(c10);
float g_fLightRadius : packoffset(c10.w);
float3 g_xLightDir : packoffset(c11);
float g_fRcpLightRadius : packoffset(c11.w);
float3 g_xLightColour : packoffset(c12);
bool g_bUseLimitAngles : packoffset(c12.w);
float g_fLightFalloffScale : packoffset(c13);
float g_fLightFalloffPower : packoffset(c13.y);
float g_fLightAngleOuter : packoffset(c13.z);
float g_fRcpLightAngleRange : packoffset(c13.w);
float g_fArcCosLimitAngle : packoffset(c14);
float g_fRcpProjCubeLerpDist : packoffset(c14.y);
bool g_bUseProjCube : packoffset(c14.z);
bool g_bUseDualProjCube : packoffset(c14.w);
float g_fLightMeshRadius : packoffset(c15);
float g_fShadowStrength : packoffset(c15.y);
}
SamplerState g_xTrilinearClamp_s : register(s3);
SamplerComparisonState g_xShadowCmpSampler_s : register(s8);
Texture2D<float4> g_xMaterialsTexture : register(t0);
Texture2D<float4> g_xNormalBuffer : register(t26);
Texture2D<float4> g_xAlbedoBuffer : register(t27);
TextureCube<float4> g_xProjCubeMap : register(t28);
TextureCube<float4> g_xProjCubeMapBlurred : register(t29);
Texture2D<float4> g_xShadowCubeMap : register(t30);
Texture2D<float4> StereoParams : register(t125);
void main(
float4 v0 : SV_Position0,
out float4 o0 : SV_Target0)
{
float4 r0,r1,r2,r3,r4,r5,r6,r7,r8,r9;
uint4 bitmask;
r0.xy = (int2)v0.xy;
r0.zw = float2(0.000000e+000,0.000000e+000);
r1.xyzw = g_xNormalBuffer.Load(r0.xyw).xyzw;
r0.xyzw = g_xAlbedoBuffer.Load(r0.xyz).xyzw;
r2.x = dot(r1.xy, r1.xy);
r3.z = r2.x * 2.000000000e+000 + -1.000000000e+000;
r2.x = rsqrt(r2.x);
r1.xy = r2.xx * r1.xy;
r2.x = -r3.z * r3.z + 1.000000000e+000;
r2.x = max(r2.x, 0.000000000e+000);
r2.x = sqrt(r2.x);
r3.xy = r2.xx * r1.xy;
r1.xy = g_xCameraTanHalfFOV.xy * r1.ww;
r2.xy = g_xTwoOverScreenDims.zw + v0.xy;
r2.xy = r2.xy * g_xTwoOverScreenDims.xy + float2(-1.000000e+000,-1.000000e+000);
r1.xy = r2.xy * r1.xy;
r2.xyz = g_xInvView._m01_m11_m21 * r1.yyy;
r2.xyz = g_xInvView._m00_m10_m20 * r1.xxx + r2.xyz;
r1.xyw = g_xInvView._m02_m12_m22 * r1.www + r2.xyz;
r1.xyw = g_xInvView._m03_m13_m23 + r1.xyw;
r2.xyz = g_xLightPos.xyz + -r1.xyw;
r2.w = dot(r2.xyz, r2.xyz);
r3.w = rsqrt(r2.w);
r4.xyz = r3.www * r2.xyz;
r2.w = sqrt(r2.w);
r3.w = g_fRcpLightRadius * r2.w;
r4.w = -r2.w * g_fRcpLightRadius + 1.000000000e+000;
r4.w = saturate(g_fLightFalloffScale * r4.w);
r4.w = log2(r4.w);
r4.w = g_fLightFalloffPower * r4.w;
r4.w = exp2(r4.w);
r5.x = dot(r4.xyz, g_xLightDir.xyz);
r5.x = g_fLightAngleOuter + r5.x;
r5.x = saturate(g_fRcpLightAngleRange * r5.x);
r5.x = r5.x * r4.w;
r4.w = g_bUseLimitAngles ? r5.x : r4.w;
r5.x = -9.999999747e-005 + r4.w;
r5.x = r5.x < 0.000000000e+000;
if (r5.x != 0) discard;
r5.x = 0.000000000e+000 < g_fShadowStrength;
if (r5.x != 0) {
r5.xyz = float3(-1.000000e+000,1.000000e+000,-1.000000e+000) * r2.xyz;
r5.w = max(abs(r5.z), abs(r5.y));
r5.w = max(r5.w, abs(r5.x));
r6.x = abs(r5.x) == r5.w;
r6.y = abs(r5.y) == r5.w;
r6.z = abs(r5.z) == r5.w;
r7.x = r6.x ? 1 : 0;
r7.y = r6.y ? 1 : 0;
r7.z = r6.z ? 1 : 0;
r6.z = dot(r7.xyz, r5.xyz);
r6.w = 0.000000000e+000 < r6.z;
r6.z = r6.z < 0.000000000e+000;
r6.z = ((int)r6.z ? -1 : 0) + ((int)r6.w ? 1 : 0);
r6.z = r6.z;
r8.x = saturate(-r6.z);
r8.y = dot(r7.zy, float2(2.000000e+000,1.000000e+000));
r7.xyzw = float4(1.000000e+000,0.000000e+000,0.000000e+000,-1.000000e+000) * r6.zzzz;
r6.z = r6.y ? 1 : r7.x;
r6.w = r6.y ? 0 : r7.y;
r7.x = r6.y ? r7.y : -1;
r7.y = r6.y ? r7.x : 0;
r6.y = r6.x ? r7.z : r6.z;
r6.z = r6.x ? r7.w : r6.w;
r6.x = r6.x ? -1 : r7.x;
r6.w = r6.x ? 0 : r7.y;
r5.xyz = r5.xyz / r5.www;
r7.x = dot(r6.yz, r5.xz);
r7.y = dot(r6.xw, r5.yz);
r5.xy = r7.xy * float2(5.000000e-001,5.000000e-001) + float2(5.000000e-001,5.000000e-001);
r5.z = g_xDepthProjection.y / r5.w;
r5.z = g_xDepthProjection.x + r5.z;
r5.w = 1.000000000e+000 + -g_fCubeClampWidth;
r5.xy = max(r5.xy, g_fCubeClampWidth);
r5.xy = min(r5.ww, r5.xy);
r5.xy = r5.xy + r8.xy;
r5.xy = float2(5.000000e-001,3.333333e-001) * r5.xy;
r5.x = g_xShadowCubeMap.SampleCmp(g_xShadowCmpSampler_s, r5.xy, r5.z).x;
r5.yz = float2(0.000000e+000,0.000000e+000);
while (true) {
r5.w = (int)r5.z >= (int)12;
if (r5.w != 0) break;
r5.y = r5.y + r5.x;
r5.z = (int)r5.z + 1;
}
r5.x = g_fShadowStrength * r5.y;
o0.w = -r5.x * 8.333333582e-002 + 1.000000000e+000;
} else {
o0.w = 1.000000000e+000;
}
r5.xyz = g_xLightColour.xyz * r4.www;
if (g_bUseProjCube != 0) {
r6.x = dot(r4.xyz, g_xLightOrientation._m00_m10_m20);
r6.y = dot(r4.xyz, g_xLightOrientation._m01_m11_m21);
r6.z = dot(r4.xyz, g_xLightOrientation._m02_m12_m22);
r4.xyzw = g_xProjCubeMap.Sample(g_xTrilinearClamp_s, r6.xyz).xyzw;
if (g_bUseDualProjCube != 0) {
r6.xyzw = g_xProjCubeMapBlurred.Sample(g_xTrilinearClamp_s, r6.xyz).xyzw;
r3.w = g_fRcpProjCubeLerpDist * r3.w;
r3.w = min(r3.w, 1.000000000e+000);
r6.xyz = r6.xyz + -r4.xyz;
r4.xyz = r3.www * r6.xyz + r4.xyz;
}
r5.xyz = r5.xyz * r4.xyz;
}
r1.xyw = g_xCamPos.xyz + -r1.xyw;
r3.w = dot(r1.xyw, r1.xyw);
r3.w = rsqrt(r3.w);
r4.xyz = r3.www * r1.xyw;
r2.xyz = r2.xyz / r2.www;
r2.w = dot(r5.xyz, float3(3.330000e-001,3.330000e-001,3.330000e-001));
r4.w = dot(r3.xyz, r2.xyz);
r6.x = 9.980468750e-001;
r6.y = r0.w;
r6.xyzw = g_xMaterialsTexture.Sample(g_xTrilinearClamp_s, r6.xy).xyzw;
r6.zw = r6.zw + r6.zw;
r0.w = max(r4.w, 0.000000000e+000);
r5.w = min(r0.w, 1.000000000e+000);
r7.x = 3.750000e-001 < r6.y;
r7.y = 1.250000e-001 < r6.y;
r8.xyz = saturate(r4.www * float3(8.000000e-001,9.000000e-001,1.000000e+000) + float3(2.000000e-001,1.000000e-001,0.000000e+000));
r8.xyz = r8.xyz * r8.xyz;
r6.y = abs(r4.w) * 6.000000238e-001 + 4.000000060e-001;
r6.y = min(r6.y, 1.000000000e+000);
r7.z = saturate(dot(r2.xyz, -r4.xyz));
r9.xyz = r0.yyy * float3(9.000000e-001,1.000000e+000,2.000000e-001) + -r0.xyz;
r9.xyz = r7.zzz * r9.xyz + r0.xyz;
r8.x = r7.y ? r8.x : r6.y;
r8.y = r7.y ? r8.y : r6.y;
r8.z = r7.y ? r8.z : r6.y;
r6.y = (int)r7.x | (int)r7.y;
r7.y = r6.y ? r0.x : r9.x;
r7.z = r6.y ? r0.y : r9.y;
r7.w = r6.y ? r0.z : r9.z;
r8.x = r7.x ? r5.w : r8.x;
r8.y = r7.x ? r5.w : r8.y;
r8.z = r7.x ? r5.w : r8.z;
r7.xyz = r7.yzw * r5.xyz;
r0.xyz = r0.xyz * r2.www + -r5.xyz;
r0.xyz = r6.zzz * r0.xyz + r5.xyz;
r2.w = 2.560000000e+002 * r6.x;
r2.w = r2.w * r2.w;
r1.xyw = r1.xyw * r3.www + r2.xyz;
r2.x = dot(r1.xyw, r1.xyw);
r2.x = rsqrt(r2.x);
r1.xyw = r2.xxx * r1.xyw;
r1.x = dot(r3.xyz, r1.xyw);
r1.x = max(r1.x, 9.999999975e-007);
r1.x = log2(r1.x);
r1.x = r2.w * r1.x;
r1.x = exp2(r1.x);
r1.x = r2.w * r1.x;
r0.w = r1.x * r0.w;
r1.x = saturate(dot(r3.xyz, r4.xyz));
r1.y = 5.000000000e-001 + r4.w;
r1.y = max(r1.y, 0.000000000e+000);
r1.x = 1.000000000e+000 + -r1.x;
r1.w = r1.x * r1.x;
r1.w = r1.w * r1.w;
r1.x = r1.x * r1.w;
r1.x = r1.x * r6.w;
r1.x = r1.x * r1.y;
r1.x = 2.500000000e+000 * r1.x;
r0.w = r0.w * 3.125000000e-002 + r1.x;
r0.w = r0.w * r1.z;
r0.xyz = r0.xyz * r0.www;
r0.xyz = r8.xyz * r7.xyz + r0.xyz;
o0.xyz = min(r0.xyz, float3(3.199902e+001,3.199902e+001,3.199902e+001));
float4 stereo = StereoParams.Load(0);
//o0.x -= stereo.x * (o0.w - stereo.y);
//o0 = 0;
return;
}[/code]
The matrices are available:
[code] float4x4 g_xView : packoffset(c0);
float4x4 g_xProj : packoffset(c4);
float4x4 g_xViewProj : packoffset(c8);
float4x4 g_xInvView : packoffset(c12);
float4x4 g_xInvProj : packoffset(c16);
float4x4 g_xInvViewProj : packoffset(c20);
[/code]
I'm not clear to me on whether this needs to be the InvView, or InvViewProj to get to the right model space. But trying both would not be terrible.
So the idea would be to do this on input:
1) run the x,y input coordinate through that InvViewProj to back to model space.
2) Use the stereoize formula on that position.
3) run the x,y,z,w back through the ViewProj matrix to get back to screen space.
Hope that helps. As noted, I'm not quite there with this type of fix.
Edit: I also notice that it already deprojects back to View space at:
[code] r2.xyz = g_xInvView._m01_m11_m21 * r1.yyy;
r2.xyz = g_xInvView._m00_m10_m20 * r1.xxx + r2.xyz;
r1.xyw = g_xInvView._m02_m12_m22 * r1.www + r2.xyz;
r1.xyw = g_xInvView._m03_m13_m23 + r1.xyw;
[/code]
You might be able to sneak in there and steroize at that moment, if that's in the right model space.
[/quote]
Hi Bo3b, I have not followed all of this thread, but thought I'd throw out a few comments while I have a few minutes (my Masters course has now started, and I am quite literally swallowed up with the amount of stuff to do...). Corrections need to be made in either View space or Projection space i.e. one of the spaces representing the scene from the camera perspective. Whenever you see something like invView or invViewProj, those matrices will put you back in WORLD coordinates, which is not where you can make a correction. In your example above, you would actually look to stereoize BEFORE the matrix is applied i.e. stereoize the original r1 variable. That being said, this still might not be what you want to do in this shader, but if it is that is what you would do. Same with something that applies invViewProj. Note that the correction for these two cases is different:
View space: S*(-r.z - C) * P11 ; the important point here is that the z-comp is used
Proj Space: S*(r.w - C)
where:
r is the source coordinate
P11 is the (1,1) element of the projection matrix. Depending where you get this from you might use 1/P11
Sometimes the terminology "screen space" is used, and a warning is that this is not used consistently in shaders - *usually* its is proj space, but sometimes its view space. You need to try and work it out, for example based on what matrices get applied either to it, or to something else to get to it.
Sometimes (in fact often) in a Pixel Shader, you can get some form of 2D screen position but not necesarilly the correct depth to apply in the second form of the fix above. In these cases the shader may (usually) derive the World coordinate as part of its deferred algorithm e.g. a shadow map. In this case, to do the correction you forward project the World coord to Proj coords using "a VPM", make the stereo correction, then reverse transform it using the inverse VPM. The trouble with this approach is that you don't always (and often do not) have access to the VPM in the shader that needs fixing - but the Helix wrapper allows you to re-use VPMs from other shaders, and this then solves the problem.
I had previously suggested to you that putting this information up so early on in the course might cause more confusion than, but it seems some people are ploughing ahead anyway, so hopefully this helps - PM me if you'd like to go through it in a more structured way offline.
bo3b said:Let me back up some here (and I edited the above posts to reflect my uncertainty). I'm not at all sure this is a 2D effect. This level of fix is presently beyond my skill level, so I'm pretty much guessing here based on what I know of other fixes.
The part that is confusing me is that the VS creates an xy coordinate on its output. That looks like 2D, but could also easily be the screen pixel/fragment location. Normally that xy is calculated in the PS, but I'd guess there is no requirement that that be done.
If that's true, then the fix would be the same as for any other deferred rendering glitch. Also worth noting that fixing deferred rendering glitches is the very hardest fix to make, you are a jedi-master once you fix these without an example.
Here's what I know for deferred rendering fix.
You start with the on screen fragment/pixel location of xy, then you need to unproject that xy back into the 3D scene to get the z location (and w by inversion). We need that, because in order to stereoize an output, we need to stereoize the original 3D space location, in View space. (not positive, maybe ViewProj space)
Then, once that location/position has been stereoized, we reproject that location back to screen space, and finish whatever work it needs to, based on the adjusted fragment/pixel location.
There are numerous examples of this being done, but they are all subtly different, which makes it hard to find an example.
In this case, your pixel shader 5db426686b596f4a-ps_replace.txt, has the information you'd need to deproject. Pretty sure, not expert here of course.
I'm not clear to me on whether this needs to be the InvView, or InvViewProj to get to the right model space. But trying both would not be terrible.
So the idea would be to do this on input:
1) run the x,y input coordinate through that InvViewProj to back to model space.
2) Use the stereoize formula on that position.
3) run the x,y,z,w back through the ViewProj matrix to get back to screen space.
Hope that helps. As noted, I'm not quite there with this type of fix.
Edit: I also notice that it already deprojects back to View space at:
You might be able to sneak in there and steroize at that moment, if that's in the right model space.
Hi Bo3b, I have not followed all of this thread, but thought I'd throw out a few comments while I have a few minutes (my Masters course has now started, and I am quite literally swallowed up with the amount of stuff to do...). Corrections need to be made in either View space or Projection space i.e. one of the spaces representing the scene from the camera perspective. Whenever you see something like invView or invViewProj, those matrices will put you back in WORLD coordinates, which is not where you can make a correction. In your example above, you would actually look to stereoize BEFORE the matrix is applied i.e. stereoize the original r1 variable. That being said, this still might not be what you want to do in this shader, but if it is that is what you would do. Same with something that applies invViewProj. Note that the correction for these two cases is different:
View space: S*(-r.z - C) * P11 ; the important point here is that the z-comp is used
Proj Space: S*(r.w - C)
where:
r is the source coordinate
P11 is the (1,1) element of the projection matrix. Depending where you get this from you might use 1/P11
Sometimes the terminology "screen space" is used, and a warning is that this is not used consistently in shaders - *usually* its is proj space, but sometimes its view space. You need to try and work it out, for example based on what matrices get applied either to it, or to something else to get to it.
Sometimes (in fact often) in a Pixel Shader, you can get some form of 2D screen position but not necesarilly the correct depth to apply in the second form of the fix above. In these cases the shader may (usually) derive the World coordinate as part of its deferred algorithm e.g. a shadow map. In this case, to do the correction you forward project the World coord to Proj coords using "a VPM", make the stereo correction, then reverse transform it using the inverse VPM. The trouble with this approach is that you don't always (and often do not) have access to the VPM in the shader that needs fixing - but the Helix wrapper allows you to re-use VPMs from other shaders, and this then solves the problem.
I had previously suggested to you that putting this information up so early on in the course might cause more confusion than, but it seems some people are ploughing ahead anyway, so hopefully this helps - PM me if you'd like to go through it in a more structured way offline.
From my personal experience so far:
- I haven't tried doing anything with 3Dmigoto yet, but I did try with HelixMod.
- Finding a shader and dump it, disable it is not that hard. Problem is: you don't know if you found a correct shader until you actually try to fix it.
- I searched around HelixMod blog=>guides and here on the forums and I wasn't really able to find the information I was looking for:
[.]What are the patterns one should look for when trying to fix an effect (Shadows,lighting, etc)[/.]
[.]Where should different fixes be applied -> (Shadow fixing for example sometimes is done in VS or PS or both)[/.]
[.]How to fix an effect in a deferred rendering environment. Why is the unprojection necessary..[/.]
[.]...etc[/.]
(These are the things that come in my mind).
I did follow and watched the video in bo3b's School Shader class ^_^ and I know he didn't get this far to what I am asking above, but I think it would be very beneficial if in the future we could make a WIKI or guide with as much examples, tips&tricks as possible to help out a newb;))
- I know that each game/engine is different and use different techniques but I expect the fixing pattern to be the same, only the details matter;))
I already asked Mike_ar69 via PM and he gladly responded and helped me out with a lot of information so far, but I think it would be awesome if we could gather it all in one place so new people aren't frightened at the beginning from all this information;))
(I think I should have posted this in the other thread but here I think it makes much more sense;)))
- I haven't tried doing anything with 3Dmigoto yet, but I did try with HelixMod.
- Finding a shader and dump it, disable it is not that hard. Problem is: you don't know if you found a correct shader until you actually try to fix it.
- I searched around HelixMod blog=>guides and here on the forums and I wasn't really able to find the information I was looking for:
What are the patterns one should look for when trying to fix an effect (Shadows,lighting, etc)
Where should different fixes be applied -> (Shadow fixing for example sometimes is done in VS or PS or both)
How to fix an effect in a deferred rendering environment. Why is the unprojection necessary..
...etc
(These are the things that come in my mind).
I did follow and watched the video in bo3b's School Shader class ^_^ and I know he didn't get this far to what I am asking above, but I think it would be very beneficial if in the future we could make a WIKI or guide with as much examples, tips&tricks as possible to help out a newb;))
- I know that each game/engine is different and use different techniques but I expect the fixing pattern to be the same, only the details matter;))
I already asked Mike_ar69 via PM and he gladly responded and helped me out with a lot of information so far, but I think it would be awesome if we could gather it all in one place so new people aren't frightened at the beginning from all this information;))
(I think I should have posted this in the other thread but here I think it makes much more sense;)))
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
@Mike: Awesome writeup! Thanks for that.
For some reason I always thought that stereoization happened in World coordinates, but clearly that's wrong. That's gotta be a key part of my confusion on fixing deferred rendering.
@ForgottenProdigy: Based on Mike's suggestion it looks like the best spot to try to stereoize the effect is before the InvView:
[code]
r1.xy = r2.xy * r1.xy;
---> on r1
r2.xyz = g_xInvView._m01_m11_m21 * r1.yyy;
r2.xyz = g_xInvView._m00_m10_m20 * r1.xxx + r2.xyz;
r1.xyw = g_xInvView._m02_m12_m22 * r1.www + r2.xyz;
r1.xyw = g_xInvView._m03_m13_m23 + r1.xyw;
[/code]
For some reason I always thought that stereoization happened in World coordinates, but clearly that's wrong. That's gotta be a key part of my confusion on fixing deferred rendering.
@ForgottenProdigy: Based on Mike's suggestion it looks like the best spot to try to stereoize the effect is before the InvView:
Posted a new version of 3Dmigoto, 0.82. [url]https://github.com/bo3b/3Dmigoto/releases/tag/0.82-beta[/url]
No code changes from the 0.77 for x32, and 0.75 for x64, but in a more convenient and clear container.
This moves to a different release mode, where I'm combining both the x32 and x64 versions into a single zip, under their own folders. This way you can use whichever variant is necessary for a game.
Please use this version if you are starting any new research. If you are already in the middle of things, there is nothing here that would require an update.
No code changes from the 0.77 for x32, and 0.75 for x64, but in a more convenient and clear container.
This moves to a different release mode, where I'm combining both the x32 and x64 versions into a single zip, under their own folders. This way you can use whichever variant is necessary for a game.
Please use this version if you are starting any new research. If you are already in the middle of things, there is nothing here that would require an update.
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 sniper elite thing still didn't work so I'm putting that on a stall and trying out dead rising 3 when it turns out I can't reload the shaders. I get this error:
[code]> FAILED to reload shaders from ShaderFixes
> reloading *_replace.txt fixes from ShaderFixes
>Replacement shader found. Re-Loading replacement HLSL code from 29481e95a8a7faa4-vs_replace.txt
Reload source code loaded. Size = 3579
compiling replacement HLSL code with shader model vs_5_0
compile result of replacement HLSL shader: 80004005
--------------------------------------------- BEGIN ---------------------------------------------
G:\Artur\Dead Rising 3\wrapper1349(19,13): error X3000: syntax error: unexpected token '.'
G:\Artur\Dead Rising 3\wrapper1349(23,13): error X3000: syntax error: unexpected token '.'
G:\Artur\Dead Rising 3\wrapper1349(25,13): error X3000: syntax error: unexpected token '.'
---------------------------------------------- END ----------------------------------------------[/code]
and this
[code]> FAILED to reload shaders from ShaderFixes
> reloading *_replace.txt fixes from ShaderFixes
>Replacement shader found. Re-Loading replacement HLSL code from d6c0220914e5bfd2-vs_replace.txt
Reload source code loaded. Size = 0
compiling replacement HLSL code with shader model vs_5_0
compile result of replacement HLSL shader: 80004005
--------------------------------------------- BEGIN ---------------------------------------------
error X3501: 'main': entrypoint not found
---------------------------------------------- END ----------------------------------------------[/code]
Using the latest build (0.82).
The sniper elite thing still didn't work so I'm putting that on a stall and trying out dead rising 3 when it turns out I can't reload the shaders. I get this error:
> FAILED to reload shaders from ShaderFixes
> reloading *_replace.txt fixes from ShaderFixes
>Replacement shader found. Re-Loading replacement HLSL code from 29481e95a8a7faa4-vs_replace.txt
Reload source code loaded. Size = 3579
compiling replacement HLSL code with shader model vs_5_0
compile result of replacement HLSL shader: 80004005
--------------------------------------------- BEGIN ---------------------------------------------
G:\Artur\Dead Rising 3\wrapper1349(19,13): error X3000: syntax error: unexpected token '.'
G:\Artur\Dead Rising 3\wrapper1349(23,13): error X3000: syntax error: unexpected token '.'
G:\Artur\Dead Rising 3\wrapper1349(25,13): error X3000: syntax error: unexpected token '.'
---------------------------------------------- END ----------------------------------------------
and this
> FAILED to reload shaders from ShaderFixes
> reloading *_replace.txt fixes from ShaderFixes
>Replacement shader found. Re-Loading replacement HLSL code from d6c0220914e5bfd2-vs_replace.txt
Reload source code loaded. Size = 0
compiling replacement HLSL code with shader model vs_5_0
compile result of replacement HLSL shader: 80004005
--------------------------------------------- BEGIN ---------------------------------------------
error X3501: 'main': entrypoint not found
---------------------------------------------- END ----------------------------------------------
I was able to use 3dmigoto with The Golf Club. I played it on Win7 64bit and used the version for debugging either Watch Dogs or CoD Ghosts (sorry, can't remember :( ). I just wanted to see if there is a simple way to disable disturbing shadows but it turned out that I had to disable so many shaders that the game would have become extremly uggly and almost unplayable. Besides from that it uses the Unity engine which is said to be very hard to fix. So I deinstalled the game...
My original display name is 3d4dd - for some reason Nvidia changed it..?!
Tried that too, absolutely no change whatsoever. And my shaderfixes folder doesn't have any .bin files, I've disabled caching.
Microsoft does not give me any way to package both x64 and x32 in the same code base because the filename 'd3d11.dll' has to be the same for both.
I think what I'll do is to package both x64 and x32 versions in the same zip file, so you can choose which to install, and that will keep them both at the same revision. I'll change the build process to generate this tomorrow.
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
Yep, I made that on purpose. I don't like the silent fail nature of HelixMod, so I wanted to make this more clear when it succeeds or fails. It also only compiles shaders that you've modified, by time stamp, so that it's fast.
If people have other suggestions or 3Dmigoto, don't hesitate to let me know. I want to build whatever works for people.
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
That sequence you show there is not discarding the shader based on separation. The game doesn't know that it is 3D, as it's running in automatic mode, and thus the x parameter there is something else.
Also that instruction "r0.x = r0.x < 0.000000000e+000;" is making a boolean compare of x<0, and assigning that true/false to r0.x. The next "if (r0.x != 0) discard;" is then just checking true/false for whether to discard. So, really, the code is discarding if x<0.
The last line, when it's not discarded is also just setting the output to all ones instead.
The SV_Target0 is the same thing as COLOR in this case, so a better way to see that would be:
So, that's clearing all transparency, and making it fully white, or at least all bits set. This is probably a mask operation. Also confirmed by the use of g_xTransparencyMap. Assuming that's true, this will be unrelated to the problem.
This looks like some sort of threshhold sampler to decide whether to show pixels or not, probably a dynamic mask to make the fire flicker.
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
My initial reaction is that this shader looks to be a strictly 2D effect, which would make it not fixable.Edit: actually that's probably not right. It's most likely deferred rendering.
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
As I noted before, I'm sorry to say, but I think this effect is entirely 2D. When I see this:You see that it only uses as input from the Position variable the x,y. That's consistent for screen images, but with no depth, it can only be at screen depth.
Also I see in the ASM section:
Which confirms that it only uses the xy of the float4 passed in. And I see math in other parts of that shader that only decides on an x,y which would be consistent with matching to pixels on screen, not anything in the 3D model of the world.
It's fairly rare to have a strictly 2D effect, but it happens, especially on older game engines.
If I'm right about it being a 2D effect, that will mean that even if we can move it to depth, it will look like a carboard cutout. Maybe that's better than nothing though.
To try moving it to depth, the only thing I think you can do would be to move the x being used to sample the texture used for the fire effect. In a given texture, the x,y is sampled across the surface of the texture to show given pixels, so if we move the x we'll get a different part of the texture to start, which can add depth. (pretty sure, haven't tried this myself, just read about it.)
So in this case, try changing the x at input to the pixel shader. Try doing some part of the maximum depth for x, to see if it moves at all. Like:
Good luck! And thanks again for taking a look at some of these other games.
Edit: I'm quite a bit less sure that this is 2D effect. Probably this is just normal deferred rendering. More detail below.
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
Try if any of the 2 codes above works. Apply to VS.
in both cases i use a fix value, only if change something regard depth.
Option 1:
Option 2:
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
I tried both of your suggestions and the texture just stays identical. Wouldn't move a centimeter. Well at least I've learned a bunch of things so something good came out of it.
The part that is confusing me is that the VS creates an xy coordinate on its output. That looks like 2D, but could also easily be the screen pixel/fragment location. Normally that xy is calculated in the PS, but I'd guess there is no requirement that that be done.
If that's true, then the fix would be the same as for any other deferred rendering glitch. Also worth noting that fixing deferred rendering glitches is the very hardest fix to make, you are a jedi-master once you fix these without an example.
Here's what I know for deferred rendering fix.
You start with the on screen fragment/pixel location of xy, then you need to unproject that xy back into the 3D scene to get the z location (and w by inversion). We need that, because in order to stereoize an output, we need to stereoize the original 3D space location, in View space. (not positive, maybe ViewProj space)
Then, once that location/position has been stereoized, we reproject that location back to screen space, and finish whatever work it needs to, based on the adjusted fragment/pixel location.
There are numerous examples of this being done, but they are all subtly different, which makes it hard to find an example.
In this case, your pixel shader 5db426686b596f4a-ps_replace.txt, has the information you'd need to deproject. Pretty sure, not expert here of course.
The matrices are available:
I'm not clear to me on whether this needs to be the InvView, or InvViewProj to get to the right model space. But trying both would not be terrible.
So the idea would be to do this on input:
1) run the x,y input coordinate through that InvViewProj to back to model space.
2) Use the stereoize formula on that position.
3) run the x,y,z,w back through the ViewProj matrix to get back to screen space.
Hope that helps. As noted, I'm not quite there with this type of fix.
Edit: I also notice that it already deprojects back to View space at:
You might be able to sneak in there and steroize at that moment, if that's in the right model space.
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
Hi Bo3b, I have not followed all of this thread, but thought I'd throw out a few comments while I have a few minutes (my Masters course has now started, and I am quite literally swallowed up with the amount of stuff to do...). Corrections need to be made in either View space or Projection space i.e. one of the spaces representing the scene from the camera perspective. Whenever you see something like invView or invViewProj, those matrices will put you back in WORLD coordinates, which is not where you can make a correction. In your example above, you would actually look to stereoize BEFORE the matrix is applied i.e. stereoize the original r1 variable. That being said, this still might not be what you want to do in this shader, but if it is that is what you would do. Same with something that applies invViewProj. Note that the correction for these two cases is different:
View space: S*(-r.z - C) * P11 ; the important point here is that the z-comp is used
Proj Space: S*(r.w - C)
where:
r is the source coordinate
P11 is the (1,1) element of the projection matrix. Depending where you get this from you might use 1/P11
Sometimes the terminology "screen space" is used, and a warning is that this is not used consistently in shaders - *usually* its is proj space, but sometimes its view space. You need to try and work it out, for example based on what matrices get applied either to it, or to something else to get to it.
Sometimes (in fact often) in a Pixel Shader, you can get some form of 2D screen position but not necesarilly the correct depth to apply in the second form of the fix above. In these cases the shader may (usually) derive the World coordinate as part of its deferred algorithm e.g. a shadow map. In this case, to do the correction you forward project the World coord to Proj coords using "a VPM", make the stereo correction, then reverse transform it using the inverse VPM. The trouble with this approach is that you don't always (and often do not) have access to the VPM in the shader that needs fixing - but the Helix wrapper allows you to re-use VPMs from other shaders, and this then solves the problem.
I had previously suggested to you that putting this information up so early on in the course might cause more confusion than, but it seems some people are ploughing ahead anyway, so hopefully this helps - PM me if you'd like to go through it in a more structured way offline.
Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278
- I haven't tried doing anything with 3Dmigoto yet, but I did try with HelixMod.
- Finding a shader and dump it, disable it is not that hard. Problem is: you don't know if you found a correct shader until you actually try to fix it.
- I searched around HelixMod blog=>guides and here on the forums and I wasn't really able to find the information I was looking for:
I did follow and watched the video in bo3b's School Shader class ^_^ and I know he didn't get this far to what I am asking above, but I think it would be very beneficial if in the future we could make a WIKI or guide with as much examples, tips&tricks as possible to help out a newb;))
- I know that each game/engine is different and use different techniques but I expect the fixing pattern to be the same, only the details matter;))
I already asked Mike_ar69 via PM and he gladly responded and helped me out with a lot of information so far, but I think it would be awesome if we could gather it all in one place so new people aren't frightened at the beginning from all this information;))
(I think I should have posted this in the other thread but here I think it makes much more sense;)))
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
For some reason I always thought that stereoization happened in World coordinates, but clearly that's wrong. That's gotta be a key part of my confusion on fixing deferred rendering.
@ForgottenProdigy: Based on Mike's suggestion it looks like the best spot to try to stereoize the effect is before the InvView:
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
No code changes from the 0.77 for x32, and 0.75 for x64, but in a more convenient and clear container.
This moves to a different release mode, where I'm combining both the x32 and x64 versions into a single zip, under their own folders. This way you can use whichever variant is necessary for a game.
Please use this version if you are starting any new research. If you are already in the middle of things, there is nothing here that would require an update.
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
and this
Using the latest build (0.82).