The first one is tile lighting - there is going to be a second adjustment needed for these needed to tell the compute shader which lights are candidates for which tiles. This may be elsewhere in the same shader, but could just as easily be in a completely different shader that you need to use the frame analysis log file to locate, or if it's anything like Arkham Knight could even come from the CPU making things rather tricky. In this case I'd start by studying the resources passed into the shader, especially the buffers. Dump them out, study them in a hex editor, throw my constant buffer debug shader at them to see them live, trace them through frame analysis - whatever you can think of to try to learn what they are for.
In the second one are there any "discard" instructions in the pixel shader? If so, comment them out to start with until the vertices are positioned correctly.
The first one is tile lighting - there is going to be a second adjustment needed for these needed to tell the compute shader which lights are candidates for which tiles. This may be elsewhere in the same shader, but could just as easily be in a completely different shader that you need to use the frame analysis log file to locate, or if it's anything like Arkham Knight could even come from the CPU making things rather tricky. In this case I'd start by studying the resources passed into the shader, especially the buffers. Dump them out, study them in a hex editor, throw my constant buffer debug shader at them to see them live, trace them through frame analysis - whatever you can think of to try to learn what they are for.
In the second one are there any "discard" instructions in the pixel shader? If so, comment them out to start with until the vertices are positioned correctly.
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
[quote="Helifax"]So I tried different things in that shader. Nothing works.
Close I came is this:
[code]
// ---- Created with 3Dmigoto v1.2.66 on Sat Oct 28 12:26:20 2017
cbuffer _Globals : register(b0)
{
float3 LightDir : packoffset(c0);
float4x4 ShadowVolumeTransform : packoffset(c1);
float4 Unproject : packoffset(c5);
float4x4 EyeToLightSpace : packoffset(c6);
float2 CascadeShadowSettings : packoffset(c10);
float CascadeIndex : packoffset(c10.z);
float CascadeShadowMapSize : packoffset(c10.w);
float2 RcpDeferredShadowMapSize : packoffset(c11);
}
SamplerComparisonState SmpLessClampLinear_s : register(s0);
Texture2D<float> LinearDepth : register(t0);
Texture2DArray<float> CascadeShadowMap : register(t1);
// 3Dmigoto declarations
#define cmp -
Texture1D<float4> IniParams : register(t120);
Texture2D<float4> StereoParams : register(t125);
void main(
float4 v0 : SV_Position0,
out float o0 : SV_Target0)
{
float4 r0,r1,r2,r3,r4;
uint4 bitmask, uiDest;
float4 fDest;
r0.z = CascadeIndex;
r1.xy = (int2)v0.xy;
r1.zw = float2(0,0);
r1.z = LinearDepth.Load(r1.xyz).x;
//Fix
float2 vPos = v0.xy * Unproject.xy + Unproject.zw;
float4 stereo = StereoParams.Load(0);
//vPos.x += stereo.x * (r1.z / stereo.y -1);
vPos.x -= stereo.x;
r2.xy = vPos.xy;
//r2.xy = v0.xy * Unproject.xy + Unproject.zw;
r1.xy = r2.xy * r1.zz;
r1.w = 1;
r2.x = dot(r1.xyzw, EyeToLightSpace._m00_m10_m20_m30);
r2.y = dot(r1.xyzw, EyeToLightSpace._m01_m11_m21_m31);
r0.w = dot(r1.xyzw, EyeToLightSpace._m02_m12_m22_m32);
r0.w = -CascadeShadowSettings.x + r0.w;
r1.xy = r2.xy * CascadeShadowMapSize + float2(0.5,0.5);
r1.zw = floor(r1.xy);
r1.xy = r1.xy + -r1.zw;
r1.zw = float2(-0.5,-0.5) + r1.zw;
r2.xy = float2(2,2) + -r1.xy;
r2.zw = -r1.yx * float2(2,2) + float2(3,3);
r2.xy = r2.xy / r2.wz;
r3.zw = float2(-1,-1) + r2.xy;
r2.xy = r1.xy * float2(2,2) + float2(1,1);
r1.xy = r1.xy / r2.xy;
r3.xy = float2(1,1) + r1.xy;
r1.x = 1 / CascadeShadowMapSize;
r4.xyzw = r3.zwxw * r1.xxxx;
r3.xyzw = r3.zyxy * r1.xxxx;
r0.xy = r1.zw * r1.xx + r4.zw;
r4.xy = r1.zw * r1.xx + r4.xy;
r0.x = CascadeShadowMap.SampleCmpLevelZero(SmpLessClampLinear_s, r0.xyz, r0.w).x;
r0.yz = r2.xy * r2.zw;
r1.y = r2.w * r2.z;
r2.x = r2.x * r2.y;
r0.x = r0.y * r0.x;
r4.z = CascadeIndex;
r0.y = CascadeShadowMap.SampleCmpLevelZero(SmpLessClampLinear_s, r4.xyz, r0.w).x;
r0.x = r1.y * r0.y + r0.x;
r4.xy = r1.zw * r1.xx + r3.xy;
r1.xy = r1.zw * r1.xx + r3.zw;
r4.z = CascadeIndex;
r0.y = CascadeShadowMap.SampleCmpLevelZero(SmpLessClampLinear_s, r4.xyz, r0.w).x;
r0.x = r0.z * r0.y + r0.x;
r1.z = CascadeIndex;
r0.y = CascadeShadowMap.SampleCmpLevelZero(SmpLessClampLinear_s, r1.xyz, r0.w).x;
r0.x = r2.x * r0.y + r0.x;
o0.x = 0.0625 * r0.x;
return;
}
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Original ASM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[/code]
Shadows are in 3D but it seems they are pushed at infinity. They look OK in the background but too much separation near the character. This is because I only use the stereo separation.
Weird thing is that normally things are the other way around: They look ok close, but not far.
Again, I am running out of ideas :(
One thing to note: "vPos.x += stereo.x * (r1.z / stereo.y -1);" GIVES the EXACT same result as "vPos.x -= stereo.x;"
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/73940/[/img]
[/quote]
[quote]
DHR, I already tried all of this and already told you it doesn't work! Don't you think I wouldn't ask for help it was so "trivial" ? :) I tried all of the ABC of shadow fixing, including inverting the "EyeToLightSpace" matrix (I have no idea in what space that is.) I said "F@ck it, let's try". Also other fancy and much more complicated stuff;) I even tried to get the damn Projection Matrix from a different VS to apply the damn FOV.
The formula breaks the shadows completely (as the depth is wrong)
[/quote]
You should be correcting r1 right before the EyeToLightSpace matrix transformation. If you look at the shader you can see that all the depth map comparison are being done against r0.w. r0 is derived by transforming r1 from view space to light space. The EyeToLightSpace basically converts the coordinates that are in view space (relative to the screen before projection) to light space (which is basically a view of the scene but from the p.o.v of the light). It's safe to assume that r1 is the vertex coordinates in view space since it's being transformed by the EyeToLightSpace matrix. So you'll want to calculate your stereo offsets in view space. Something like this:
[code]
r1.xy = r2.xy * r1.zz;
r1.w = 1;
float4 stereo = StereoParams.Load(0);
r1.x -= stereo.x * (r1.z- stereo.y)/m_matProjection._m00; // assuming you have access to the projection matrix
r2.x = dot(r1.xyzw, EyeToLightSpace._m00_m10_m20_m30);
r2.y = dot(r1.xyzw, EyeToLightSpace._m01_m11_m21_m31);
r0.w = dot(r1.xyzw, EyeToLightSpace._m02_m12_m22_m32);
r0.w = -CascadeShadowSettings.x + r0.w;
[/code]
[quote]
@mx-2:
I think is onto something there;)) And this is exactly what I believe is happening!
Have you tried dumping the CB constants (Frame Analysis? If I remember right, I think Unproject.x is 0.916 something) I think we need to use those "Unprojects" to correctly scale the depth buffer!
[/quote]
I don't think you should need to scale the depth buffer. It's already linear and it look like all the depth map comparisons are also done linearly since there are no scaling factors like far clip.
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Original ASM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Shadows are in 3D but it seems they are pushed at infinity. They look OK in the background but too much separation near the character. This is because I only use the stereo separation.
Weird thing is that normally things are the other way around: They look ok close, but not far.
Again, I am running out of ideas :(
One thing to note: "vPos.x += stereo.x * (r1.z / stereo.y -1);" GIVES the EXACT same result as "vPos.x -= stereo.x;"
DHR, I already tried all of this and already told you it doesn't work! Don't you think I wouldn't ask for help it was so "trivial" ? :) I tried all of the ABC of shadow fixing, including inverting the "EyeToLightSpace" matrix (I have no idea in what space that is.) I said "F@ck it, let's try". Also other fancy and much more complicated stuff;) I even tried to get the damn Projection Matrix from a different VS to apply the damn FOV.
The formula breaks the shadows completely (as the depth is wrong)
You should be correcting r1 right before the EyeToLightSpace matrix transformation. If you look at the shader you can see that all the depth map comparison are being done against r0.w. r0 is derived by transforming r1 from view space to light space. The EyeToLightSpace basically converts the coordinates that are in view space (relative to the screen before projection) to light space (which is basically a view of the scene but from the p.o.v of the light). It's safe to assume that r1 is the vertex coordinates in view space since it's being transformed by the EyeToLightSpace matrix. So you'll want to calculate your stereo offsets in view space. Something like this:
r1.xy = r2.xy * r1.zz;
r1.w = 1;
float4 stereo = StereoParams.Load(0);
r1.x -= stereo.x * (r1.z- stereo.y)/m_matProjection._m00; // assuming you have access to the projection matrix
@mx-2:
I think is onto something there;)) And this is exactly what I believe is happening!
Have you tried dumping the CB constants (Frame Analysis? If I remember right, I think Unproject.x is 0.916 something) I think we need to use those "Unprojects" to correctly scale the depth buffer!
I don't think you should need to scale the depth buffer. It's already linear and it look like all the depth map comparisons are also done linearly since there are no scaling factors like far clip.
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z
@sgsrules:
That doesn't work. It was, I think the first thing I tried (or among the first to try). Even if you don't have access to the FOV (Projection Matrix) you can try some hard-coded values. Using only this part
[code]
r1.x -= stereo.x * (r1.z- stereo.y)
[/code]
makes one eye in shadow and one outside. Trying a value of 0.086 for the "FOV" makes a difference, but they still don't show in both eyes (The separation is huge).
This is way I believe the depth buffer is not scaled correctly.
@sgsrules:
That doesn't work. It was, I think the first thing I tried (or among the first to try). Even if you don't have access to the FOV (Projection Matrix) you can try some hard-coded values. Using only this part
r1.x -= stereo.x * (r1.z- stereo.y)
makes one eye in shadow and one outside. Trying a value of 0.086 for the "FOV" makes a difference, but they still don't show in both eyes (The separation is huge).
This is way I believe the depth buffer is not scaled correctly.
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
[quote="DarkStarSword"]The first one is tile lighting - there is going to be a second adjustment needed for these needed to tell the compute shader which lights are candidates for which tiles. This may be elsewhere in the same shader, but could just as easily be in a completely different shader that you need to use the frame analysis log file to locate, or if it's anything like Arkham Knight could even come from the CPU making things rather tricky. In this case I'd start by studying the resources passed into the shader, especially the buffers. Dump them out, study them in a hex editor, throw my constant buffer debug shader at them to see them live, trace them through frame analysis - whatever you can think of to try to learn what they are for.[/quote]I looked at some of those buffers a found some candidates. How would they look like in the frame analysis look? In my case there are lots of VS and PS listed in the log but no CS. Some of that shaders have the same buffer hashes as inputs but none of them writes to them as a render target. Does that mean they are coming from the CPU?
[quote="DarkStarSword"]In the second one are there any "discard" instructions in the pixel shader? If so, comment them out to start with until the vertices are positioned correctly.[/quote]OK, that solved the strange behaviour. Vertex shader looks good now.
[quote="Helifax"]@sgsrules:
That doesn't work. It was, I think the first thing I tried (or among the first to try). Even if you don't have access to the FOV (Projection Matrix) you can try some hard-coded values. Using only this part
[code]
r1.x -= stereo.x * (r1.z- stereo.y)
[/code]
makes one eye in shadow and one outside. Trying a value of 0.086 for the "FOV" makes a difference, but they still don't show in both eyes (The separation is huge).
This is way I believe the depth buffer is not scaled correctly.[/quote]There is definitely something wrong with the depth buffer scale. This would be very similar to the "Risen" series from the same developer where the sampled depth was multiplied with a constant in the original shaders.
In ELEX, these magic constants are the key to a fix. They are needed for everything including shadows, point lights, decals and maybe other things and have different values in every shader - in case of decals they are even different between every decal in the same shader.
DarkStarSword said:The first one is tile lighting - there is going to be a second adjustment needed for these needed to tell the compute shader which lights are candidates for which tiles. This may be elsewhere in the same shader, but could just as easily be in a completely different shader that you need to use the frame analysis log file to locate, or if it's anything like Arkham Knight could even come from the CPU making things rather tricky. In this case I'd start by studying the resources passed into the shader, especially the buffers. Dump them out, study them in a hex editor, throw my constant buffer debug shader at them to see them live, trace them through frame analysis - whatever you can think of to try to learn what they are for.
I looked at some of those buffers a found some candidates. How would they look like in the frame analysis look? In my case there are lots of VS and PS listed in the log but no CS. Some of that shaders have the same buffer hashes as inputs but none of them writes to them as a render target. Does that mean they are coming from the CPU?
DarkStarSword said:In the second one are there any "discard" instructions in the pixel shader? If so, comment them out to start with until the vertices are positioned correctly.
OK, that solved the strange behaviour. Vertex shader looks good now.
Helifax said:@sgsrules:
That doesn't work. It was, I think the first thing I tried (or among the first to try). Even if you don't have access to the FOV (Projection Matrix) you can try some hard-coded values. Using only this part
r1.x -= stereo.x * (r1.z- stereo.y)
makes one eye in shadow and one outside. Trying a value of 0.086 for the "FOV" makes a difference, but they still don't show in both eyes (The separation is huge).
This is way I believe the depth buffer is not scaled correctly.
There is definitely something wrong with the depth buffer scale. This would be very similar to the "Risen" series from the same developer where the sampled depth was multiplied with a constant in the original shaders.
In ELEX, these magic constants are the key to a fix. They are needed for everything including shadows, point lights, decals and maybe other things and have different values in every shader - in case of decals they are even different between every decal in the same shader.
[quote="mx-2"]I looked at some of those buffers a found some candidates. How would they look like in the frame analysis look? In my case there are lots of VS and PS listed in the log but no CS. Some of that shaders have the same buffer hashes as inputs but none of them writes to them as a render target. Does that mean they are coming from the CPU?[/quote]
You only want to look at the log.txt in the frame analysis, and ignore the buffer hashes - you are only interested in the handles (memory addresses) when doing this type of tracing.
First, search the log.txt for the shader hash (should appear at the end of a CSSetShader line), then notice the number at the very start of the line - this is the draw call number and you will see a bunch of lines around this point with the same number, the last of which will be the actual Dispatch() call that runs the compute shader.
Find the CSSetShaderResources call with the matching draw call number, and you will see a list of resources that were bound using that call by register number just below it, which will hopefully include the buffer you are tracing. Sometimes there may be multiple CSSetShaderResources calls (one for each resource) instead, but the idea is the same. If you don't see any matching CSSetShaderResources call on this draw call number, start searching backwards in the file for the most recent one that set this resource.
Note down the handle of that resource, which is the hex string after "resource=0x...", then search for it starting from that point and working backwards to find out where it came from.
You will likely find it was used in an earlier CSSetUnorderedAccessViews call - if so, note the new draw call number from this line and find the corresponding CSSetShader call to find the shader hash that populated it. This will also tell you which u register it was used as in this shader.
If you instead find it was used in a Map or UpdateSubresource call it has come from the CPU, in which case things get very complicated as you won't be able to adjust the code that populated it. In Arkham Knight I wrote a custom compute shader to process the list from the CPU and merge lights into adjacent tiles to solve this (trivia: this is the origin of the [CustomShader] feature in 3DMigoto), but this was a very game specific effect and I'm not expecting to see many other games doing it in this way.
Occasionally you may also find it has gone through a CopyResource or CopySubresourceRegion call, which will tell you the resource it was copied from allowing you to continue your search using the source handle.
Sometimes you may find that the same buffer has been used in multiple earlier shaders - your goal is generally to find the most recent one that actually updated it, as some of these may only be reading it.
mx-2 said:I looked at some of those buffers a found some candidates. How would they look like in the frame analysis look? In my case there are lots of VS and PS listed in the log but no CS. Some of that shaders have the same buffer hashes as inputs but none of them writes to them as a render target. Does that mean they are coming from the CPU?
You only want to look at the log.txt in the frame analysis, and ignore the buffer hashes - you are only interested in the handles (memory addresses) when doing this type of tracing.
First, search the log.txt for the shader hash (should appear at the end of a CSSetShader line), then notice the number at the very start of the line - this is the draw call number and you will see a bunch of lines around this point with the same number, the last of which will be the actual Dispatch() call that runs the compute shader.
Find the CSSetShaderResources call with the matching draw call number, and you will see a list of resources that were bound using that call by register number just below it, which will hopefully include the buffer you are tracing. Sometimes there may be multiple CSSetShaderResources calls (one for each resource) instead, but the idea is the same. If you don't see any matching CSSetShaderResources call on this draw call number, start searching backwards in the file for the most recent one that set this resource.
Note down the handle of that resource, which is the hex string after "resource=0x...", then search for it starting from that point and working backwards to find out where it came from.
You will likely find it was used in an earlier CSSetUnorderedAccessViews call - if so, note the new draw call number from this line and find the corresponding CSSetShader call to find the shader hash that populated it. This will also tell you which u register it was used as in this shader.
If you instead find it was used in a Map or UpdateSubresource call it has come from the CPU, in which case things get very complicated as you won't be able to adjust the code that populated it. In Arkham Knight I wrote a custom compute shader to process the list from the CPU and merge lights into adjacent tiles to solve this (trivia: this is the origin of the [CustomShader] feature in 3DMigoto), but this was a very game specific effect and I'm not expecting to see many other games doing it in this way.
Occasionally you may also find it has gone through a CopyResource or CopySubresourceRegion call, which will tell you the resource it was copied from allowing you to continue your search using the source handle.
Sometimes you may find that the same buffer has been used in multiple earlier shaders - your goal is generally to find the most recent one that actually updated it, as some of these may only be reading it.
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
@DarkStarSword
Very bad news. If I'm not totally wrong, the errornous buffer comes from a Map() call:(
I managed to fix those artifacts around players head and some other objects but those clipping issue in the distance light remains.
For now, I give up on this since nothing in this game works as it should do. See [url=https://forums.geforce.com/default/topic/1026753/3d-vision/elex/post/5236740/#5236740]this post[/url] for details.
Nonetheless, big thank you for answering my questions.
@DarkStarSword
Very bad news. If I'm not totally wrong, the errornous buffer comes from a Map() call:(
I managed to fix those artifacts around players head and some other objects but those clipping issue in the distance light remains.
For now, I give up on this since nothing in this game works as it should do. See this post for details.
Nonetheless, big thank you for answering my questions.
I want to share something that I found a while ago, then forgot about it, only to re-discover it last night:))
So far, I only tested it on Frostbite3 games, but the math should work on any game.
For picture comparison I will use Mass Effect Andromeda.
Like you know, many games have a particular problem to the sky-box, namely being MONO.
Without any fixing by default the sky looks like this:
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/74021/[/img]
Once you find the VS shader and you apply the stereo formula on it the sky starts rendering perfectly in stereo 3D, but with a catch! (The black borders on the side of the monitors!) All of us has seen this at least one in our games:)
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/74019/[/img]
So, here comes the challenge! Having a stereo Sky-box but without the damn annoying BLACK bars right?
As we all know, the straight-forward approach would be to leave the VS mono, find the PS and stereo correct the "position" there (or Texcoord used for sampling the texture)! And this also works, if you have the headers in the shaders and so on...
ME:A doesn't have any of the shader headers. Doing this was much more difficult that I anticipated, thus, I was thinking of finding an easy hack for this problem that includes only the Vertex Shader.
And it seems there is something we can do about it:)
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/74020/[/img]
Since we are talking about the skybox (which is always at infinity) the normal stereo correction would be something like:
[code]
o0.x += separation * depth;
[/code]
ME:A only requires
[code]
o0.x += separation;
[/code]
And we get this image:
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/74019/[/img]
One thing I did find out by experimentation is this:
[code]
o0.x += separation;
o0.x *= 1.15; // Value is based on trial & error
[/code]
This will remove the black pillars on the side of the monitor, but also breaks the stereo (The stereo is too "strong" and the skybox is not in the "right place").
So, then we need to counteract this multiplication. This can be done easily in the stereo formula.
The code then becomes:
[code]
o0.x += separation * 0.88; // Value is based on trial & error
o0.x *= 1.15; // Value is based on trial & error
[/code]
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/74022/[/img]
However, upon closer inspection, the fact that we only multiplied the X component of the vertex position also skewed the "look" of the sky (is elongated horizontally).
In order to fix this we need to do the following:
[code]
o0.x += separation * 0.88; // Value is based on trial & error
// Notice the x, y, z components
o0.xyz *= 1.15; // Value is based on trial & error.
[/code]
And this time we get the properly aligned skybox in stereo 3D without side-effects:)
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/74020/[/img]
Hope this helps any shaderhacker who fixes skyboxes (What looks like a trivial matter, but can have a big impact on the experience:) )
Cheers,
Helifax
I want to share something that I found a while ago, then forgot about it, only to re-discover it last night:))
So far, I only tested it on Frostbite3 games, but the math should work on any game.
For picture comparison I will use Mass Effect Andromeda.
Like you know, many games have a particular problem to the sky-box, namely being MONO.
Without any fixing by default the sky looks like this:
Once you find the VS shader and you apply the stereo formula on it the sky starts rendering perfectly in stereo 3D, but with a catch! (The black borders on the side of the monitors!) All of us has seen this at least one in our games:)
So, here comes the challenge! Having a stereo Sky-box but without the damn annoying BLACK bars right?
As we all know, the straight-forward approach would be to leave the VS mono, find the PS and stereo correct the "position" there (or Texcoord used for sampling the texture)! And this also works, if you have the headers in the shaders and so on...
ME:A doesn't have any of the shader headers. Doing this was much more difficult that I anticipated, thus, I was thinking of finding an easy hack for this problem that includes only the Vertex Shader.
And it seems there is something we can do about it:)
Since we are talking about the skybox (which is always at infinity) the normal stereo correction would be something like:
o0.x += separation * depth;
ME:A only requires
o0.x += separation;
And we get this image:
One thing I did find out by experimentation is this:
o0.x += separation;
o0.x *= 1.15; // Value is based on trial & error
This will remove the black pillars on the side of the monitor, but also breaks the stereo (The stereo is too "strong" and the skybox is not in the "right place").
So, then we need to counteract this multiplication. This can be done easily in the stereo formula.
The code then becomes:
o0.x += separation * 0.88; // Value is based on trial & error
o0.x *= 1.15; // Value is based on trial & error
However, upon closer inspection, the fact that we only multiplied the X component of the vertex position also skewed the "look" of the sky (is elongated horizontally).
In order to fix this we need to do the following:
o0.x += separation * 0.88; // Value is based on trial & error
// Notice the x, y, z components
o0.xyz *= 1.15; // Value is based on trial & error.
And this time we get the properly aligned skybox in stereo 3D without side-effects:)
Hope this helps any shaderhacker who fixes skyboxes (What looks like a trivial matter, but can have a big impact on the experience:) )
Cheers,
Helifax
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
What I did with one fake 2D light in DMC4SE was calculating how much stretching I needed to do to cover that cutoff, depending on separation (I don't remember the formula. It's there in my fix). Being stretched almost doesn't matter because it isn't a skybox.
Your discovery is nice for screen depth skyboxes.
In Zelda OOT, I remember that multiplying the xyz values of the skybox (a cube placed on top of you, very near the camera) worked great. It made the box be bigger, and thus farther from the camera. I haven't used that trick since forever because I didn't need it in PC games since then.
Gothic 2 will be my guinea pig, I think :). It's almost the only game I fixed that needs a new method (Gothic 1 too).
I'm on a phone so: did you lose any part of the sky? I mean, with F9 in 2D, is there any difference?
What I did with one fake 2D light in DMC4SE was calculating how much stretching I needed to do to cover that cutoff, depending on separation (I don't remember the formula. It's there in my fix). Being stretched almost doesn't matter because it isn't a skybox.
Your discovery is nice for screen depth skyboxes.
In Zelda OOT, I remember that multiplying the xyz values of the skybox (a cube placed on top of you, very near the camera) worked great. It made the box be bigger, and thus farther from the camera. I haven't used that trick since forever because I didn't need it in PC games since then.
Gothic 2 will be my guinea pig, I think :). It's almost the only game I fixed that needs a new method (Gothic 1 too).
I'm on a phone so: did you lose any part of the sky? I mean, with F9 in 2D, is there any difference?
Some small addition to the Skybox topic:
Some games like Risen 3 or ELEX seem to generate the clouds on the fly with some kind of perlin noise algorithm - and may use world coordinates for the sky. In this case, an adjustment to the vertex shader output position and most adjustments in the pixel shader lead to corruption or different cloud patterns between left and right eye.
This type of sky(box?) can to be fixed by adjusting a texcoord in the vertex shader which looks like a "colorful world coordinate system" if you output it from the pixel shader.
Example (from ELEX):[code]
void main(
float4 v0 : POSITION0,
float2 v1 : TEXCOORD0,
out float4 o0 : SV_Position0,
out float2 o1 : TEXCOORD0,
out float3 o2 : EYE0)
{
float4 r0,r1;
uint4 bitmask, uiDest;
float4 fDest;
o0.xyw = v0.xyw;
o0.z = 1;
o1.xy = v1.xy;
r0.xy = v1.xy * float2(2,-2) + float2(-1,1);
r0.z = 1;
// o2 looks like world coordinate system on screen depth
// this must pushed to infinity to fix the sky - same as in Risen 3
float4 stereo = StereoParams.Load(0);
r0.x -= stereo.x;
r1.x = dot(r0.xyz, ReprojectEye._m00_m10_m30);
r1.y = dot(r0.xyz, ReprojectEye._m01_m11_m31);
r1.z = dot(r0.xyz, ReprojectEye._m02_m12_m32);
r0.x = dot(r0.xyz, ReprojectEye._m03_m13_m33);
o2.xyz = r1.xyz / r0.xxx;
return;
}
[/code]
Sorry, I don't have any piuctures at hand right now.
Edit: Added picture of the "colorful world coordinate system":
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/74029/[/img]
Some games like Risen 3 or ELEX seem to generate the clouds on the fly with some kind of perlin noise algorithm - and may use world coordinates for the sky. In this case, an adjustment to the vertex shader output position and most adjustments in the pixel shader lead to corruption or different cloud patterns between left and right eye.
This type of sky(box?) can to be fixed by adjusting a texcoord in the vertex shader which looks like a "colorful world coordinate system" if you output it from the pixel shader.
// o2 looks like world coordinate system on screen depth
// this must pushed to infinity to fix the sky - same as in Risen 3
float4 stereo = StereoParams.Load(0);
r0.x -= stereo.x;
That's the same type of code as lighting and shadows in some games I fixed, and it moved them from screen depth to proper depth. What happens to the sky if you do this in that shader?:
[code]
void main(
float4 v0 : POSITION0,
float2 v1 : TEXCOORD0,
out float4 o0 : SV_Position0,
out float2 o1 : TEXCOORD0,
out float3 o2 : EYE0)
{
float4 r0,r1;
uint4 bitmask, uiDest;
float4 fDest;
o0.xyw = v0.xyw;
o0.z = 1;
o1.xy = v1.xy;
r0.xy = v1.xy * float2(2,-2) + float2(-1,1);
r0.z = 1;
// o2 looks like world coordinate system on screen depth
// this must pushed to infinity to fix the sky - same as in Risen 3
float4 stereo = StereoParams.Load(0);
float4 depth = dot(r0.xyz, ReprojectEye._m03_m13_m33);
r0.x+=stereo.x*(depth*stereo.y-1);
r1.x = dot(r0.xyz, ReprojectEye._m00_m10_m30);
r1.y = dot(r0.xyz, ReprojectEye._m01_m11_m31);
r1.z = dot(r0.xyz, ReprojectEye._m02_m12_m32);
r0.x = dot(r0.xyz, ReprojectEye._m03_m13_m33);
o2.xyz = r1.xyz / r0.xxx;
return;
}
[/code]
I'm curious. Check very high convergence levels too.
That's the same type of code as lighting and shadows in some games I fixed, and it moved them from screen depth to proper depth. What happens to the sky if you do this in that shader?:
// o2 looks like world coordinate system on screen depth
// this must pushed to infinity to fix the sky - same as in Risen 3
float4 stereo = StereoParams.Load(0);
float4 depth = dot(r0.xyz, ReprojectEye._m03_m13_m33);
r0.x+=stereo.x*(depth*stereo.y-1);
r1.x = dot(r0.xyz, ReprojectEye._m00_m10_m30);
r1.y = dot(r0.xyz, ReprojectEye._m01_m11_m31);
r1.z = dot(r0.xyz, ReprojectEye._m02_m12_m32);
r0.x = dot(r0.xyz, ReprojectEye._m03_m13_m33);
o2.xyz = r1.xyz / r0.xxx;
return;
}
I'm curious. Check very high convergence levels too.
[quote="Helifax"]And this time we get the properly aligned skybox in stereo 3D without side-effects:)[/quote]
Try multiplying the X coord by (1 + abs(separation)) instead, e.g.
Skybox in Oddworld:
https://github.com/DarkStarSword/3d-fixes/commit/63ece777b23247aced5f42779da557fcce237f10
Ocean in MGSV:
https://github.com/DarkStarSword/3d-fixes/commit/a426d294fd7befe9351086d894f6f4e3ad8d4a0e
[quote="masterotaku"]That's the same type of code as lighting and shadows in some games I fixed, and it moved them from screen depth to proper depth. What happens to the sky if you do this in that shader?:
...
I'm curious. Check very high convergence levels too.[/quote]Just double checked that, in ELEX it still works at extreme convergence (~2000).
masterotaku said:That's the same type of code as lighting and shadows in some games I fixed, and it moved them from screen depth to proper depth. What happens to the sky if you do this in that shader?:
...
I'm curious. Check very high convergence levels too.
Just double checked that, in ELEX it still works at extreme convergence (~2000).
Hey guys, I have been working on World of Warcraft a bit mainly as a learning exercise and have fixed the HUD and sky-boxes so far. I have struck a problem with the Software mouse. The game has a native one but it seems that blizzard broke it some time ago in 3dvision. Now when it's on the mouse doesn't render but bizarrely it will appear in 2d when hovering over a UI element.
So I tried to use the 3dmigoto software mouse and it correctly disables the games hardware mouse but will not render at all. I feel if I fix this problem it will at least be playable again for those people that are interested.
I have successfully got it working in some other games like path of exile, so it seems like this game is doing something screwy.
Anyone got any ideas? thanks.
*eek and sorry looks like discussion has since moved from this thread.*
Hey guys, I have been working on World of Warcraft a bit mainly as a learning exercise and have fixed the HUD and sky-boxes so far. I have struck a problem with the Software mouse. The game has a native one but it seems that blizzard broke it some time ago in 3dvision. Now when it's on the mouse doesn't render but bizarrely it will appear in 2d when hovering over a UI element.
So I tried to use the 3dmigoto software mouse and it correctly disables the games hardware mouse but will not render at all. I feel if I fix this problem it will at least be playable again for those people that are interested.
I have successfully got it working in some other games like path of exile, so it seems like this game is doing something screwy.
Anyone got any ideas? thanks.
*eek and sorry looks like discussion has since moved from this thread.*
i7-4790K CPU 4.8Ghz stable overclock.
16 GB RAM Corsair
ASUS Turbo 2080TI
Samsung SSD 840Pro
ASUS Z97-WS3D
Surround ASUS Rog Swift PG278Q(R), 2x PG278Q (yes it works)
Obutto R3volution.
Windows 10 pro 64x (Windows 7 Dual boot)
Hi Necropants,
I made a small fix you can use with your fix. the main thing is I had gotten the Software mouse to work in Stereo, I also added the HUD / UI to go into Depth as well.
I disabled the Harware mouse in game settings then found the software mouse Shader and inoput the correction code there seems to have worked. I could not get the software mouse working in Stereo with Migoto so this is a workaround..
the main thing is reuse the Mouse.HLSL file in the shaderfixes folder and the shader itself which is this one "9dc1fb9d64b49602"
here is the fix I did so you can just add what you did into it or vise versa:
https://s3.amazonaws.com/nephilim3d/WoW+3D+Fix.7z
This is NOT a Complete fix so do not forget to add what you also fixed into this.. let me know if you have issues with the mouse still
I made a small fix you can use with your fix. the main thing is I had gotten the Software mouse to work in Stereo, I also added the HUD / UI to go into Depth as well.
I disabled the Harware mouse in game settings then found the software mouse Shader and inoput the correction code there seems to have worked. I could not get the software mouse working in Stereo with Migoto so this is a workaround..
the main thing is reuse the Mouse.HLSL file in the shaderfixes folder and the shader itself which is this one "9dc1fb9d64b49602"
here is the fix I did so you can just add what you did into it or vise versa:
Hmm ok that's interesting. I don't really follow what you did to fix the mouse. but I will merge that part of your fix with mine and go from there...
thanks alot. =)
*Edit*
Ok I tried your files and although it fixes the mouse on the main menu it still exhibits the same issue in game as I described previously.
Odd...
I wonder if there is another mouse shader when in game and not over a part of the UI. ODnt have time to look into this tonight.
So I removed my fix completely and used yours and the same issue occurred. There were still some broken UI bits with your fix as well.
Were you able to log into a character at all and check? if we can resolve this issue I will release my fix for anyone here that want it. High quality shadows and water may be a bonus later
Hmm ok that's interesting. I don't really follow what you did to fix the mouse. but I will merge that part of your fix with mine and go from there...
thanks alot. =)
*Edit*
Ok I tried your files and although it fixes the mouse on the main menu it still exhibits the same issue in game as I described previously.
Odd...
I wonder if there is another mouse shader when in game and not over a part of the UI. ODnt have time to look into this tonight.
So I removed my fix completely and used yours and the same issue occurred. There were still some broken UI bits with your fix as well.
Were you able to log into a character at all and check? if we can resolve this issue I will release my fix for anyone here that want it. High quality shadows and water may be a bonus later
i7-4790K CPU 4.8Ghz stable overclock.
16 GB RAM Corsair
ASUS Turbo 2080TI
Samsung SSD 840Pro
ASUS Z97-WS3D
Surround ASUS Rog Swift PG278Q(R), 2x PG278Q (yes it works)
Obutto R3volution.
Windows 10 pro 64x (Windows 7 Dual boot)
In the second one are there any "discard" instructions in the pixel shader? If so, comment them out to start with until the vertices are positioned correctly.
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
You should be correcting r1 right before the EyeToLightSpace matrix transformation. If you look at the shader you can see that all the depth map comparison are being done against r0.w. r0 is derived by transforming r1 from view space to light space. The EyeToLightSpace basically converts the coordinates that are in view space (relative to the screen before projection) to light space (which is basically a view of the scene but from the p.o.v of the light). It's safe to assume that r1 is the vertex coordinates in view space since it's being transformed by the EyeToLightSpace matrix. So you'll want to calculate your stereo offsets in view space. Something like this:
I don't think you should need to scale the depth buffer. It's already linear and it look like all the depth map comparisons are also done linearly since there are no scaling factors like far clip.
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z
That doesn't work. It was, I think the first thing I tried (or among the first to try). Even if you don't have access to the FOV (Projection Matrix) you can try some hard-coded values. Using only this part
makes one eye in shadow and one outside. Trying a value of 0.086 for the "FOV" makes a difference, but they still don't show in both eyes (The separation is huge).
This is way I believe the depth buffer is not scaled correctly.
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)
OK, that solved the strange behaviour. Vertex shader looks good now.
There is definitely something wrong with the depth buffer scale. This would be very similar to the "Risen" series from the same developer where the sampled depth was multiplied with a constant in the original shaders.
In ELEX, these magic constants are the key to a fix. They are needed for everything including shadows, point lights, decals and maybe other things and have different values in every shader - in case of decals they are even different between every decal in the same shader.
My 3D fixes with Helixmod for the Risen series on GitHub
Bo3b's School for Shaderhackers - starting point for your first 3D fix
You only want to look at the log.txt in the frame analysis, and ignore the buffer hashes - you are only interested in the handles (memory addresses) when doing this type of tracing.
First, search the log.txt for the shader hash (should appear at the end of a CSSetShader line), then notice the number at the very start of the line - this is the draw call number and you will see a bunch of lines around this point with the same number, the last of which will be the actual Dispatch() call that runs the compute shader.
Find the CSSetShaderResources call with the matching draw call number, and you will see a list of resources that were bound using that call by register number just below it, which will hopefully include the buffer you are tracing. Sometimes there may be multiple CSSetShaderResources calls (one for each resource) instead, but the idea is the same. If you don't see any matching CSSetShaderResources call on this draw call number, start searching backwards in the file for the most recent one that set this resource.
Note down the handle of that resource, which is the hex string after "resource=0x...", then search for it starting from that point and working backwards to find out where it came from.
You will likely find it was used in an earlier CSSetUnorderedAccessViews call - if so, note the new draw call number from this line and find the corresponding CSSetShader call to find the shader hash that populated it. This will also tell you which u register it was used as in this shader.
If you instead find it was used in a Map or UpdateSubresource call it has come from the CPU, in which case things get very complicated as you won't be able to adjust the code that populated it. In Arkham Knight I wrote a custom compute shader to process the list from the CPU and merge lights into adjacent tiles to solve this (trivia: this is the origin of the [CustomShader] feature in 3DMigoto), but this was a very game specific effect and I'm not expecting to see many other games doing it in this way.
Occasionally you may also find it has gone through a CopyResource or CopySubresourceRegion call, which will tell you the resource it was copied from allowing you to continue your search using the source handle.
Sometimes you may find that the same buffer has been used in multiple earlier shaders - your goal is generally to find the most recent one that actually updated it, as some of these may only be reading it.
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
Very bad news. If I'm not totally wrong, the errornous buffer comes from a Map() call:(
I managed to fix those artifacts around players head and some other objects but those clipping issue in the distance light remains.
For now, I give up on this since nothing in this game works as it should do. See this post for details.
Nonetheless, big thank you for answering my questions.
My 3D fixes with Helixmod for the Risen series on GitHub
Bo3b's School for Shaderhackers - starting point for your first 3D fix
So far, I only tested it on Frostbite3 games, but the math should work on any game.
For picture comparison I will use Mass Effect Andromeda.
Like you know, many games have a particular problem to the sky-box, namely being MONO.
Without any fixing by default the sky looks like this:
Once you find the VS shader and you apply the stereo formula on it the sky starts rendering perfectly in stereo 3D, but with a catch! (The black borders on the side of the monitors!) All of us has seen this at least one in our games:)
So, here comes the challenge! Having a stereo Sky-box but without the damn annoying BLACK bars right?
As we all know, the straight-forward approach would be to leave the VS mono, find the PS and stereo correct the "position" there (or Texcoord used for sampling the texture)! And this also works, if you have the headers in the shaders and so on...
ME:A doesn't have any of the shader headers. Doing this was much more difficult that I anticipated, thus, I was thinking of finding an easy hack for this problem that includes only the Vertex Shader.
And it seems there is something we can do about it:)
Since we are talking about the skybox (which is always at infinity) the normal stereo correction would be something like:
ME:A only requires
And we get this image:
One thing I did find out by experimentation is this:
This will remove the black pillars on the side of the monitor, but also breaks the stereo (The stereo is too "strong" and the skybox is not in the "right place").
So, then we need to counteract this multiplication. This can be done easily in the stereo formula.
The code then becomes:
However, upon closer inspection, the fact that we only multiplied the X component of the vertex position also skewed the "look" of the sky (is elongated horizontally).
In order to fix this we need to do the following:
And this time we get the properly aligned skybox in stereo 3D without side-effects:)
Hope this helps any shaderhacker who fixes skyboxes (What looks like a trivial matter, but can have a big impact on the experience:) )
Cheers,
Helifax
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)
Your discovery is nice for screen depth skyboxes.
In Zelda OOT, I remember that multiplying the xyz values of the skybox (a cube placed on top of you, very near the camera) worked great. It made the box be bigger, and thus farther from the camera. I haven't used that trick since forever because I didn't need it in PC games since then.
Gothic 2 will be my guinea pig, I think :). It's almost the only game I fixed that needs a new method (Gothic 1 too).
I'm on a phone so: did you lose any part of the sky? I mean, with F9 in 2D, is there any difference?
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
Some games like Risen 3 or ELEX seem to generate the clouds on the fly with some kind of perlin noise algorithm - and may use world coordinates for the sky. In this case, an adjustment to the vertex shader output position and most adjustments in the pixel shader lead to corruption or different cloud patterns between left and right eye.
This type of sky(box?) can to be fixed by adjusting a texcoord in the vertex shader which looks like a "colorful world coordinate system" if you output it from the pixel shader.
Example (from ELEX):
Sorry, I don't have any piuctures at hand right now.
Edit: Added picture of the "colorful world coordinate system":
My 3D fixes with Helixmod for the Risen series on GitHub
Bo3b's School for Shaderhackers - starting point for your first 3D fix
I'm curious. Check very high convergence levels too.
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
Try multiplying the X coord by (1 + abs(separation)) instead, e.g.
Skybox in Oddworld:
https://github.com/DarkStarSword/3d-fixes/commit/63ece777b23247aced5f42779da557fcce237f10
Ocean in MGSV:
https://github.com/DarkStarSword/3d-fixes/commit/a426d294fd7befe9351086d894f6f4e3ad8d4a0e
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
My 3D fixes with Helixmod for the Risen series on GitHub
Bo3b's School for Shaderhackers - starting point for your first 3D fix
So I tried to use the 3dmigoto software mouse and it correctly disables the games hardware mouse but will not render at all. I feel if I fix this problem it will at least be playable again for those people that are interested.
I have successfully got it working in some other games like path of exile, so it seems like this game is doing something screwy.
Anyone got any ideas? thanks.
*eek and sorry looks like discussion has since moved from this thread.*
i7-4790K CPU 4.8Ghz stable overclock.
16 GB RAM Corsair
ASUS Turbo 2080TI
Samsung SSD 840Pro
ASUS Z97-WS3D
Surround ASUS Rog Swift PG278Q(R), 2x PG278Q (yes it works)
Obutto R3volution.
Windows 10 pro 64x (Windows 7 Dual boot)
I made a small fix you can use with your fix. the main thing is I had gotten the Software mouse to work in Stereo, I also added the HUD / UI to go into Depth as well.
I disabled the Harware mouse in game settings then found the software mouse Shader and inoput the correction code there seems to have worked. I could not get the software mouse working in Stereo with Migoto so this is a workaround..
the main thing is reuse the Mouse.HLSL file in the shaderfixes folder and the shader itself which is this one "9dc1fb9d64b49602"
here is the fix I did so you can just add what you did into it or vise versa:
https://s3.amazonaws.com/nephilim3d/WoW+3D+Fix.7z
This is NOT a Complete fix so do not forget to add what you also fixed into this.. let me know if you have issues with the mouse still
Intel i5 7600K @ 4.8ghz / MSI Z270 SLI / Asus 1080GTX - 416.16 / Optoma HD142x Projector / 1 4'x10' Curved Screen PVC / TrackIR / HOTAS Cougar / Cougar MFD's / Track IR / NVidia 3D Vision / Win 10 64bit
thanks alot. =)
*Edit*
Ok I tried your files and although it fixes the mouse on the main menu it still exhibits the same issue in game as I described previously.
Odd...
I wonder if there is another mouse shader when in game and not over a part of the UI. ODnt have time to look into this tonight.
So I removed my fix completely and used yours and the same issue occurred. There were still some broken UI bits with your fix as well.
Were you able to log into a character at all and check? if we can resolve this issue I will release my fix for anyone here that want it. High quality shadows and water may be a bonus later
i7-4790K CPU 4.8Ghz stable overclock.
16 GB RAM Corsair
ASUS Turbo 2080TI
Samsung SSD 840Pro
ASUS Z97-WS3D
Surround ASUS Rog Swift PG278Q(R), 2x PG278Q (yes it works)
Obutto R3volution.
Windows 10 pro 64x (Windows 7 Dual boot)