3Dmigoto now open-source...
  72 / 143    
[quote="masterotaku"][quote="4everAwake"] I'm not sure, but try this and let me know if it makes a difference: [/quote] Sadly, no. It's exactly the same as the original unmodified shader (even if I comment the condition). Things are OK when they are at screen depth, but wrong at any other depth.[/quote] Sorry, I made an error in the VS that I posted previously (I forgot to include the bracket at the very end). Can you test the one below? [code]//Gravity VS. // ---- Created with 3Dmigoto v1.2.37 on Sun May 15 15:03:15 2016 cbuffer _Globals : register(b0) { float4 globalColorMask : packoffset(c0) = {1,1,1,1}; float4 globalColorMaskN : packoffset(c1) = {0,0,0,0}; float softParticleScale : packoffset(c2); float softParticleContrast : packoffset(c2.y); float softParticleEnabled : packoffset(c2.z); float doCameraFadeout : packoffset(c2.w); float cameraFadeoutFactor : packoffset(c3); float4x4 World : packoffset(c4); float4x4 WorldView : packoffset(c8); float4x4 WorldViewProjection : packoffset(c12); } cbuffer NVStereoCB : register(b12) { float nv_negative_separation_convergence; float nv_separation; float nv_unused; float nv_stereo_enabled; } // 3Dmigoto declarations #define cmp - Texture1D<float4> IniParams : register(t120); Texture2D<float4> StereoParams : register(t125); void main( float3 v0 : POSITION0, float3 v1 : NORMAL0, float4 v2 : COLOR0, float2 v3 : TEXCOORD0, out float4 o0 : SV_POSITION0, out float4 o1 : TEXCOORD1, out float4 o2 : TEXCOORD0, out float3 o3 : TEXCOORD2) { float4 r0; uint4 bitmask, uiDest; float4 fDest; float4 stereo = StereoParams.Load(0); float separation = stereo.x; float convergence = stereo.y; r0.xyz = v0.xyz; r0.w = 1; o0.x = dot(r0.xyzw, WorldViewProjection._m00_m10_m20_m30); o0.y = dot(r0.xyzw, WorldViewProjection._m01_m11_m21_m31); o0.z = dot(r0.xyzw, WorldViewProjection._m02_m12_m22_m32); o0.w = dot(r0.xyzw, WorldViewProjection._m03_m13_m23_m33); o1.xyzw = v2.xyzw; o2.xy = v3.xy; //o0.x+=separation*(o0.w-convergence); o3.xyz = v1.xyz; if(nv_stereo_enabled > 1){ o0.x += nv_separation * o0.w + nv_negative_separation_convergence; } return; } [/code] Also, try testing with & without the line "o0.x+=separation*(o0.w-convergence);"
masterotaku said:
4everAwake said:
I'm not sure, but try this and let me know if it makes a difference:


Sadly, no. It's exactly the same as the original unmodified shader (even if I comment the condition). Things are OK when they are at screen depth, but wrong at any other depth.


Sorry, I made an error in the VS that I posted previously (I forgot to include the bracket at the very end). Can you test the one below?
//Gravity VS.
// ---- Created with 3Dmigoto v1.2.37 on Sun May 15 15:03:15 2016

cbuffer _Globals : register(b0)
{
float4 globalColorMask : packoffset(c0) = {1,1,1,1};
float4 globalColorMaskN : packoffset(c1) = {0,0,0,0};
float softParticleScale : packoffset(c2);
float softParticleContrast : packoffset(c2.y);
float softParticleEnabled : packoffset(c2.z);
float doCameraFadeout : packoffset(c2.w);
float cameraFadeoutFactor : packoffset(c3);
float4x4 World : packoffset(c4);
float4x4 WorldView : packoffset(c8);
float4x4 WorldViewProjection : packoffset(c12);
}

cbuffer NVStereoCB : register(b12)
{
float nv_negative_separation_convergence;
float nv_separation;
float nv_unused;
float nv_stereo_enabled;
}

// 3Dmigoto declarations
#define cmp -
Texture1D<float4> IniParams : register(t120);
Texture2D<float4> StereoParams : register(t125);


void main(
float3 v0 : POSITION0,
float3 v1 : NORMAL0,
float4 v2 : COLOR0,
float2 v3 : TEXCOORD0,
out float4 o0 : SV_POSITION0,
out float4 o1 : TEXCOORD1,
out float4 o2 : TEXCOORD0,
out float3 o3 : TEXCOORD2)
{
float4 r0;
uint4 bitmask, uiDest;
float4 fDest;

float4 stereo = StereoParams.Load(0);
float separation = stereo.x;
float convergence = stereo.y;

r0.xyz = v0.xyz;
r0.w = 1;
o0.x = dot(r0.xyzw, WorldViewProjection._m00_m10_m20_m30);
o0.y = dot(r0.xyzw, WorldViewProjection._m01_m11_m21_m31);
o0.z = dot(r0.xyzw, WorldViewProjection._m02_m12_m22_m32);
o0.w = dot(r0.xyzw, WorldViewProjection._m03_m13_m23_m33);
o1.xyzw = v2.xyzw;
o2.xy = v3.xy;
//o0.x+=separation*(o0.w-convergence);
o3.xyz = v1.xyz;

if(nv_stereo_enabled > 1){
o0.x += nv_separation * o0.w + nv_negative_separation_convergence;
}
return;
}


Also, try testing with & without the line "o0.x+=separation*(o0.w-convergence);"

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

Posted 05/25/2016 05:13 AM   
Without uncommenting the the "o0.x+=separation*(o0.w-convergence);" line, the effect is always at screen depth, and with it, it's exactly the same as the original shader. I guess that the "o0.x += nv_separation * o0.w + nv_negative_separation_convergence;" line is behaving like "o0.x-=separation*(o0.w-convergence);". Now I have to go to work, so 13 hours until I'm at home again :(.
Without uncommenting the the "o0.x+=separation*(o0.w-convergence);" line, the effect is always at screen depth, and with it, it's exactly the same as the original shader.

I guess that the "o0.x += nv_separation * o0.w + nv_negative_separation_convergence;" line is behaving like "o0.x-=separation*(o0.w-convergence);".

Now I have to go to work, so 13 hours until I'm at home again :(.

CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com

Posted 05/25/2016 05:51 AM   
[quote="DarkStarSword"]I just wanted to say a public thankyou to Oomek, who I see has been updating the 3DMigoto wiki :) Thanks Oomek![/quote] You are welcome mate. I had in plans to update it even more, but due to recent decline of my health I have been forced to postpone shaderhacking for a while.
DarkStarSword said:I just wanted to say a public thankyou to Oomek, who I see has been updating the 3DMigoto wiki :)

Thanks Oomek!


You are welcome mate. I had in plans to update it even more, but due to recent decline of my health I have been forced to postpone shaderhacking for a while.

EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64

Posted 05/25/2016 08:49 PM   
There was a 3Dmigoto problem in FFX-2 that I could manually fix. Googling it, bo3b faced it before. The vertex shader (which I need to not dump or it will break a water effect. Unrelated to this problem) sends: [code] out float2 o2 : TEXCOORD0, out float2 p2 : TEXCOORD4, out float2 o3 : TEXCOORD6, out float2 p3 : TEXCOORD7, o2.x = ScrollSpeed_tex0_X * scene.GlobalTime + v3.x; o2.y = ScrollSpeed_tex0_Y * scene.GlobalTime + v3.y; p2.xy = ScrollSpeed_tex1_X * scene.GlobalTime + v4.xy; o3.xy = ScrollSpeed_nml1_X * scene.GlobalTime + v5.xy; p3.xy = ScrollSpeed_nml2_X * scene.GlobalTime + v6.xy; [/code] However, in the ASM code: [code] dcl_output o2.xy dcl_output o2.zw dcl_output o3.xy dcl_output o3.zw mad o2.x, cb0[66].w, cb0[28].w, v3.x mad o2.y, cb0[67].x, cb0[28].w, v3.y mad o2.zw, cb0[67].zzzw, cb0[28].wwww, v4.xxxy mad o3.xy, cb0[68].xyxx, cb0[28].wwww, v5.xyxx mad o3.zw, cb0[68].zzzw, cb0[28].wwww, v6.xxxy [/code] Then, the pixel shader receives as inputs: [code] float2 v2 : TEXCOORD0, float2 w2 : TEXCOORD4, float2 v3 : TEXCOORD6, float2 w3 : TEXCOORD7, [/code] But then makes the mistake of for example doing: [code] r1.xyzw = v3.xyzw * float4(1,-1,1,-1) + float4(0,1,0,1); [/code] Which produced a "boop" when I dumped the shader, because v2 and v3 have only 2 dimensions. I could fix it by creating new variables in the pixel shader and doing something like "newv2.xy=v2.xy;newv2.zw=w2.xy;" and then using them instead of the original v2 and v3. The ASM code doesn't suffer from this problem. I just wanted to inform about this and ask if it's normal. By the way, if I ever want to use ASM code instead of HLSL, do I just have to delete all HLSL code?
There was a 3Dmigoto problem in FFX-2 that I could manually fix. Googling it, bo3b faced it before.

The vertex shader (which I need to not dump or it will break a water effect. Unrelated to this problem) sends:

out float2 o2 : TEXCOORD0,
out float2 p2 : TEXCOORD4,
out float2 o3 : TEXCOORD6,
out float2 p3 : TEXCOORD7,

o2.x = ScrollSpeed_tex0_X * scene.GlobalTime + v3.x;
o2.y = ScrollSpeed_tex0_Y * scene.GlobalTime + v3.y;
p2.xy = ScrollSpeed_tex1_X * scene.GlobalTime + v4.xy;
o3.xy = ScrollSpeed_nml1_X * scene.GlobalTime + v5.xy;
p3.xy = ScrollSpeed_nml2_X * scene.GlobalTime + v6.xy;


However, in the ASM code:

dcl_output o2.xy
dcl_output o2.zw
dcl_output o3.xy
dcl_output o3.zw

mad o2.x, cb0[66].w, cb0[28].w, v3.x
mad o2.y, cb0[67].x, cb0[28].w, v3.y
mad o2.zw, cb0[67].zzzw, cb0[28].wwww, v4.xxxy
mad o3.xy, cb0[68].xyxx, cb0[28].wwww, v5.xyxx
mad o3.zw, cb0[68].zzzw, cb0[28].wwww, v6.xxxy


Then, the pixel shader receives as inputs:

float2 v2 : TEXCOORD0,
float2 w2 : TEXCOORD4,
float2 v3 : TEXCOORD6,
float2 w3 : TEXCOORD7,


But then makes the mistake of for example doing:

r1.xyzw = v3.xyzw * float4(1,-1,1,-1) + float4(0,1,0,1);


Which produced a "boop" when I dumped the shader, because v2 and v3 have only 2 dimensions. I could fix it by creating new variables in the pixel shader and doing something like "newv2.xy=v2.xy;newv2.zw=w2.xy;" and then using them instead of the original v2 and v3. The ASM code doesn't suffer from this problem.

I just wanted to inform about this and ask if it's normal.

By the way, if I ever want to use ASM code instead of HLSL, do I just have to delete all HLSL code?

CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com

Posted 06/12/2016 10:07 AM   
@masterotaku: That's the right idea for working around that problem with p2 and p3 extra outputs. This is not super common, but it has popped up periodically. I haven't put much effort into fixing it because the workaround is straightforward. You can switch to ASM for these if you prefer, but read up on the gotchas in the wiki. To use ASM, you'll want to set the extra dumping in the d3dx.ini as export_shaders=1. That will dump every shader seen as ASM. You take that file and drop it into ShaderFixes to enable it. If there is an ASM file it takes precedence over the HLSL file, but to keep it more clear you will likely want to delete the HLSL file.
@masterotaku: That's the right idea for working around that problem with p2 and p3 extra outputs. This is not super common, but it has popped up periodically. I haven't put much effort into fixing it because the workaround is straightforward.

You can switch to ASM for these if you prefer, but read up on the gotchas in the wiki. To use ASM, you'll want to set the extra dumping in the d3dx.ini as export_shaders=1. That will dump every shader seen as ASM. You take that file and drop it into ShaderFixes to enable it. If there is an ASM file it takes precedence over the HLSL file, but to keep it more clear you will likely want to delete the HLSL file.

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 06/13/2016 06:27 AM   
[quote="bo3b"]@masterotaku: That's the right idea for working around that problem with p2 and p3 extra outputs. This is not super common, but it has popped up periodically. I haven't put much effort into fixing it because the workaround is straightforward. You can switch to ASM for these if you prefer, but read up on the gotchas in the wiki. To use ASM, you'll want to set the extra dumping in the d3dx.ini as export_shaders=1. That will dump every shader seen as ASM. You take that file and drop it into ShaderFixes to enable it. If there is an ASM file it takes precedence over the HLSL file, but to keep it more clear you will likely want to delete the HLSL file. [/quote] Or you can do the following: - Find the shader and dump it with 3DMigoto: ex "xxxxxx_vs_replace.txt" - Open the file and DELETE all the HLSL code. - Delete the start/end comments for the ASM code block: The "/*************/" sections. - Rename the file to xxxxx_vs.txt (remove the replace from the name). - Hit F10 and profit;) Even if is a bit of more work I always do this to avoid duplicate shaders (one in ASM and other in HLSL).
bo3b said:@masterotaku: That's the right idea for working around that problem with p2 and p3 extra outputs. This is not super common, but it has popped up periodically. I haven't put much effort into fixing it because the workaround is straightforward.

You can switch to ASM for these if you prefer, but read up on the gotchas in the wiki. To use ASM, you'll want to set the extra dumping in the d3dx.ini as export_shaders=1. That will dump every shader seen as ASM. You take that file and drop it into ShaderFixes to enable it. If there is an ASM file it takes precedence over the HLSL file, but to keep it more clear you will likely want to delete the HLSL file.



Or you can do the following:
- Find the shader and dump it with 3DMigoto: ex "xxxxxx_vs_replace.txt"
- Open the file and DELETE all the HLSL code.
- Delete the start/end comments for the ASM code block: The "/*************/" sections.
- Rename the file to xxxxx_vs.txt (remove the replace from the name).
- Hit F10 and profit;)

Even if is a bit of more work I always do this to avoid duplicate shaders (one in ASM and other in HLSL).

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 06/13/2016 10:10 AM   
Thanks for the info, bo3b and helifax. If a new version of 3Dmigoto fixes this, using it with old manually fixed shaders will break them, right?
Thanks for the info, bo3b and helifax.

If a new version of 3Dmigoto fixes this, using it with old manually fixed shaders will break them, right?

CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com

Posted 06/13/2016 04:52 PM   
[quote="masterotaku"]Thanks for the info, bo3b and helifax. If a new version of 3Dmigoto fixes this, using it with old manually fixed shaders will break them, right?[/quote] I don't understand the question. If we fix the Decompiler bug, it won't affect any fixes already in place. Only shaders in ShaderFixes will be activated for a game fix. And if you have a shader already there and hit Mark, it will beep as it finds the conflict. I set it up that way to avoid overwriting hand fixed shaders. It will 'touch' the file though, so that it sorts to the top of a sort-by-date folder view.
masterotaku said:Thanks for the info, bo3b and helifax.

If a new version of 3Dmigoto fixes this, using it with old manually fixed shaders will break them, right?

I don't understand the question.

If we fix the Decompiler bug, it won't affect any fixes already in place. Only shaders in ShaderFixes will be activated for a game fix. And if you have a shader already there and hit Mark, it will beep as it finds the conflict. I set it up that way to avoid overwriting hand fixed shaders. It will 'touch' the file though, so that it sorts to the top of a sort-by-date folder view.

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 06/14/2016 09:17 AM   
[quote="bo3b"] I don't understand the question.[/quote] It's probably something about how 3Dmigoto works that I don't understand. Like if the non dumped vertex shader is sending two texcoords with 4 dimensions, how can the incorrectly 3Dmigoto generated pixel shader that receives 4 texcoords of 2 dimensions work with just a tweak in the method? Probably a stupid question. I repeat, I'm a web developer so this isn't my field :p.
bo3b said:
I don't understand the question.


It's probably something about how 3Dmigoto works that I don't understand. Like if the non dumped vertex shader is sending two texcoords with 4 dimensions, how can the incorrectly 3Dmigoto generated pixel shader that receives 4 texcoords of 2 dimensions work with just a tweak in the method? Probably a stupid question. I repeat, I'm a web developer so this isn't my field :p.

CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com

Posted 06/15/2016 07:17 AM   
Need some help (if what I need is even possible)! I think I'm on the verge of fixing the lighting in Ryse's compute shader that's causing directional lighting to be in 2D. I've found a section where doing the stereo adjustment causes the lighting to separate in different directions in relation to player/camera position, so I'm pretty sure I just need to convert the coordinates to projection space before doing the fix, and then back. The good news is that there is a VPM in the shader, however the bad news is there is no iVPM... annnnd being as it's a compute shader, I'm having to work with the ASM code, and therefore I have no idea how to use DarkStarSwords matrix.hlsl shader to do the inverse, or whether it's even possible. I just had the idea of redumping a different shader that I've already fixed using this method, thinking that the ASM section below would show the translation of what was done in HLSL to achieve the fix, but unfortunately the ASM code does not reflect with what I did in the HLSL code. Is there any other way I can recompile some HLSL code to see how it would appear in ASM? Any other suggestions? I can include the code if anyone wants to look, but it's over 2000 lines of code, so I'll hold off unless it's necessary.
Need some help (if what I need is even possible)!

I think I'm on the verge of fixing the lighting in Ryse's compute shader that's causing directional lighting to be in 2D. I've found a section where doing the stereo adjustment causes the lighting to separate in different directions in relation to player/camera position, so I'm pretty sure I just need to convert the coordinates to projection space before doing the fix, and then back. The good news is that there is a VPM in the shader, however the bad news is there is no iVPM... annnnd being as it's a compute shader, I'm having to work with the ASM code, and therefore I have no idea how to use DarkStarSwords matrix.hlsl shader to do the inverse, or whether it's even possible.

I just had the idea of redumping a different shader that I've already fixed using this method, thinking that the ASM section below would show the translation of what was done in HLSL to achieve the fix, but unfortunately the ASM code does not reflect with what I did in the HLSL code. Is there any other way I can recompile some HLSL code to see how it would appear in ASM?

Any other suggestions? I can include the code if anyone wants to look, but it's over 2000 lines of code, so I'll hold off unless it's necessary.

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 06/15/2016 10:17 AM   
I remember helifax having a problem with something at angles, I'm not sure if it's even remotely related though, especially since it was GLSL. It's all French to me, but DSS replied with a solution that he had only ever used a few times before, once before in The Last Tinkerer. [url=https://forums.geforce.com/default/topic/766890/3d-vision/bo3bs-school-for-shaderhackers/post/4878897/#4878897]find it here[/url] If nothing else, you can file the answer in the memory bank for later.
I remember helifax having a problem with something at angles, I'm not sure if it's even remotely related though, especially since it was GLSL. It's all French to me, but DSS replied with a solution that he had only ever used a few times before, once before in The Last Tinkerer. find it here If nothing else, you can file the answer in the memory bank for later.

Posted 06/15/2016 10:50 AM   
Y'know what D-Man11, I think that just might work! The shader I'm working with does have the frustum corners data defined, so I believe I'm able to adapt that calculation here. Big thanks for pointing that out, I'll report back how it works when I've worked it out and tested. Edit: Damn, no go. I converted the formula to ASM, and it moves the lighting in the same direction in both eyes. ie. No separation. I'll include my code conversion in case someone can see if I made a mistake, but I think it's solid. [code] //Header where I obtain Frustum buffer values cbuffer PER_BATCH : register(b0) { float4 FrustumTL : packoffset(c0); float4 FrustumBL : packoffset(c1); float4 WorldViewPos : packoffset(c2); float4 ProjParams : packoffset(c3); float4 SunDir : packoffset(c4); float4 SSDOParams : packoffset(c5); float4 FrustumTR : packoffset(c6); float4 ScreenSize : packoffset(c7); } // Frustum corners appear to be in _fa_freqLow[0,1,3,4], let's use 0 & 1 as the top two corners: //vec3 camera_horizontal_world = _fa_freqLow[1].xyz - _fa_freqLow[0].xyz; add r27.xyz, cb0[6].xyz, -cb0[0].xyz // In this case I think that the frustum is already a unit distance from the // camera, otherwise it would need to be rescaled. // Find the width of the frustum using Pythagorus: //float frustum_width = sqrt(dot3(camera_horizontal_world.xyz, camera_horizontal_world.xyz)); dp3 r27.w, r27.xyz, r27.xyz sqrt r27.w, r27.w // Calculate the horizontal unit vector: //vec3 camera_horizontal_world_normalized = camera_horizontal_world / frustum_width; div r27.xyz, r27.xyz, r27.w // Calculate the stereo adjustment magnitude, using frustum_width/2 in place of // tan(fov_horizontal / 2) normally obtained from the inverse projection matrix: // float adjustment_magnitude = g_eye * g_eye_separation * (zLinear - g_convergence) * frustum_width / 2; ld_indexable(texture2d)(float,float,float,float) r29.xyzw, l(0, 0, 0, 0), t125.xyzw add r29.w, r10.z, -r29.y mul r29.w, r29.x, r29.w mul r29.w, r29.w, r27.w div r29.w, r29.w, l(2) // World space adjustment is just the magitude * horizontal: //world_pos.xyz -= adjustment_magnitude * camera_horizontal_world_normalized mad r10.xyz, -r27.xyz, r29.www, r10.xyz [/code] And in case anyone wants to look at the shader itself: ASM only - [url]https://www.mediafire.com/?2kr0c0l2an6zl1i[/url] HLSL too - [url]https://www.mediafire.com/?2kr0c0l2an6zl1i[/url] My fix attempts begin at line 1110 in ASM only file.
Y'know what D-Man11, I think that just might work! The shader I'm working with does have the frustum corners data defined, so I believe I'm able to adapt that calculation here. Big thanks for pointing that out, I'll report back how it works when I've worked it out and tested.

Edit: Damn, no go. I converted the formula to ASM, and it moves the lighting in the same direction in both eyes. ie. No separation.

I'll include my code conversion in case someone can see if I made a mistake, but I think it's solid.

//Header where I obtain Frustum buffer values
cbuffer PER_BATCH : register(b0)
{
float4 FrustumTL : packoffset(c0);
float4 FrustumBL : packoffset(c1);
float4 WorldViewPos : packoffset(c2);
float4 ProjParams : packoffset(c3);
float4 SunDir : packoffset(c4);
float4 SSDOParams : packoffset(c5);
float4 FrustumTR : packoffset(c6);
float4 ScreenSize : packoffset(c7);
}

// Frustum corners appear to be in _fa_freqLow[0,1,3,4], let's use 0 & 1 as the top two corners:
//vec3 camera_horizontal_world = _fa_freqLow[1].xyz - _fa_freqLow[0].xyz;
add r27.xyz, cb0[6].xyz, -cb0[0].xyz

// In this case I think that the frustum is already a unit distance from the
// camera, otherwise it would need to be rescaled.

// Find the width of the frustum using Pythagorus:
//float frustum_width = sqrt(dot3(camera_horizontal_world.xyz, camera_horizontal_world.xyz));
dp3 r27.w, r27.xyz, r27.xyz
sqrt r27.w, r27.w

// Calculate the horizontal unit vector:
//vec3 camera_horizontal_world_normalized = camera_horizontal_world / frustum_width;
div r27.xyz, r27.xyz, r27.w

// Calculate the stereo adjustment magnitude, using frustum_width/2 in place of
// tan(fov_horizontal / 2) normally obtained from the inverse projection matrix:
// float adjustment_magnitude = g_eye * g_eye_separation * (zLinear - g_convergence) * frustum_width / 2;

ld_indexable(texture2d)(float,float,float,float) r29.xyzw, l(0, 0, 0, 0), t125.xyzw
add r29.w, r10.z, -r29.y
mul r29.w, r29.x, r29.w
mul r29.w, r29.w, r27.w
div r29.w, r29.w, l(2)

// World space adjustment is just the magitude * horizontal:
//world_pos.xyz -= adjustment_magnitude * camera_horizontal_world_normalized
mad r10.xyz, -r27.xyz, r29.www, r10.xyz



And in case anyone wants to look at the shader itself:
ASM only - https://www.mediafire.com/?2kr0c0l2an6zl1i
HLSL too - https://www.mediafire.com/?2kr0c0l2an6zl1i

My fix attempts begin at line 1110 in ASM only file.

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 06/15/2016 06:55 PM   
It moves the effect in both eyes in the same direction? That is weird... Is this a compute shader? or a VS/PS? I've seen this before in CS only... If is PS/VS then most likely the location where the modification is done is not right:( If is a CS... most likely this is not the CS shader you are looking for, but another CS shader "calling" this one. I had the same problem in ROTTR and DSS used Frame Analysis to figure out what the real CS shaders was that was calling my CS shader... Don't know how much this helps but is good to keep it in mind if everything else fails. I looked at the code and I can't spot anything wrong, although I am not the most versed in these matters:(
It moves the effect in both eyes in the same direction? That is weird... Is this a compute shader? or a VS/PS?
I've seen this before in CS only... If is PS/VS then most likely the location where the modification is done is not right:(

If is a CS... most likely this is not the CS shader you are looking for, but another CS shader "calling" this one. I had the same problem in ROTTR and DSS used Frame Analysis to figure out what the real CS shaders was that was calling my CS shader... Don't know how much this helps but is good to keep it in mind if everything else fails.

I looked at the code and I can't spot anything wrong, although I am not the most versed in these matters:(

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 06/15/2016 09:30 PM   
It's a compute shader, and in case you were thinking this might be the solution, I've already added the 0x00004000 bit to the StereoFlagsDX10 setting in the Nvidia profile, which was necessary to get the game to not have one eye blanked out. If I just try a standard stereo correction, I do get the lighting to separate, but not in relation to the screen, so I think it's the correct spot but I'm pretty sure it's a world space coordinate. It's when I attempted this other method to calculate the magnitude via the frustum corners to create the world space adjustment that the lighting moves in the same direction in both eyes, which is a bit strange because it's being multiplied by the stereo separation in the calculation.
It's a compute shader, and in case you were thinking this might be the solution, I've already added the 0x00004000 bit to the StereoFlagsDX10 setting in the Nvidia profile, which was necessary to get the game to not have one eye blanked out.

If I just try a standard stereo correction, I do get the lighting to separate, but not in relation to the screen, so I think it's the correct spot but I'm pretty sure it's a world space coordinate.

It's when I attempted this other method to calculate the magnitude via the frustum corners to create the world space adjustment that the lighting moves in the same direction in both eyes, which is a bit strange because it's being multiplied by the stereo separation in the calculation.

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 06/15/2016 09:41 PM   
Yes, that's exactly what I am trying to say;) Because it moves in the same dirrection in both eyes that means the CS is not executed one time for each frame;) So, most likely there is another Shader (CS probably) that is using the OUTPUT of this shader to render;) Hope this makes sense;) Now, how to find the other shader, based on what DSS told me and used in ROTTR is to use Frame analysis and see what other CS is using this shader;)
Yes, that's exactly what I am trying to say;)
Because it moves in the same dirrection in both eyes that means the CS is not executed one time for each frame;)
So, most likely there is another Shader (CS probably) that is using the OUTPUT of this shader to render;)

Hope this makes sense;)
Now, how to find the other shader, based on what DSS told me and used in ROTTR is to use Frame analysis and see what other CS is using this shader;)

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 06/15/2016 11:19 PM   
  72 / 143    
Scroll To Top