How to fix/disable shaders in games(DLL,guide and fixes).
  158 / 167    
What does the LOG.txt say? Anything useful? Also, would be worth trying to change the key from F10, some games interfere with the reload.
What does the LOG.txt say? Anything useful?

Also, would be worth trying to change the key from F10, some games interfere with the reload.

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

Posted 09/13/2014 12:41 PM   
[quote="bo3b"]What does the LOG.txt say? Anything useful? Also, would be worth trying to change the key from F10, some games interfere with the reload.[/quote] Hmm.. Anything I should be looking for in the LOG ? I don't know exactly what to look for in there... The main problem I am having is that in the game I find a shader with a CRC32 which I can't find in the DUMPS folder, but I can cycle it in-game... Either this is a bug or something is not set correctly and that shader is not dumped. Either way, I can't get the source of that shader.. (Dump all or using the key)...
bo3b said:What does the LOG.txt say? Anything useful?

Also, would be worth trying to change the key from F10, some games interfere with the reload.


Hmm.. Anything I should be looking for in the LOG ? I don't know exactly what to look for in there...

The main problem I am having is that in the game I find a shader with a CRC32 which I can't find in the DUMPS folder, but I can cycle it in-game... Either this is a bug or something is not set correctly and that shader is not dumped. Either way, I can't get the source of that shader.. (Dump all or using the key)...

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)

Posted 09/13/2014 01:23 PM   
[quote="helifax"]The main problem I am having is that in the game I find a shader with a CRC32 which I can't find in the DUMPS folder, but I can cycle it in-game... Either this is a bug or something is not set correctly and that shader is not dumped. Either way, I can't get the source of that shader.. (Dump all or using the key)...[/quote] Strange. Have you tried seeing if you can dump the shader using any of the other Helixmod DLLs?
helifax said:The main problem I am having is that in the game I find a shader with a CRC32 which I can't find in the DUMPS folder, but I can cycle it in-game... Either this is a bug or something is not set correctly and that shader is not dumped. Either way, I can't get the source of that shader.. (Dump all or using the key)...


Strange. Have you tried seeing if you can dump the shader using any of the other Helixmod DLLs?

Dual boot Win 7 x64 & Win 10 (1809) | Geforce Drivers 417.35

Posted 09/13/2014 02:29 PM   
[quote="helifax"][quote="bo3b"]What does the LOG.txt say? Anything useful? Also, would be worth trying to change the key from F10, some games interfere with the reload.[/quote] Hmm.. Anything I should be looking for in the LOG ? I don't know exactly what to look for in there... The main problem I am having is that in the game I find a shader with a CRC32 which I can't find in the DUMPS folder, but I can cycle it in-game... Either this is a bug or something is not set correctly and that shader is not dumped. Either way, I can't get the source of that shader.. (Dump all or using the key)...[/quote]Yeah, pretty sure that is a bug. It sounds like you tried other versions of the dll and they crash instead. Some games just don't play nice with Helixmod and have this sort of inconsistent effect. To avoid the crashes, make sure there are no overlays involved, including the hated Steam. If that still crashes, try the injected version of the dll instead of the wrap version.
helifax said:
bo3b said:What does the LOG.txt say? Anything useful?

Also, would be worth trying to change the key from F10, some games interfere with the reload.


Hmm.. Anything I should be looking for in the LOG ? I don't know exactly what to look for in there...

The main problem I am having is that in the game I find a shader with a CRC32 which I can't find in the DUMPS folder, but I can cycle it in-game... Either this is a bug or something is not set correctly and that shader is not dumped. Either way, I can't get the source of that shader.. (Dump all or using the key)...
Yeah, pretty sure that is a bug. It sounds like you tried other versions of the dll and they crash instead.

Some games just don't play nice with Helixmod and have this sort of inconsistent effect. To avoid the crashes, make sure there are no overlays involved, including the hated Steam. If that still crashes, try the injected version of the dll instead of the wrap version.

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

Posted 09/14/2014 12:38 AM   
[quote="bo3b"][quote="helifax"][quote="bo3b"]What does the LOG.txt say? Anything useful? Also, would be worth trying to change the key from F10, some games interfere with the reload.[/quote] Hmm.. Anything I should be looking for in the LOG ? I don't know exactly what to look for in there... The main problem I am having is that in the game I find a shader with a CRC32 which I can't find in the DUMPS folder, but I can cycle it in-game... Either this is a bug or something is not set correctly and that shader is not dumped. Either way, I can't get the source of that shader.. (Dump all or using the key)...[/quote]Yeah, pretty sure that is a bug. It sounds like you tried other versions of the dll and they crash instead. Some games just don't play nice with Helixmod and have this sort of inconsistent effect. To avoid the crashes, make sure there are no overlays involved, including the hated Steam. If that still crashes, try the injected version of the dll instead of the wrap version.[/quote] I had a feeling it was a timestamp. It took me a bit to figure it out that's in the YY MM DD format (US) rather than DD MM YY format (EU) :)) I tried again with a different DLL that was previously crashing and removed the ShaderOverride folder (which was causing the crash). Same thing I was able to find the same CRC32 vertex shader yet like before is not being dumped :(... Guess the engine does something different and the DLL is not working properly on this game...
bo3b said:
helifax said:
bo3b said:What does the LOG.txt say? Anything useful?

Also, would be worth trying to change the key from F10, some games interfere with the reload.


Hmm.. Anything I should be looking for in the LOG ? I don't know exactly what to look for in there...

The main problem I am having is that in the game I find a shader with a CRC32 which I can't find in the DUMPS folder, but I can cycle it in-game... Either this is a bug or something is not set correctly and that shader is not dumped. Either way, I can't get the source of that shader.. (Dump all or using the key)...
Yeah, pretty sure that is a bug. It sounds like you tried other versions of the dll and they crash instead.

Some games just don't play nice with Helixmod and have this sort of inconsistent effect. To avoid the crashes, make sure there are no overlays involved, including the hated Steam. If that still crashes, try the injected version of the dll instead of the wrap version.


I had a feeling it was a timestamp. It took me a bit to figure it out that's in the YY MM DD format (US) rather than DD MM YY format (EU) :))

I tried again with a different DLL that was previously crashing and removed the ShaderOverride folder (which was causing the crash). Same thing I was able to find the same CRC32 vertex shader yet like before is not being dumped :(...
Guess the engine does something different and the DLL is not working properly on this game...

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)

Posted 09/14/2014 09:47 AM   
In response to this post [url]https://forums.geforce.com/default/topic/539437/3d-vision/watch-dogs/post/4311001/#4311001[/url] in the Watch Dogs thread, I picked a shader at random and brain dumped. This is the shader, and then I dump my thought processes: [code] //Shadows/AO under cars cbuffer Viewport : register(b0) { float4x4 _ViewRotProjectionMatrix : packoffset(c0); float4x4 _ViewProjectionMatrix : packoffset(c4); float4x4 _ProjectionMatrix : packoffset(c8); float4x4 _InvProjectionMatrix : packoffset(c12); float4x4 _InvProjectionMatrixDepth : packoffset(c16); float4x4 _DepthTextureTransform : packoffset(c20); float4x3 _ViewMatrix : packoffset(c24); float4x3 _InvViewMatrix : packoffset(c27); float4x4 _PreviousViewProjectionMatrix : packoffset(c30); float4 _CameraDistances : packoffset(c34); float4 _ViewportSize : packoffset(c35); float4 _CameraPosition_MaxStaticReflectionMipIndex : packoffset(c36); float4 _CameraDirection_MaxParaboloidReflectionMipIndex : packoffset(c37); float4 _ViewPoint_ExposureScale : packoffset(c38); float4 _FogColorVector_ExposedWhitePointOverExposureScale : packoffset(c39); float3 _SideFogColor : packoffset(c40); float3 _SunFogColorDelta : packoffset(c41); float3 _OppositeFogColorDelta : packoffset(c42); float4 _FogValues0 : packoffset(c43); float4 _FogValues1 : packoffset(c44); float4 _CameraNearPlaneSize : packoffset(c45); float4 _UncompressDepthWeights_ShadowProjDepthMinValue : packoffset(c46); float4 _UncompressDepthWeightsWS_ReflectionFadeTarget : packoffset(c47); float4 _WorldAmbientColorParams0 : packoffset(c48); float4 _WorldAmbientColorParams1 : packoffset(c49); float4 _WorldAmbientColorParams2 : packoffset(c50); float4 _GlobalWorldTextureParams : packoffset(c51); float4 _CullingCameraPosition_OneOverAutoExposureScale : packoffset(c52); float4 _AmbientSkyColor_ReflectionScaleStrength : packoffset(c53); float4 _AmbientGroundColor_ReflectionScaleDistanceMul : packoffset(c54); float4 _FacettedShadowCastParams : packoffset(c55); float4 _FSMClipPlanes : packoffset(c56); float2 _ReflectionGIControl : packoffset(c57); } SamplerState Viewport__DepthVPSampler__SampObj___s : register(s0); SamplerState Viewport__GBufferNormalTexture__SampObj___s : register(s1); SamplerState AmbientOcclusionVolume__AmbientOcclusionTexure__SampObj___s : register(s2); Texture2D<float4> Viewport__DepthVPSampler__TexObj__ : register(t0); Texture2D<float4> Viewport__GBufferNormalTexture__TexObj__ : register(t1); Texture2D<float4> AmbientOcclusionVolume__AmbientOcclusionTexure__TexObj__ : register(t2); Texture2D<float4> StereoParams : register(t125); void main( float4 v0 : TEXCOORD0, float4 v1 : TEXCOORD1, float4 v2 : TEXCOORD2, float4 v3 : TEXCOORD3, float4 v4 : TEXCOORD4, float4 v5 : TEXCOORD5, float v6 : TEXCOORD6, float4 v7 : SV_Position0, out float4 o0 : SV_Target0) { float4 r0,r1,r2,r3,r4; uint4 bitmask; r0.xy = v0.xy / v0.zz; r0.z = Viewport__DepthVPSampler__TexObj__.Sample(Viewport__DepthVPSampler__SampObj___s, r0.xy).x; r1.xyz = Viewport__GBufferNormalTexture__TexObj__.Sample(Viewport__GBufferNormalTexture__SampObj___s, r0.xy).xyz; r1.xyz = r1.xyz * float3(2.000000e+000,2.000000e+000,2.000000e+000) + float3(-1.000000e+000,-1.000000e+000,-1.000000e+000); r0.w = 1.000000000e+000; r0.x = dot(r0.zw, _InvProjectionMatrix._m22_m32); r0.y = dot(r0.zw, _InvProjectionMatrix._m23_m33); r0.x = -r0.x / r0.y; r0.yzw = v5.xyz / v5.zzz; r2.x = v1.w; r2.y = v2.w; r2.z = v3.w; float4 stereo = StereoParams.Load(0); float4 r22; r22.xyz = r0.yzw * -r0.xxx; r22.x -= stereo.x*(-r22.z - stereo.y)*_InvProjectionMatrix._m00; r0.xyz = r22.xyz + -r2.xyz; //r0.yzw * -r0.xxx + -r2.xyz; r2.z = dot(r0.xyz, v3.xyz); r2.z = abs(r2.z); r3.x = dot(r0.xyz, v1.xyz); r3.y = dot(r0.xyz, v2.xyz); r3.zw = abs(r3.xy) * abs(r3.xy); r4.xy = r3.xy * float2(5.000000e-001,5.000000e-001) + float2(5.000000e-001,5.000000e-001); r2.xy = r3.zw * r3.zw; r2.xyz = min(r2.xyz, float3(1.000000e+000,1.000000e+000,1.000000e+000)); r2.xyz = float3(1.000000e+000,1.000000e+000,1.000000e+000) + -r2.xyz; r0.w = r2.x * r2.y; r0.w = r0.w * r2.z; r4.z = 1.000000000e+000 + -r4.y; r2.xyzw = AmbientOcclusionVolume__AmbientOcclusionTexure__TexObj__.Sample(AmbientOcclusionVolume__AmbientOcclusionTexure__SampObj___s, r4.xz).xyzw; r1.w = dot(r2.xyzw, v4.xyzw); r0.w = r1.w * r0.w; r2.x = dot(r1.xyz, _ViewMatrix._m00_m10_m20); r2.y = dot(r1.xyz, _ViewMatrix._m01_m11_m21); r2.z = dot(r1.xyz, _ViewMatrix._m02_m12_m22); r1.x = dot(r2.xyz, r2.xyz); r1.x = rsqrt(r1.x); r1.xyz = r2.xyz * r1.xxx; r1.w = dot(r0.xyz, r0.xyz); r1.w = rsqrt(r1.w); r0.xyz = r1.www * r0.xyz; r0.x = dot(r1.xyz, r0.xyz); r0.x = saturate(5.000000000e-001 + r0.x); r0.x = -r0.x * v6.x + 1.000000000e+000; r0.x = r0.w * r0.x; r0.x = v5.w * r0.x; r0.x = saturate(min(r0.x, v4.w)); r0.x = v0.w + -r0.x; o0.xyzw = float4(1.000000e+000,1.000000e+000,1.000000e+000,1.000000e+000) + r0.xxxx; return; } [/code] Looking at this I see that InvProjectionMatrix is used which takes a coord from proj to view space, and I see that ViewMatrix is used which takes a coord from world to view space. So correction around these two points is likely to hold the key. In the first case it is a correction on view space, and in the second case it could be a correction (in different ways) in either coord. To correct a world coord, so in this case the r1.xyz value will need a ViewProj and and InvViewProj, which we don't have directly in this shader (though the InvViewProj can be generated from the separate InView and InProjection matrices). So this goes on the backburner until its the last resort. I also see an ambient occlusion sampler, so looking fomr something that affects that is another good thing to look for. So best candidates are: 1. Correcting r0.xyz in this line: r0.xyz = r0.yzw * -r0.xxx + -r2.xyz; 2. Correcting r2.xyz after thes elines: r2.x = dot(r1.xyz, _ViewMatrix._m00_m10_m20); r2.y = dot(r1.xyz, _ViewMatrix._m01_m11_m21); r2.z = dot(r1.xyz, _ViewMatrix._m02_m12_m22); Looking at them, my hunch is that case 1 has the answer in it, but I'll look at 2 first. Case 2: r2.xyz is a good and obvious candidate. You could (and I think I perhaps did, but can't remember) simply just try and apply a correction to it. We know its in View Space. the trouble is we don;t really know what it is. Its prevenance leads back to Viewport__GBufferNormalTexture__TexObj__, which might indicate that its a vector that is being transformed. It's worth a try and it may even fix some parts of the problem BUT notice that r1.xyz is not used in any of the code deriving from Case 1, so its independent of that. Now see below. Case 1: This was my preferred starting point, and it looks like something I fixed in AC3/4, and in SR3/4. It is also a good candidate because this line includes what looks like is the EyePos/CamPos in r2.xyz: r2.x = v1.w; r2.y = v2.w; r2.z = v3.w; This suggests that r0.yzw*-r0.xxx is a normalized View vector of some kind, scaled by a depth - add this to the EyePos gives the world coord. Looking up the code, we see that r0.yzw comes from a texcoord passed in v5, normalized by its z comp, and r0.x comes from inversing the proj matrix on a depth obtained from a depth map, so the inverse projection gives the depth in view space. NOW - it does not matter if all the nuances of what gets divided by what etc are not fully clear, this is all the right kind of stuff. All this tells me that I need to correct the compound term (r0.yzw * -r0.xxx). The other important thing I noticed here, is that the r0.xyz term that gets affected by this correction, ultimately affects the indexing of the AmbientOcclusionVolume__AmbientOcclusionTexure__TexObj__ sampler, *which is the effect we are trying to fix*. r0.xyz ultimately gets combined with the r2.xyz that comes out of case 1, so the stereo correction also propagates there as well. The Solution So I decided I neede to fix the vector (r22.xyz = r0.yzw * - r0.xxx). The equation for this is: r22.x -= stereo.x*(-r22.z - stereo.y)*_InvProjectionMatrix._m00; The differences with the "normal" stereo fix are: - use -r22.z instead of r22.w (because that does not exist) - multiply by _InvProjectionMatrix._m00. We happen to be fortunate that this shader contains this matrix. If it's not clear whether you need to multiply or divide by this parameter, or if you just plain forgot, try them both. If you have the ProjMatrix, you can use that too. To understand this you need to go through the maths of multiplying the Proj Matrix to see why it is this way, but I am not going to do that. I have no idea if this helps anyone, but someone did ask...
In response to this post https://forums.geforce.com/default/topic/539437/3d-vision/watch-dogs/post/4311001/#4311001 in the Watch Dogs thread, I picked a shader at random and brain dumped. This is the shader, and then I dump my thought processes:

//Shadows/AO under cars
cbuffer Viewport : register(b0)
{
float4x4 _ViewRotProjectionMatrix : packoffset(c0);
float4x4 _ViewProjectionMatrix : packoffset(c4);
float4x4 _ProjectionMatrix : packoffset(c8);
float4x4 _InvProjectionMatrix : packoffset(c12);
float4x4 _InvProjectionMatrixDepth : packoffset(c16);
float4x4 _DepthTextureTransform : packoffset(c20);
float4x3 _ViewMatrix : packoffset(c24);
float4x3 _InvViewMatrix : packoffset(c27);
float4x4 _PreviousViewProjectionMatrix : packoffset(c30);
float4 _CameraDistances : packoffset(c34);
float4 _ViewportSize : packoffset(c35);
float4 _CameraPosition_MaxStaticReflectionMipIndex : packoffset(c36);
float4 _CameraDirection_MaxParaboloidReflectionMipIndex : packoffset(c37);
float4 _ViewPoint_ExposureScale : packoffset(c38);
float4 _FogColorVector_ExposedWhitePointOverExposureScale : packoffset(c39);
float3 _SideFogColor : packoffset(c40);
float3 _SunFogColorDelta : packoffset(c41);
float3 _OppositeFogColorDelta : packoffset(c42);
float4 _FogValues0 : packoffset(c43);
float4 _FogValues1 : packoffset(c44);
float4 _CameraNearPlaneSize : packoffset(c45);
float4 _UncompressDepthWeights_ShadowProjDepthMinValue : packoffset(c46);
float4 _UncompressDepthWeightsWS_ReflectionFadeTarget : packoffset(c47);
float4 _WorldAmbientColorParams0 : packoffset(c48);
float4 _WorldAmbientColorParams1 : packoffset(c49);
float4 _WorldAmbientColorParams2 : packoffset(c50);
float4 _GlobalWorldTextureParams : packoffset(c51);
float4 _CullingCameraPosition_OneOverAutoExposureScale : packoffset(c52);
float4 _AmbientSkyColor_ReflectionScaleStrength : packoffset(c53);
float4 _AmbientGroundColor_ReflectionScaleDistanceMul : packoffset(c54);
float4 _FacettedShadowCastParams : packoffset(c55);
float4 _FSMClipPlanes : packoffset(c56);
float2 _ReflectionGIControl : packoffset(c57);
}
SamplerState Viewport__DepthVPSampler__SampObj___s : register(s0);
SamplerState Viewport__GBufferNormalTexture__SampObj___s : register(s1);
SamplerState AmbientOcclusionVolume__AmbientOcclusionTexure__SampObj___s : register(s2);
Texture2D<float4> Viewport__DepthVPSampler__TexObj__ : register(t0);
Texture2D<float4> Viewport__GBufferNormalTexture__TexObj__ : register(t1);
Texture2D<float4> AmbientOcclusionVolume__AmbientOcclusionTexure__TexObj__ : register(t2);

Texture2D<float4> StereoParams : register(t125);

void main(
float4 v0 : TEXCOORD0,
float4 v1 : TEXCOORD1,
float4 v2 : TEXCOORD2,
float4 v3 : TEXCOORD3,
float4 v4 : TEXCOORD4,
float4 v5 : TEXCOORD5,
float v6 : TEXCOORD6,
float4 v7 : SV_Position0,
out float4 o0 : SV_Target0)
{
float4 r0,r1,r2,r3,r4;
uint4 bitmask;
r0.xy = v0.xy / v0.zz;
r0.z = Viewport__DepthVPSampler__TexObj__.Sample(Viewport__DepthVPSampler__SampObj___s, r0.xy).x;
r1.xyz = Viewport__GBufferNormalTexture__TexObj__.Sample(Viewport__GBufferNormalTexture__SampObj___s, r0.xy).xyz;
r1.xyz = r1.xyz * float3(2.000000e+000,2.000000e+000,2.000000e+000) + float3(-1.000000e+000,-1.000000e+000,-1.000000e+000);
r0.w = 1.000000000e+000;
r0.x = dot(r0.zw, _InvProjectionMatrix._m22_m32);
r0.y = dot(r0.zw, _InvProjectionMatrix._m23_m33);
r0.x = -r0.x / r0.y;
r0.yzw = v5.xyz / v5.zzz;
r2.x = v1.w;
r2.y = v2.w;
r2.z = v3.w;

float4 stereo = StereoParams.Load(0);
float4 r22;
r22.xyz = r0.yzw * -r0.xxx;
r22.x -= stereo.x*(-r22.z - stereo.y)*_InvProjectionMatrix._m00;

r0.xyz = r22.xyz + -r2.xyz; //r0.yzw * -r0.xxx + -r2.xyz;


r2.z = dot(r0.xyz, v3.xyz);
r2.z = abs(r2.z);
r3.x = dot(r0.xyz, v1.xyz);
r3.y = dot(r0.xyz, v2.xyz);
r3.zw = abs(r3.xy) * abs(r3.xy);
r4.xy = r3.xy * float2(5.000000e-001,5.000000e-001) + float2(5.000000e-001,5.000000e-001);
r2.xy = r3.zw * r3.zw;
r2.xyz = min(r2.xyz, float3(1.000000e+000,1.000000e+000,1.000000e+000));
r2.xyz = float3(1.000000e+000,1.000000e+000,1.000000e+000) + -r2.xyz;
r0.w = r2.x * r2.y;
r0.w = r0.w * r2.z;
r4.z = 1.000000000e+000 + -r4.y;
r2.xyzw = AmbientOcclusionVolume__AmbientOcclusionTexure__TexObj__.Sample(AmbientOcclusionVolume__AmbientOcclusionTexure__SampObj___s, r4.xz).xyzw;
r1.w = dot(r2.xyzw, v4.xyzw);
r0.w = r1.w * r0.w;
r2.x = dot(r1.xyz, _ViewMatrix._m00_m10_m20);
r2.y = dot(r1.xyz, _ViewMatrix._m01_m11_m21);
r2.z = dot(r1.xyz, _ViewMatrix._m02_m12_m22);
r1.x = dot(r2.xyz, r2.xyz);
r1.x = rsqrt(r1.x);
r1.xyz = r2.xyz * r1.xxx;
r1.w = dot(r0.xyz, r0.xyz);
r1.w = rsqrt(r1.w);
r0.xyz = r1.www * r0.xyz;
r0.x = dot(r1.xyz, r0.xyz);
r0.x = saturate(5.000000000e-001 + r0.x);
r0.x = -r0.x * v6.x + 1.000000000e+000;
r0.x = r0.w * r0.x;
r0.x = v5.w * r0.x;
r0.x = saturate(min(r0.x, v4.w));
r0.x = v0.w + -r0.x;
o0.xyzw = float4(1.000000e+000,1.000000e+000,1.000000e+000,1.000000e+000) + r0.xxxx;
return;
}


Looking at this I see that InvProjectionMatrix is used which takes a coord from proj to view space, and I see that ViewMatrix is used which takes a coord from world to view space. So correction around these two points is likely to hold the key. In the first case it is a correction on view space, and in the second case it could be a correction (in different ways) in either coord. To correct a world coord, so in this case the r1.xyz value will need a ViewProj and and InvViewProj, which we don't have directly in this shader (though the InvViewProj can be generated from the separate InView and InProjection matrices). So this goes on the backburner until its the last resort. I also see an ambient occlusion sampler, so looking fomr something that affects that is another good thing to look for. So best candidates are:
1. Correcting r0.xyz in this line:
r0.xyz = r0.yzw * -r0.xxx + -r2.xyz;
2. Correcting r2.xyz after thes elines:
r2.x = dot(r1.xyz, _ViewMatrix._m00_m10_m20);
r2.y = dot(r1.xyz, _ViewMatrix._m01_m11_m21);
r2.z = dot(r1.xyz, _ViewMatrix._m02_m12_m22);

Looking at them, my hunch is that case 1 has the answer in it, but I'll look at 2 first.

Case 2:
r2.xyz is a good and obvious candidate. You could (and I think I perhaps did, but can't remember) simply just try and apply a correction to it. We know its in View Space. the trouble is we don;t really know what it is. Its prevenance leads back to Viewport__GBufferNormalTexture__TexObj__, which might indicate that its a vector that is being transformed.
It's worth a try and it may even fix some parts of the problem BUT notice that r1.xyz is not used in any of the code deriving from Case 1, so its independent of that. Now see below.

Case 1: This was my preferred starting point, and it looks like something I fixed in AC3/4, and in SR3/4. It is also a good candidate because this line includes what looks like is the EyePos/CamPos in r2.xyz:
r2.x = v1.w;
r2.y = v2.w;
r2.z = v3.w;

This suggests that r0.yzw*-r0.xxx is a normalized View vector of some kind, scaled by a depth - add this to the EyePos gives the world coord. Looking up the code, we see that r0.yzw comes from a texcoord passed in v5, normalized by its z comp, and r0.x comes from inversing the proj matrix on a depth obtained from a depth map, so the inverse projection gives the depth in view space. NOW - it does not matter if all the nuances of what gets divided by what etc are not fully clear, this is all the right kind of stuff. All this tells me that I need to correct the compound term (r0.yzw * -r0.xxx). The other important thing I noticed here, is that the r0.xyz term that gets affected by this correction, ultimately affects the indexing of the AmbientOcclusionVolume__AmbientOcclusionTexure__TexObj__ sampler, *which is the effect we are trying to fix*. r0.xyz ultimately gets combined with the r2.xyz that comes out of case 1, so the stereo correction also propagates there as well.

The Solution
So I decided I neede to fix the vector (r22.xyz = r0.yzw * - r0.xxx). The equation for this is:

r22.x -= stereo.x*(-r22.z - stereo.y)*_InvProjectionMatrix._m00;

The differences with the "normal" stereo fix are:
- use -r22.z instead of r22.w (because that does not exist)
- multiply by _InvProjectionMatrix._m00. We happen to be fortunate that this shader contains this matrix. If it's not clear whether you need to multiply or divide by this parameter, or if you just plain forgot, try them both. If you have the ProjMatrix, you can use that too. To understand this you need to go through the maths of multiplying the Proj Matrix to see why it is this way, but I am not going to do that.


I have no idea if this helps anyone, but someone did ask...

Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278

Posted 09/15/2014 07:55 PM   
I had a look at "The Sims 4" and came across a strange issue. The game could offer an excellent S3D experience (apart from the 2D HUD and cursor), shadows, bloom, depth of field, skybox, etc. everything works fine. There is only a strange "gap" at the edge of the lots. The ground is at correct depth but near the edge of the lot the texture is only rendered for one eye depending on the stereo settings and the distance, see http://photos.3dvisionlive.com/3d4dd/image/541acf82d475fe8373000107/ . Using other profiles (Sims 3, Prototype, Aion) even caused more issues. I discovered that this issue appears as soons as You paint a ground texture (soil, cobblestone, etc.) on the lot. Without this painted textures and only the common ground grass texture present everything works fine, see http://photos.3dvisionlive.com/3d4dd/image/541acf59d475fe8674000110/. I hunted the PS (68D76126) used for some of the lots: [code]//lot painted, issue // Generated by shader LotTerrain.fx // // Parameters: // // float4 CascadeShadowParams[6]; // float4 ExteriorLightData[4]; // float4 ShaderDayNightParameters; // float3 SunCubeBasis[2]; // float4 g_lot_terrain_paint_ps_params; // float4 g_lot_terrain_spec_paint_ps_params; // float4 g_ssao_ps_apply_params[4]; // sampler2D samplerLightMap; // sampler2D samplerPaintTexture; // sampler2D samplerShadowMainMap; // sampler2D samplerSpecPaintTexture; // samplerCUBE samplerTerrainCubeMap; // sampler2D samplerblendMap; // sampler2D samplercolorMap; // sampler2D samplercolorMap2; // sampler2D samplercolorMap3; // sampler2D samplercolorMap4; // sampler2D samplerg_SsaoBuffer; // sampler2D samplerspecMap; // sampler2D samplerspecMap2; // sampler2D samplerspecMap3; // sampler2D samplerspecMap4; // float4 shadowTextureData; // float4 specScales; // // // Registers: // // Name Reg Size // ---------------------------------- ----- ---- // ExteriorLightData c6 4 // CascadeShadowParams c12 6 // g_ssao_ps_apply_params c18 2 // SunCubeBasis c20 2 // shadowTextureData c22 1 // ShaderDayNightParameters c23 1 // g_lot_terrain_paint_ps_params c24 1 // g_lot_terrain_spec_paint_ps_params c25 1 // specScales c26 1 // samplerg_SsaoBuffer s0 1 // samplerLightMap s1 1 // samplerPaintTexture s2 1 // samplerSpecPaintTexture s3 1 // samplercolorMap s4 1 // samplerShadowMainMap s5 1 // samplercolorMap2 s6 1 // samplercolorMap3 s7 1 // samplercolorMap4 s8 1 // samplerspecMap s9 1 // samplerspecMap2 s10 1 // samplerspecMap3 s11 1 // samplerspecMap4 s12 1 // samplerTerrainCubeMap s13 1 // samplerblendMap s14 1 // // // Default values: // // ExteriorLightData // c6 = { 0, 0, 0, 0 }; // c7 = { 0, 0, 0, 0 }; // c8 = { 0, 0, 0, 0 }; // c9 = { 0, 0, 0, 0 }; // // CascadeShadowParams // c12 = { 0, 0, 0, 0 }; // c13 = { 0, 0, 0, 0 }; // c14 = { 0, 0, 0, 0 }; // c15 = { 0, 0, 0, 0 }; // c16 = { 0, 0, 0, 0 }; // c17 = { 0, 0, 0, 0 }; // // g_ssao_ps_apply_params // c18 = { 0, 0, 0, 0 }; // c19 = { 0, 0, 0, 0 }; // // SunCubeBasis // c20 = { 0, 0, 0, 0 }; // c21 = { 0, 0, 0, 0 }; // // shadowTextureData // c22 = { 1024, 1024, 0.000976563, 0.000976563 }; // // ShaderDayNightParameters // c23 = { 1, 0, 0, 0 }; // // g_lot_terrain_paint_ps_params // c24 = { 0, 0, 0, 0 }; // // g_lot_terrain_spec_paint_ps_params // c25 = { 0, 0, 0, 0 }; // // specScales // c26 = { 0, 0, 0, 0 }; // ps_3_0 def c0, 1, -0, 0.25, 10 def c1, 1, 2, -1, 0.5 def c2, 8, 0.104999997, 0.335000008, 0.0599999987 dcl_color v0 dcl_texcoord1 v1.xy dcl_texcoord2 v2.xyz dcl_texcoord3 v3.xy dcl_texcoord4 v4.xy dcl_texcoord5 v5.xyz dcl_texcoord6 v6 dcl vPos.xy dcl_2d s0 dcl_2d s1 dcl_2d s2 dcl_2d s3 dcl_2d s4 dcl_2d s5 dcl_2d s6 dcl_2d s7 dcl_2d s8 dcl_2d s9 dcl_2d s10 dcl_2d s11 dcl_2d s12 dcl_cube s13 dcl_2d s14 texld r3, v1, s14 dp3 r0.w, r3, c1.x add_sat r3.w, -r0.w, c1.x texld r2, v4, s4 mov r5.w, r2.w texld r4, v4, s6 mov r5.z, r4.w texld r1, v4, s7 mov r5.y, r1.w texld r0, v4, s8 mov r5.x, r0.w mad r3, c1.y, r3, r5 add_sat r3, r3, c1.z dp4 r0.w, r3, c1.x rcp r0.w, r0.w mul r3, r3, r0.w mul r4.xyz, r4, r3.z mad r2.xyz, r2, r3.w, r4 mad r1.xyz, r1, r3.y, r2 mad r6.xyz, r0, r3.x, r1 mad r0.xy, vPos, c24, c24.zwzw texld r2, r0, s2 add r4.xy, v6.w, -c16.yxzw mov r0.xyz, c12 mad r0.xyz, v6, r0, c13 cmp r1.xyz, r4.y, r0, v6 mov r0.xyz, c14 mad r0.xyz, v6, r0, c15 cmp r0.xyz, r4.x, r0, r1 mad r4.zw, r0.z, c0.xyxy, c0.xyyx add r6.w, -r2.w, c1.x mov r1.zw, r4 mov r7.xyw, c1 mad r4.xy, c22.zwzw, -r7.w, r0 mov r5.zw, r1 add r0.xy, r4, c22.zwzw mov r0.zw, r5 texldp r0, r0, s5 mov r0.w, r0.x mad r5.xy, c22.zwzw, r7.yxzw, r4 texldp r5, r5, s5 mov r0.z, r5.x texldp r5, r4, s5 mov r0.x, r5.x mad r1.xy, c22.zwzw, r7, r4 texldp r1, r1, s5 mov r0.y, r1.x dp4 r1.z, r0, c0.z mad_sat r1.w, v6.w, c17.z, c17.w lrp r0.w, r1.w, c1.x, r1.z dp3_sat r4.w, v2, c7 min r1.z, r0.w, c1.x mul r1.w, r4.w, c0.w min r0.w, r1.w, r1.z mov r0.xyz, c9 add r0.xyz, -r0, c6 mad r2.xyz, r6, r6.w, r2 mad r4.xyz, r0.w, r0, c9 texld r0, v3, s1 mul r0.w, r0.w, c23.x lrp r1.xyz, r4.w, r4, c8 mul r0.w, r0.w, c2.x mad r4.xyz, r0, r0.w, r1 mad r0.xy, vPos, c18, c18.zwzw texld r0, r0, s0 mul r0.w, r0.x, r0.x lrp r1.w, c19.w, r0.w, r0.x mov r1.xyz, v2 dp3 r0.w, v5, r1 mad_sat r0.z, r1.w, c19.x, c19.y add r0.w, r0.w, r0.w mul r0.xyz, r4, r0.z mad r1.xyz, r1, -r0.w, v5 mul r2.xyz, r2, r0 dp3 r0.z, r1, c21 dp3 r0.x, r1, c20 dp3 r0.y, r1, c7 texld r0, r0, s13 dp3 r0.w, r0, r0 cmp r0.w, -r0.w, c0.y, c0.x mad r1.xy, vPos, c25, c25.zwzw texld r1, r1, s3 if_ne r0.w, -r0.w mul r3, r3, c26 texld r4, v4, s10 mul r0.w, r3.z, r4.y texld r4, v4, s9 mad r0.w, r3.w, r4.y, r0.w texld r4, v4, s11 mad r0.w, r3.y, r4.y, r0.w texld r4, v4, s12 mad r0.w, r3.x, r4.y, r0.w add r1.w, -r2.w, c1.x mad r0.w, r0.w, r1.w, r1.y mad r0.xyz, r0.w, r0, r2 else mov r0.xyz, r2 endif mov_sat r0.w, v0.w add r1.xyz, -r0, v0 mad oC0.xyz, r0.w, r1, r0 dp3 oC0.w, r0, c2.yzww // approximately 104 instruction slots used (18 texture, 86 arithmetic) [/code] According to bo3b's lesson 5 I've made some experiments and discovered that commenting out texld r2, r0, s2 (line 150, s2 = samplerPaintTexture) removed the painted texture and so the issue with the edges. But it also removed parts of the common ground grass texture on the lot, see http://photos.3dvisionlive.com/3d4dd/image/541acfc6d475fe430400005f/ . I was lucky to find that repacing s2 (samplerPaintTexture) with s13 (samplerTerrainCubeMap) replaced the missing parts of the ground texture (see http://photos.3dvisionlive.com/3d4dd/image/541ad025d475fedf7100014a/ ). So "texld r2, r0, s13" is a workaround. So far so good. Of course it would be much better to fix the broken edges caused by the painted textures instead of removing this gameplay element. But I don't know if there was another game with an issue like this and if it could be fixed. I discovered that there is a separate shader for lots without painted textures (PixelShader_79_CRC32_32649FA3). As soon as there are painted textures another shader is used for the lot (PS 68D76126, see above) with additional elements (g_lot_terrain_paint_ps_params; g_lot_terrain_spec_paint_ps_params; samplerPaintTexture). There is also a PS (PixelShader_78_CRC32_70F8E562) that when disabled allows to see olny the painted texture on the lot (without removing the issues an the edges, see http://photos.3dvisionlive.com/3d4dd/image/541befe0d475fefb6b0001a1/ ). Regarding VS there is VS (VertexShader_91_CRC32_27BA7FF3) only for the painted texture (if disabled it removes the painted texture but not the issues) and a VS for the common ground grass texture on the lot (VertexShader_92_CRC32_7ED12D76). BTW PixelShader_78_CRC32_70F8E562 and VertexShader_91_CRC32_27BA7FF3 are ps_2_0 or vs_2_0. Is this mixture of 2_0 and 3_0 shaders normal? The shaders mentioned above can be downloaded here: http://www12.zippyshare.com/v/33085941/file.html Maybe someone could take a look at it to see if the issue with the wrong rendered edges could be fixed...? All the shaders are "Generated by shader LotTerrain.fx". Unfortunately I couldn't extract this shader from the game files. Modders were able to extract shaders to remove the censor pixels but I don't know which tool they used. In additon there are 3 other types of lots that use different PS than PS 68D76126. In this case my trick with samplerTerrainCubeMap didn't work. But I could disable the painted textures by replacing these shaders with the equivalent shaders for the empty lots without painted textures. I only had to adjust the c... and s... values.
I had a look at "The Sims 4" and came across a strange issue. The game could offer an excellent S3D experience (apart from the 2D HUD and cursor), shadows, bloom, depth of field, skybox, etc. everything works fine. There is only a strange "gap" at the edge of the lots. The ground is at correct depth but near the edge of the lot the texture is only rendered for one eye depending on the stereo settings and the distance, see http://photos.3dvisionlive.com/3d4dd/image/541acf82d475fe8373000107/ . Using other profiles (Sims 3, Prototype, Aion) even caused more issues. I discovered that this issue appears as soons as You paint a ground texture (soil, cobblestone, etc.) on the lot. Without this painted textures and only the common ground grass texture present everything works fine, see http://photos.3dvisionlive.com/3d4dd/image/541acf59d475fe8674000110/. I hunted the PS (68D76126) used for some of the lots:
//lot painted, issue
// Generated by shader LotTerrain.fx
//
// Parameters:
//
// float4 CascadeShadowParams[6];
// float4 ExteriorLightData[4];
// float4 ShaderDayNightParameters;
// float3 SunCubeBasis[2];
// float4 g_lot_terrain_paint_ps_params;
// float4 g_lot_terrain_spec_paint_ps_params;
// float4 g_ssao_ps_apply_params[4];
// sampler2D samplerLightMap;
// sampler2D samplerPaintTexture;
// sampler2D samplerShadowMainMap;
// sampler2D samplerSpecPaintTexture;
// samplerCUBE samplerTerrainCubeMap;
// sampler2D samplerblendMap;
// sampler2D samplercolorMap;
// sampler2D samplercolorMap2;
// sampler2D samplercolorMap3;
// sampler2D samplercolorMap4;
// sampler2D samplerg_SsaoBuffer;
// sampler2D samplerspecMap;
// sampler2D samplerspecMap2;
// sampler2D samplerspecMap3;
// sampler2D samplerspecMap4;
// float4 shadowTextureData;
// float4 specScales;
//
//
// Registers:
//
// Name Reg Size
// ---------------------------------- ----- ----
// ExteriorLightData c6 4
// CascadeShadowParams c12 6
// g_ssao_ps_apply_params c18 2
// SunCubeBasis c20 2
// shadowTextureData c22 1
// ShaderDayNightParameters c23 1
// g_lot_terrain_paint_ps_params c24 1
// g_lot_terrain_spec_paint_ps_params c25 1
// specScales c26 1
// samplerg_SsaoBuffer s0 1
// samplerLightMap s1 1
// samplerPaintTexture s2 1
// samplerSpecPaintTexture s3 1
// samplercolorMap s4 1
// samplerShadowMainMap s5 1
// samplercolorMap2 s6 1
// samplercolorMap3 s7 1
// samplercolorMap4 s8 1
// samplerspecMap s9 1
// samplerspecMap2 s10 1
// samplerspecMap3 s11 1
// samplerspecMap4 s12 1
// samplerTerrainCubeMap s13 1
// samplerblendMap s14 1
//
//
// Default values:
//
// ExteriorLightData
// c6 = { 0, 0, 0, 0 };
// c7 = { 0, 0, 0, 0 };
// c8 = { 0, 0, 0, 0 };
// c9 = { 0, 0, 0, 0 };
//
// CascadeShadowParams
// c12 = { 0, 0, 0, 0 };
// c13 = { 0, 0, 0, 0 };
// c14 = { 0, 0, 0, 0 };
// c15 = { 0, 0, 0, 0 };
// c16 = { 0, 0, 0, 0 };
// c17 = { 0, 0, 0, 0 };
//
// g_ssao_ps_apply_params
// c18 = { 0, 0, 0, 0 };
// c19 = { 0, 0, 0, 0 };
//
// SunCubeBasis
// c20 = { 0, 0, 0, 0 };
// c21 = { 0, 0, 0, 0 };
//
// shadowTextureData
// c22 = { 1024, 1024, 0.000976563, 0.000976563 };
//
// ShaderDayNightParameters
// c23 = { 1, 0, 0, 0 };
//
// g_lot_terrain_paint_ps_params
// c24 = { 0, 0, 0, 0 };
//
// g_lot_terrain_spec_paint_ps_params
// c25 = { 0, 0, 0, 0 };
//
// specScales
// c26 = { 0, 0, 0, 0 };
//

ps_3_0
def c0, 1, -0, 0.25, 10
def c1, 1, 2, -1, 0.5
def c2, 8, 0.104999997, 0.335000008, 0.0599999987
dcl_color v0
dcl_texcoord1 v1.xy
dcl_texcoord2 v2.xyz
dcl_texcoord3 v3.xy
dcl_texcoord4 v4.xy
dcl_texcoord5 v5.xyz
dcl_texcoord6 v6
dcl vPos.xy
dcl_2d s0
dcl_2d s1
dcl_2d s2
dcl_2d s3
dcl_2d s4
dcl_2d s5
dcl_2d s6
dcl_2d s7
dcl_2d s8
dcl_2d s9
dcl_2d s10
dcl_2d s11
dcl_2d s12
dcl_cube s13
dcl_2d s14
texld r3, v1, s14
dp3 r0.w, r3, c1.x
add_sat r3.w, -r0.w, c1.x
texld r2, v4, s4
mov r5.w, r2.w
texld r4, v4, s6
mov r5.z, r4.w
texld r1, v4, s7
mov r5.y, r1.w
texld r0, v4, s8
mov r5.x, r0.w
mad r3, c1.y, r3, r5
add_sat r3, r3, c1.z
dp4 r0.w, r3, c1.x
rcp r0.w, r0.w
mul r3, r3, r0.w
mul r4.xyz, r4, r3.z
mad r2.xyz, r2, r3.w, r4
mad r1.xyz, r1, r3.y, r2
mad r6.xyz, r0, r3.x, r1
mad r0.xy, vPos, c24, c24.zwzw
texld r2, r0, s2
add r4.xy, v6.w, -c16.yxzw
mov r0.xyz, c12
mad r0.xyz, v6, r0, c13
cmp r1.xyz, r4.y, r0, v6
mov r0.xyz, c14
mad r0.xyz, v6, r0, c15
cmp r0.xyz, r4.x, r0, r1
mad r4.zw, r0.z, c0.xyxy, c0.xyyx
add r6.w, -r2.w, c1.x
mov r1.zw, r4
mov r7.xyw, c1
mad r4.xy, c22.zwzw, -r7.w, r0
mov r5.zw, r1
add r0.xy, r4, c22.zwzw
mov r0.zw, r5
texldp r0, r0, s5
mov r0.w, r0.x
mad r5.xy, c22.zwzw, r7.yxzw, r4
texldp r5, r5, s5
mov r0.z, r5.x
texldp r5, r4, s5
mov r0.x, r5.x
mad r1.xy, c22.zwzw, r7, r4
texldp r1, r1, s5
mov r0.y, r1.x
dp4 r1.z, r0, c0.z
mad_sat r1.w, v6.w, c17.z, c17.w
lrp r0.w, r1.w, c1.x, r1.z
dp3_sat r4.w, v2, c7
min r1.z, r0.w, c1.x
mul r1.w, r4.w, c0.w
min r0.w, r1.w, r1.z
mov r0.xyz, c9
add r0.xyz, -r0, c6
mad r2.xyz, r6, r6.w, r2
mad r4.xyz, r0.w, r0, c9
texld r0, v3, s1
mul r0.w, r0.w, c23.x
lrp r1.xyz, r4.w, r4, c8
mul r0.w, r0.w, c2.x
mad r4.xyz, r0, r0.w, r1
mad r0.xy, vPos, c18, c18.zwzw
texld r0, r0, s0
mul r0.w, r0.x, r0.x
lrp r1.w, c19.w, r0.w, r0.x
mov r1.xyz, v2
dp3 r0.w, v5, r1
mad_sat r0.z, r1.w, c19.x, c19.y
add r0.w, r0.w, r0.w
mul r0.xyz, r4, r0.z
mad r1.xyz, r1, -r0.w, v5
mul r2.xyz, r2, r0
dp3 r0.z, r1, c21
dp3 r0.x, r1, c20
dp3 r0.y, r1, c7
texld r0, r0, s13
dp3 r0.w, r0, r0
cmp r0.w, -r0.w, c0.y, c0.x
mad r1.xy, vPos, c25, c25.zwzw
texld r1, r1, s3
if_ne r0.w, -r0.w
mul r3, r3, c26
texld r4, v4, s10
mul r0.w, r3.z, r4.y
texld r4, v4, s9
mad r0.w, r3.w, r4.y, r0.w
texld r4, v4, s11
mad r0.w, r3.y, r4.y, r0.w
texld r4, v4, s12
mad r0.w, r3.x, r4.y, r0.w
add r1.w, -r2.w, c1.x
mad r0.w, r0.w, r1.w, r1.y
mad r0.xyz, r0.w, r0, r2
else
mov r0.xyz, r2
endif
mov_sat r0.w, v0.w
add r1.xyz, -r0, v0
mad oC0.xyz, r0.w, r1, r0
dp3 oC0.w, r0, c2.yzww

// approximately 104 instruction slots used (18 texture, 86 arithmetic)

According to bo3b's lesson 5 I've made some experiments and discovered that commenting out texld r2, r0, s2 (line 150, s2 = samplerPaintTexture) removed the painted texture and so the issue with the edges. But it also removed parts of the common ground grass texture on the lot, see http://photos.3dvisionlive.com/3d4dd/image/541acfc6d475fe430400005f/ . I was lucky to find that repacing s2 (samplerPaintTexture) with s13 (samplerTerrainCubeMap) replaced the missing parts of the ground texture (see http://photos.3dvisionlive.com/3d4dd/image/541ad025d475fedf7100014a/ ). So "texld r2, r0, s13" is a workaround.
So far so good.
Of course it would be much better to fix the broken edges caused by the painted textures instead of removing this gameplay element. But I don't know if there was another game with an issue like this and if it could be fixed. I discovered that there is a separate shader for lots without painted textures (PixelShader_79_CRC32_32649FA3). As soon as there are painted textures another shader is used for the lot (PS 68D76126, see above) with additional elements (g_lot_terrain_paint_ps_params; g_lot_terrain_spec_paint_ps_params; samplerPaintTexture). There is also a PS (PixelShader_78_CRC32_70F8E562) that when disabled allows to see olny the painted texture on the lot (without removing the issues an the edges, see http://photos.3dvisionlive.com/3d4dd/image/541befe0d475fefb6b0001a1/ ). Regarding VS there is VS (VertexShader_91_CRC32_27BA7FF3) only for the painted texture (if disabled it removes the painted texture but not the issues) and a VS for the common ground grass texture on the lot (VertexShader_92_CRC32_7ED12D76). BTW PixelShader_78_CRC32_70F8E562 and VertexShader_91_CRC32_27BA7FF3 are ps_2_0 or vs_2_0. Is this mixture of 2_0 and 3_0 shaders normal?
The shaders mentioned above can be downloaded here: http://www12.zippyshare.com/v/33085941/file.html
Maybe someone could take a look at it to see if the issue with the wrong rendered edges could be fixed...?
All the shaders are "Generated by shader LotTerrain.fx". Unfortunately I couldn't extract this shader from the game files. Modders were able to extract shaders to remove the censor pixels but I don't know which tool they used.

In additon there are 3 other types of lots that use different PS than PS 68D76126. In this case my trick with samplerTerrainCubeMap didn't work. But I could disable the painted textures by replacing these shaders with the equivalent shaders for the empty lots without painted textures. I only had to adjust the c... and s... values.

My original display name is 3d4dd - for some reason Nvidia changed it..?!

Posted 09/19/2014 09:12 AM   
Sorry, I missed this one. When I look at your image there, it seems like that might be scissor-clipping. Try setting the "SkipSetScissorRect=true" [url]http://wiki.bo3b.net/index.php?title=HelixMod_Feature_List#SkipSetScissorRect[/url] Let me know if that doesn't do it, and I'll look at other possibilities.
Sorry, I missed this one. When I look at your image there, it seems like that might be scissor-clipping.

Try setting the "SkipSetScissorRect=true"

http://wiki.bo3b.net/index.php?title=HelixMod_Feature_List#SkipSetScissorRect


Let me know if that doesn't do it, and I'll look at other possibilities.

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

Posted 10/01/2014 11:42 AM   
"SkipSetScissorRect=true" was the first fix I have tried (without really knowing what it is good for). Had forgotten to mention it, sorry. Unfortunately it didn't help. But I will try it again when I am back at my gaming PC.
"SkipSetScissorRect=true" was the first fix I have tried (without really knowing what it is good for). Had forgotten to mention it, sorry. Unfortunately it didn't help. But I will try it again when I am back at my gaming PC.

My original display name is 3d4dd - for some reason Nvidia changed it..?!

Posted 10/05/2014 09:45 AM   
[quote="3d4dd"]"SkipSetScissorRect=true" was the first fix I have tried (without really knowing what it is good for). Had forgotten to mention it, sorry. Unfortunately it didn't help. But I will try it again when I am back at my gaming PC.[/quote]OK, interesting that didn't work. That really looks like clipping to me. Try digging around in the shader and see if there is anything there that is suggestive of clipping, like a clip-matrix. You might be able to find something that can be modified.
3d4dd said:"SkipSetScissorRect=true" was the first fix I have tried (without really knowing what it is good for). Had forgotten to mention it, sorry. Unfortunately it didn't help. But I will try it again when I am back at my gaming PC.
OK, interesting that didn't work. That really looks like clipping to me.

Try digging around in the shader and see if there is anything there that is suggestive of clipping, like a clip-matrix. You might be able to find something that can be modified.

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

Posted 10/05/2014 11:40 PM   
I have tried "SkipSetScissorRect=true" again without success. [quote="bo3b"]Try digging around in the shader and see if there is anything there that is suggestive of clipping, like a clip-matrix. You might be able to find something that can be modified.[/quote] Should I search for a certain pattern? I simlpy looked for "clip" and had two hits: [code]// // Generated by shader ConvertLightmap. // // Parameters: // // float4 ClipSpaceOffset; // sampler2D samplerSourceTexture; // // // Registers: // // Name Reg Size // -------------------- ----- ---- // ClipSpaceOffset c0 1 // samplerSourceTexture s0 1 // // // Default values: // // ClipSpaceOffset // c0 = { 0, 0, 0, 0 }; // ps_2_0 def c1, -1, 1, 0.25, 8 def c2, 0.125, 0, 0, 0 dcl t0.xy dcl_2d s0 add r3.x, t0.x, c0.z add r3.y, t0.y, c0.w add r2.x, t0.x, -c0.z add r2.y, t0.y, -c0.w mov r0.xy, c1 mad r1.x, c0.z, r0.x, t0.x mad r1.y, c0.w, r0.y, t0.y mad r0.x, c0.z, -r0.x, t0.x mad r0.y, c0.w, -r0.y, t0.y texld r3, r3, s0 texld r4, r2, s0 texld r2, r1, s0 texld r1, r0, s0 texld r0, t0, s0 add r3.xyz, r3, r4 add r2.xyz, r2, r3 add r1.xyz, r1, r2 mad r0.xyz, r1, -c1.z, r0 mov_sat r0.w, r0.w mul r0.xyz, r0, r0.w mad r0.xyz, r1, c1.z, r0 max r1.w, r0.x, r0.y max r2.w, r1.w, r0.z max r1.w, r2.w, c1.y min r0.w, r1.w, c1.w rcp r1.w, r0.w mul r0.w, r0.w, c2.x mul r0.xyz, r0, r1.w mov oC0, r0 // approximately 29 instruction slots used (5 texture, 24 arithmetic)[/code] [code]// // Generated by shader Particle.fx // // Parameters: // // float clipAlphaOpacity; // sampler2D samplerAlbedoTexture; // // // Registers: // // Name Reg Size // -------------------- ----- ---- // clipAlphaOpacity c12 1 // samplerAlbedoTexture s0 1 // // // Default values: // // clipAlphaOpacity // c12 = { 0.5, 0, 0, 0 }; // ps_2_0 def c0, -0.200000003, 0, 0, 0 dcl v0 dcl t1.xy dcl_2d s0 texld r0, t1, s0 mad r1, r0.w, v0.w, c0.x mul r0.xyz, r0, v0 texkill r1 mov r0.w, c12.x mov oC0, r0 // approximately 6 instruction slots used (1 texture, 5 arithmetic)[/code]
I have tried "SkipSetScissorRect=true" again without success.
bo3b said:Try digging around in the shader and see if there is anything there that is suggestive of clipping, like a clip-matrix. You might be able to find something that can be modified.

Should I search for a certain pattern?
I simlpy looked for "clip" and had two hits:
//
// Generated by shader ConvertLightmap.
//
// Parameters:
//
// float4 ClipSpaceOffset;
// sampler2D samplerSourceTexture;
//
//
// Registers:
//
// Name Reg Size
// -------------------- ----- ----
// ClipSpaceOffset c0 1
// samplerSourceTexture s0 1
//
//
// Default values:
//
// ClipSpaceOffset
// c0 = { 0, 0, 0, 0 };
//

ps_2_0
def c1, -1, 1, 0.25, 8
def c2, 0.125, 0, 0, 0
dcl t0.xy
dcl_2d s0
add r3.x, t0.x, c0.z
add r3.y, t0.y, c0.w
add r2.x, t0.x, -c0.z
add r2.y, t0.y, -c0.w
mov r0.xy, c1
mad r1.x, c0.z, r0.x, t0.x
mad r1.y, c0.w, r0.y, t0.y
mad r0.x, c0.z, -r0.x, t0.x
mad r0.y, c0.w, -r0.y, t0.y
texld r3, r3, s0
texld r4, r2, s0
texld r2, r1, s0
texld r1, r0, s0
texld r0, t0, s0
add r3.xyz, r3, r4
add r2.xyz, r2, r3
add r1.xyz, r1, r2
mad r0.xyz, r1, -c1.z, r0
mov_sat r0.w, r0.w
mul r0.xyz, r0, r0.w
mad r0.xyz, r1, c1.z, r0
max r1.w, r0.x, r0.y
max r2.w, r1.w, r0.z
max r1.w, r2.w, c1.y
min r0.w, r1.w, c1.w
rcp r1.w, r0.w
mul r0.w, r0.w, c2.x
mul r0.xyz, r0, r1.w
mov oC0, r0

// approximately 29 instruction slots used (5 texture, 24 arithmetic)

//
// Generated by shader Particle.fx
//
// Parameters:
//
// float clipAlphaOpacity;
// sampler2D samplerAlbedoTexture;
//
//
// Registers:
//
// Name Reg Size
// -------------------- ----- ----
// clipAlphaOpacity c12 1
// samplerAlbedoTexture s0 1
//
//
// Default values:
//
// clipAlphaOpacity
// c12 = { 0.5, 0, 0, 0 };
//

ps_2_0
def c0, -0.200000003, 0, 0, 0
dcl v0
dcl t1.xy
dcl_2d s0
texld r0, t1, s0
mad r1, r0.w, v0.w, c0.x
mul r0.xyz, r0, v0
texkill r1
mov r0.w, c12.x
mov oC0, r0

// approximately 6 instruction slots used (1 texture, 5 arithmetic)

My original display name is 3d4dd - for some reason Nvidia changed it..?!

Posted 10/06/2014 03:52 PM   
Nope, sorry, it would most likely be something related to the shader in question. Always possible there is another shader on top that is doing clipping though. Particle.fx doesn't seem very likely for a surface like this. The ConvertLightMap is a maybe. It wouldn't hurt to comment out the lines where c0 is used to modify the inputs. Or change it to a cX where you specify the constants and see if has an effect on the clipping. If I remember correctly it's also possible that SkipScissorRect doesn't work in all games, sometimes fails for unknown reasons. For this sort of thing though- since you found a great workaround that has no ill effects, I'd go with that. The problem with hacking is that we often cannot make it do things 'properly', it's just trying to get something that works with the fewest problems.
Nope, sorry, it would most likely be something related to the shader in question. Always possible there is another shader on top that is doing clipping though.

Particle.fx doesn't seem very likely for a surface like this. The ConvertLightMap is a maybe. It wouldn't hurt to comment out the lines where c0 is used to modify the inputs. Or change it to a cX where you specify the constants and see if has an effect on the clipping.


If I remember correctly it's also possible that SkipScissorRect doesn't work in all games, sometimes fails for unknown reasons.

For this sort of thing though- since you found a great workaround that has no ill effects, I'd go with that. The problem with hacking is that we often cannot make it do things 'properly', it's just trying to get something that works with the fewest problems.

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

Posted 10/07/2014 12:53 AM   
Has anyone worked out exactly what it is about the various profiles that allows the driver to fix things automatically (I mean specifically which settings do what)? I spent a bit of time this evening experimenting with the unidentified settings in the Aion and Prototype 2 profiles and was able to identify a few things - I've added what I've learned so far to the bottom of this custom setting names XML file (replace the one from nVidia Inspector with this to use it): https://raw.githubusercontent.com/DarkStarSword/3d-fixes/master/CustomSettingNames_en-EN.xml I've found that 0x70E34A78 seems to be responsible for fixing various halo type issues (e.g. water in Miasmata and lots of issues in World of Diving), though I haven't worked out what the significance of the values are yet, as any non-zero value seems to have the same effect. When I set 0x4B1CD968 to 0x00000000 I broke shadows in Miasmata, so that seems to be relevant. Setting 0x70EDB381 to 0x00000000 turned the game into mono - the glasses kicked in but I was seeing the image meant for the left eye in both eyes, so I'm guessing this might have some effect on the heuristics that decide what gets stereoised? The mere existence of 0x701EB457 (i.e. not greyed out) seems to allow 3D to kick in in Windowed mode, regardless of what the value is set to. I've also identified the convergence (0x708DB8C5) and whether the 3D notes are displayed (0x704F5928), but they aren't all that interesting. The setting that has the 3D notes is pretty obvious, though it looks like nVidia inspector has some bugs finding the right string from the database, so for some games it displays garbage instead.
Has anyone worked out exactly what it is about the various profiles that allows the driver to fix things automatically (I mean specifically which settings do what)?

I spent a bit of time this evening experimenting with the unidentified settings in the Aion and Prototype 2 profiles and was able to identify a few things - I've added what I've learned so far to the bottom of this custom setting names XML file (replace the one from nVidia Inspector with this to use it):

https://raw.githubusercontent.com/DarkStarSword/3d-fixes/master/CustomSettingNames_en-EN.xml

I've found that 0x70E34A78 seems to be responsible for fixing various halo type issues (e.g. water in Miasmata and lots of issues in World of Diving), though I haven't worked out what the significance of the values are yet, as any non-zero value seems to have the same effect.

When I set 0x4B1CD968 to 0x00000000 I broke shadows in Miasmata, so that seems to be relevant.

Setting 0x70EDB381 to 0x00000000 turned the game into mono - the glasses kicked in but I was seeing the image meant for the left eye in both eyes, so I'm guessing this might have some effect on the heuristics that decide what gets stereoised?

The mere existence of 0x701EB457 (i.e. not greyed out) seems to allow 3D to kick in in Windowed mode, regardless of what the value is set to.

I've also identified the convergence (0x708DB8C5) and whether the 3D notes are displayed (0x704F5928), but they aren't all that interesting. The setting that has the 3D notes is pretty obvious, though it looks like nVidia inspector has some bugs finding the right string from the database, so for some games it displays garbage instead.

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 10/09/2014 02:26 PM   
That is some very interesting research! I don't believe that anyone has ever tied together the little bits for how the profiles work, or what they affect. My best guess has been that the profiles actively change nvapi calls to stereoize differently depending upon what they found out. Here is the description from NVidia for the calls I think are relevant: [quote]Defeating Driver Heuristics As described earlier, 3D Vision Automatic uses driver heuristics to decide which draw calls need to be stereoized and which ones should not be. In this section, some of the common problem heuristics are described, and their specific behaviors outlined. NULL Z-buffer Target For PC based applications, the most common stereoscopic heuristic that applications run into is the state of the Z-buffer. When the Z-buffer is set to NULL, the 3D Vision Automatic driver uses this as a cue that the rendering being actively performed is a blit-with-shader, and disables the stereoscopic portion accordingly. If you wish to avoid rendering to the Z-buffer while performing an operation, but still need that operation to be stereoized, set the Z-test function to ALWAYS and Z-write-enable to FALSE, while leaving a Z-target bound. Surface Aspect Ratios In Direct3D9, all Render Targets (surfaces created with IDirect3DDevice9::CreateRenderTarget), regardless of aspect ratio, are stereoized. By default, non-square surfaces that are equal to or larger than the back buffer are stereoized. Non-square surfaces smaller than the backbuffer are not stereoized by default. Square surfaces are (by default) not stereoized. The expected usage for these surfaces is typically projected lights or shadow buffers, and therefore they are not eye-dependent. In order to apply these heuristics to a Direct3D9 title, applications should create the desired renderable surface with IDirect3DDevice9::CreateTexture, taking care to set the D3DUSAGE_RENDERTARGET bit of the usage parameter.[/quote] A main call in the nvapi that affect stereo, like NvAPI_Stereo_SetSurfaceCreationMode, as: [code]/////////////////////////////////////////////////////////////////////////////// // // FUNCTION NAME: NvAPI_Stereo_SetSurfaceCreationMode // //! \function NvAPI_Stereo_SetSurfaceCreationMode(StereoHandle hStereoHandle, NVAPI_STEREO_SURFACECREATEMODE creationMode) //! \param [in] hStereoHandle Stereo handle that corresponds to the device interface. //! \param [in] creationMode New surface creation mode for this device interface. //! //! \since Release: 285 //! //! SUPPORTED OS: Windows Vista and higher //! //! //! DESCRIPTION: This API sets surface creation mode for this device interface. //! //! WHEN TO USE: After the stereo handle for device interface is created via successful call to appropriate NvAPI_Stereo_CreateHandleFrom function. //! //! \return This API can return any of the error codes enumerated in #NvAPI_Status. //! There are no return error codes with specific meaning for this API. //! /////////////////////////////////////////////////////////////////////////////// //! \ingroup stereoapi typedef enum _NVAPI_STEREO_SURFACECREATEMODE { NVAPI_STEREO_SURFACECREATEMODE_AUTO, //!< Use driver registry profile settings for surface creation mode. NVAPI_STEREO_SURFACECREATEMODE_FORCESTEREO, //!< Always create stereo surfaces. NVAPI_STEREO_SURFACECREATEMODE_FORCEMONO //!< Always create mono surfaces. } NVAPI_STEREO_SURFACECREATEMODE; //! \ingroup stereoapi NVAPI_INTERFACE NvAPI_Stereo_SetSurfaceCreationMode(__in StereoHandle hStereoHandle, __in NVAPI_STEREO_SURFACECREATEMODE creationMode); [/code] I'm fairly sure that is being called in response to one or more of the profile flags being set. Based on the discussion of stereoizing square targets or not. In 3Dmigoto, there are options to set the stereo rendering modes, in a way that I think is similar if not the same to the way the profiles work to dictate the heuristics. [code]; sets the global surface creation heuristic for NVidia stero driver. ; 0 = NVAPI_STEREO_SURFACECREATEMODE_AUTO - use driver registry profile settings for surface creation mode. ; 1 = NVAPI_STEREO_SURFACECREATEMODE_FORCESTEREO - Always create stereo surfaces. ; 2 = NVAPI_STEREO_SURFACECREATEMODE_FORCEMONO - Always create mono surfaces. ;surface_createmode=1 ; overrides surface creation mode for square surfaces. ;surface_square_createmode=1 [/code] I'm not certain those work, but I think all of these pieces tie together some how. Just not sure about the details. Like, if we set surface_square_createmode=1 does that affect shadows? I think yes, but haven't done any legwork to see how they tie together. For a lot of the games, I've often wondered if the driver heuristics are doing more harm than good. The guesses on square and smaller render targets is all well and good, but are just guesses. It might actually be easier to fix stuff without the sort of random nature of the profiles, so a way to turn all them off has been on my todo list for awhile.
That is some very interesting research! I don't believe that anyone has ever tied together the little bits for how the profiles work, or what they affect.

My best guess has been that the profiles actively change nvapi calls to stereoize differently depending upon what they found out.

Here is the description from NVidia for the calls I think are relevant:

Defeating Driver Heuristics

As described earlier, 3D Vision Automatic uses driver heuristics to decide which draw calls need to be stereoized and which ones should not be. In this section, some of the common problem heuristics are described, and their specific behaviors outlined.

NULL Z-buffer Target

For PC based applications, the most common stereoscopic heuristic that applications run into is the state of the Z-buffer. When the Z-buffer is set to NULL, the 3D Vision Automatic driver uses this as a cue that the rendering being actively performed is a blit-with-shader, and disables the stereoscopic portion accordingly.

If you wish to avoid rendering to the Z-buffer while performing an operation, but still need that operation to be stereoized, set the Z-test function to ALWAYS and Z-write-enable to FALSE, while leaving a Z-target bound.

Surface Aspect Ratios

In Direct3D9, all Render Targets (surfaces created with IDirect3DDevice9::CreateRenderTarget), regardless of aspect ratio, are stereoized.

By default, non-square surfaces that are equal to or larger than the back buffer are stereoized. Non-square surfaces smaller than the backbuffer are not stereoized by default.

Square surfaces are (by default) not stereoized. The expected usage for these surfaces is typically projected lights or shadow buffers, and therefore they are not eye-dependent.

In order to apply these heuristics to a Direct3D9 title, applications should create the desired renderable surface with IDirect3DDevice9::CreateTexture, taking care to set the D3DUSAGE_RENDERTARGET bit of the usage parameter.



A main call in the nvapi that affect stereo, like NvAPI_Stereo_SetSurfaceCreationMode, as:


///////////////////////////////////////////////////////////////////////////////
//
// FUNCTION NAME: NvAPI_Stereo_SetSurfaceCreationMode
//
//! \function NvAPI_Stereo_SetSurfaceCreationMode(StereoHandle hStereoHandle, NVAPI_STEREO_SURFACECREATEMODE creationMode)
//! \param [in] hStereoHandle Stereo handle that corresponds to the device interface.
//! \param [in] creationMode New surface creation mode for this device interface.
//!
//! \since Release: 285
//!
//! SUPPORTED OS: Windows Vista and higher
//!
//!
//! DESCRIPTION: This API sets surface creation mode for this device interface.
//!
//! WHEN TO USE: After the stereo handle for device interface is created via successful call to appropriate NvAPI_Stereo_CreateHandleFrom function.
//!
//! \return This API can return any of the error codes enumerated in #NvAPI_Status.
//! There are no return error codes with specific meaning for this API.
//!
///////////////////////////////////////////////////////////////////////////////

//! \ingroup stereoapi
typedef enum _NVAPI_STEREO_SURFACECREATEMODE
{
NVAPI_STEREO_SURFACECREATEMODE_AUTO, //!< Use driver registry profile settings for surface creation mode.
NVAPI_STEREO_SURFACECREATEMODE_FORCESTEREO, //!< Always create stereo surfaces.
NVAPI_STEREO_SURFACECREATEMODE_FORCEMONO //!< Always create mono surfaces.
} NVAPI_STEREO_SURFACECREATEMODE;

//! \ingroup stereoapi
NVAPI_INTERFACE NvAPI_Stereo_SetSurfaceCreationMode(__in StereoHandle hStereoHandle, __in NVAPI_STEREO_SURFACECREATEMODE creationMode);



I'm fairly sure that is being called in response to one or more of the profile flags being set. Based on the discussion of stereoizing square targets or not.

In 3Dmigoto, there are options to set the stereo rendering modes, in a way that I think is similar if not the same to the way the profiles work to dictate the heuristics.

; sets the global surface creation heuristic for NVidia stero driver.
; 0 = NVAPI_STEREO_SURFACECREATEMODE_AUTO - use driver registry profile settings for surface creation mode.
; 1 = NVAPI_STEREO_SURFACECREATEMODE_FORCESTEREO - Always create stereo surfaces.
; 2 = NVAPI_STEREO_SURFACECREATEMODE_FORCEMONO - Always create mono surfaces.
;surface_createmode=1

; overrides surface creation mode for square surfaces.
;surface_square_createmode=1


I'm not certain those work, but I think all of these pieces tie together some how. Just not sure about the details. Like, if we set surface_square_createmode=1 does that affect shadows? I think yes, but haven't done any legwork to see how they tie together.

For a lot of the games, I've often wondered if the driver heuristics are doing more harm than good. The guesses on square and smaller render targets is all well and good, but are just guesses. It might actually be easier to fix stuff without the sort of random nature of the profiles, so a way to turn all them off has been on my todo list for awhile.

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

Posted 10/10/2014 12:19 AM   
Regarding my clipping issue with The Sims 4 I have tried to change the ConvertLightMap shader but it had either no effect or crashed the game. So with my own knowledge I only can offer a hotfix that allows to disable painted terrain by hotkey to avoid the issues. Maybe someone is interested in this fix. I have told eqzitara about the fix and he said that he might take a look at Sims 4 himself. So I will describe and offer the fix as WIP here in the forum.
Regarding my clipping issue with The Sims 4 I have tried to change the ConvertLightMap shader but it had either no effect or crashed the game. So with my own knowledge I only can offer a hotfix that allows to disable painted terrain by hotkey to avoid the issues. Maybe someone is interested in this fix. I have told eqzitara about the fix and he said that he might take a look at Sims 4 himself. So I will describe and offer the fix as WIP here in the forum.

My original display name is 3d4dd - for some reason Nvidia changed it..?!

Posted 10/14/2014 09:36 AM   
  158 / 167    
Scroll To Top