Hello,
I am still stuck with the problem of the sky in DCS world (the previous post regarding the horizon problem is linked to the shader drawing the sky).
I try to make a lot of things, but I still have the sky in 2D...
I used the sun instead of horizon to check the effects of my modification, because it shows easier the problem than the horizon.
What did I try ?
At fisrt I tried to stereoize the o0 of vertex shader: no success (see DCS05_90.jps).
Then I tried to steroize the o1 and o2 part common with o0 : I had a strange result where the sun is only shifted to the left (see DCS_0390.jps)!
VS shader is here:
[code]cbuffer _Globals : register(b0)
{
float4x4 viewProjInverse : packoffset(c0);
}
Texture2D<float4> StereoParams : register(t125);
Texture1D<float4> IniParams : register(t120);
void main(
uint v0 : SV_VertexID0,
out float4 o0 : SV_POSITION0,
out float4 o1 : TEXCOORD0,
out float3 o2 : TEXCOORD1)
{
const float4 icb[] = { { -1.000000, -1.000000, 0, 0},
{ 1.000000, -1.000000, 0, 0},
{ -1.000000, 1.000000, 0, 0},
{ 1.000000, 1.000000, 0, 0} };
float4 r0;
float4 t1;
uint4 bitmask, uiDest;
float4 fDest;
float4 stereo = StereoParams.Load(0);
o0.zw = float2(0,1);
r0.x = v0.x;
o0.xy = icb[r0.x+0].xy;
//t1 added for test
t1.xy = icb[r0.x+0].xy;
// failed test to stereoize o0
// t1.x += stereo.x * (1.0 - stereo.y);
// o0.x = t1.x;
// initial line => o1.xy = icb[r0.x+0].xy * float2(0.5,0.5) + float2(0.5,0.5);
// test to steroize o1
o1.xy = t1.x * float2(0.5,0.5) + float2(0.5,0.5);
// initial line => r0.xy = icb[r0.x+0].xy;
r0.xy = t1.xy;
r0.z = 1;
o2.x = dot(r0.xyz, viewProjInverse._m00_m10_m30);
o2.y = dot(r0.xyz, viewProjInverse._m01_m11_m31);
o2.z = dot(r0.xyz, viewProjInverse._m02_m12_m32);
return;
}[/code]
After that I tried to work on pixel shader: "stereoizing" the v2 input, modifying numbers or formulas in shader : no succes !
Then I comment most of the shader to have it as simple as possible : here is the remaining code.
[code]cbuffer cbMaterialParams : register(b9)
{
float4 ShadowDistance : packoffset(c0);
float4x4 ShadowMatrix[4] : packoffset(c1);
float4x4 ShadowMatrixInv[4] : packoffset(c17);
float4 ShadowBlurFactor : packoffset(c33);
float4 ShadowLightDir : packoffset(c34);
float4 FlatShadowDistance : packoffset(c35);
float4 atmSunDirectionParam : packoffset(c36);
float4 atmEarthCenterParam : packoffset(c37);
float4 fogCoeff : packoffset(c38);
float4 fogColorParam : packoffset(c39);
float4 fogColorParam2 : packoffset(c40);
}
SamplerState gAnisotropicClampSampler_s : register(s14);
Texture2D<float4> transmittanceTex : register(t0);
Texture3D<float4> inscatterTex : register(t127);
Texture2D<float4> StereoParams : register(t125);
Texture1D<float4> IniParams : register(t120);
void main(
float4 v0 : SV_POSITION0,
float4 v1 : TEXCOORD0,
float3 v2 : TEXCOORD1,
out float4 o0 : SV_TARGET0)
{
float4 r0,r1,r2,r3;
uint4 bitmask, uiDest;
float4 fDest;
r0.x = dot(v2.xyz, v2.xyz);
r0.x = rsqrt(r0.x);
r0.xyz = v2.xyz * r0.xxx;
r0.w = dot(atmEarthCenterParam.xyz, r0.xyz);
o0.xyz = r0.yyy * r0.xzw + fogColorParam.xyz;
o0.w = 1;
return;
}[/code]
I used it with the "steroized" VS and had the following result : DCS04_90.jps. Of course there is few of the original effect, but, as for the sun, the result is not stereoscopic !
So I dont not understand why I can not have different X shift for each eye for this shader !
I already use 3dmigoto for HUD and label shader for this version of DCS and it works. Why not for this one ?
If someone can help...
Hello,
I am still stuck with the problem of the sky in DCS world (the previous post regarding the horizon problem is linked to the shader drawing the sky).
I try to make a lot of things, but I still have the sky in 2D...
I used the sun instead of horizon to check the effects of my modification, because it shows easier the problem than the horizon.
What did I try ?
At fisrt I tried to stereoize the o0 of vertex shader: no success (see DCS05_90.jps).
Then I tried to steroize the o1 and o2 part common with o0 : I had a strange result where the sun is only shifted to the left (see DCS_0390.jps)!
VS shader is here:
After that I tried to work on pixel shader: "stereoizing" the v2 input, modifying numbers or formulas in shader : no succes !
Then I comment most of the shader to have it as simple as possible : here is the remaining code.
I used it with the "steroized" VS and had the following result : DCS04_90.jps. Of course there is few of the original effect, but, as for the sun, the result is not stereoscopic !
So I dont not understand why I can not have different X shift for each eye for this shader !
I already use 3dmigoto for HUD and label shader for this version of DCS and it works. Why not for this one ?
If someone can help...
@lefuneste
Post the original VS for the Sky.
Try add the code after o0.xy (stereoize o0)
[code]float4 stereo = StereoParams.Load(0);
o0.x += stereo.x * stereo.y; [/code]
I have already try to stereoize o0, but I tried it again as you wrote above. Same results : see DCS05_90.jps : sun only shifted for one eye, but wrong positionned (the halo around sun is drawn by another shader ok for 3Dvision), and black rectangle at left side of screen.
I included the original VS and PS and my d2dx.ini in the enclosed zip (remove the jps extension)
I have already try to stereoize o0, but I tried it again as you wrote above. Same results : see DCS05_90.jps : sun only shifted for one eye, but wrong positionned (the halo around sun is drawn by another shader ok for 3Dvision), and black rectangle at left side of screen.
I included the original VS and PS and my d2dx.ini in the enclosed zip (remove the jps extension)
I saw the VS with the comments to stereoize o0, but you miss this line:
[code]float4 stereo = StereoParams.Load(0);[/code]
i don't know if you removed in the copy-paste....
edit: Sorry, i just saw the line upper in the code.
Also the sun siluette/halo have to be fixed....is in depth, but not infinite (use the same code).
I used the bda5788465aff6b0-vs_replace.txt file you post, same problem as above: see DCS05_90.jps.
By the way, DCS world 1.5b is freely downloadable, and the problems can be showned with the free plane.
I know that the sun halo is not at 100% depth, but I can not start to fix its dedicated shader until I have a solution for the sun (and horizon) shader bugs, which are much more annoying.
I used the bda5788465aff6b0-vs_replace.txt file you post, same problem as above: see DCS05_90.jps.
By the way, DCS world 1.5b is freely downloadable, and the problems can be showned with the free plane.
I know that the sun halo is not at 100% depth, but I can not start to fix its dedicated shader until I have a solution for the sun (and horizon) shader bugs, which are much more annoying.
Now you have to try different codes:
Change sign:
[code]o0.x -= stereo.x * stereo.y;[/code]
Try different values between 0.1 and 1 in "CORRECT" (with + and - sign):
[code]o0.x += stereo.x * CORRECT;[/code]
[code]o0.x -= stereo.x * CORRECT;[/code]
For example, using CORRECT = 1 (check with - sign also):
[code]o0.x += stereo.x;[/code]
[quote="YoZJik"][img]http://s016.radikal.ru/i336/1511/b2/1d0561c12193.jpg[/img]
Here is aiming by dominant eye[/quote]
Except that I'm left eye dominant, but it looks great. Is this from Tridef or a 3Dmigoto experiment?
[quote="bo3b"]
Except that I'm left eye dominant, but it looks great. Is this from Tridef or a 3Dmigoto experiment?[/quote]
3Dmigoto, 3rd pers view, Free cam ("tfc" command) and than find pozition for screenshot. ("sucsm 0.5" - set camera speed.)
This might be interesting to people - I've worked out how nvidia inject the separation and convergence into vertex shaders to apply their stereo correction.
I found this while I was adding a feature to 3DMigoto to copy vertex buffers into shaders as constant buffers (although I have since added the ability to copy them in as structured buffers, which are a lot easier to work with, but I digress - I'll cover that in more detail when I release the FC4 update that uses it). At one point I had this:
[code]
[ShaderOverrideHUD]
vs-cb12 = vb0
[/code]
Which wasn't working, but I couldn't find any reason why it wasn't working - frame analysis showed that my injected buffer was loaded in the cb12 slot and it contained the correct data copied from the correct offset from the vertex buffer, but it's values were complete garbage when I tried to use them in the shader - they weren't the values I was seeing dumped in frame analysis, but they weren't 0 either. Eventually, I tried this:
[code]
if (cb12[0].x > 0) {
o0 = 0;
return;
}
[/code]
As expected that disabled the shader... but unexpectedly it only disabled it in one eye! I then changed it to use constant buffer 11 instead and everything started working.
So, I seem to have found a constant buffer that is hidden from the CPU (frame analysis doesn't show it), but available to the GPU and appears to contain different values in each eye. And if the game happened to use constant buffer 12 itself it would be clobbered by this hidden stereo constant buffer (perhaps there is a setting somewhere to change which constant buffer it uses).
So, today I experiemented a little more with the values in constant buffer 12 and have determined that the structure seems to be:
[code]
cbuffer NVStereoCB : register(b12)
{
float nv_negative_separation_convergence;
float nv_separation;
float nv_unused;
float nv_stereo_enabled;
}
[/code]
So, the first value might look a bit weird, but it's a precomputation of the part of the formula that does not depend on the depth (I don't think it saves them any instructions though, but maybe they have another reason for doing it that way).
Seeing if we can apply this, if this is how we would usually fix a halo type issue:
[code]
...
r1.xyzw = cb2[1].xyzw * r0.yyyy;
r1.xyzw = cb2[0].xyzw * r0.xxxx + r1.xyzw;
r1.xyzw = cb2[2].xyzw * r0.zzzz + r1.xyzw;
r1.xyzw = cb2[3].xyzw * v0.wwww + r1.xyzw;
o0.xyzw = r1.xyzw;
float4 stereo = StereoParams.Load(0);
r1.x += stereo.x * (r1.w - stereo.y);
o1.xy = v3.xy;
p1.xy = v4.xy;
...
[/code]
Then you might expect we would change it to this:
[code]
...
r1.xyzw = cb2[1].xyzw * r0.yyyy;
r1.xyzw = cb2[0].xyzw * r0.xxxx + r1.xyzw;
r1.xyzw = cb2[2].xyzw * r0.zzzz + r1.xyzw;
r1.xyzw = cb2[3].xyzw * v0.wwww + r1.xyzw;
o0.xyzw = r1.xyzw;
r1.x += nv_separation * r1.w + nv_negative_separation_convergence;
o1.xy = v3.xy;
p1.xy = v4.xy;
...
[/code]
But it turns out that doesn't work - if the shader is accessing cb12, the driver will not apply it's stereo correction, so we actually need to apply it before o0 is set:
[code]
...
r1.xyzw = cb2[1].xyzw * r0.yyyy;
r1.xyzw = cb2[0].xyzw * r0.xxxx + r1.xyzw;
r1.xyzw = cb2[2].xyzw * r0.zzzz + r1.xyzw;
r1.xyzw = cb2[3].xyzw * v0.wwww + r1.xyzw;
r1.x += nv_separation * r1.w + nv_negative_separation_convergence;
o0.xyzw = r1.xyzw;
o1.xy = v3.xy;
p1.xy = v4.xy;
...
[/code]
Notably this constant buffer does not seem to be available in pixel shaders (of at least it doesn't seem to be in cb12), which makes sense since the driver doesn't change them.
Should you use this? Probably not - there's no way to know if nvidia will change this in the future, and it's only injected into vertex shaders. Performance might be slightly better (this generally applies to constant buffers over shader resources), but it would be marginal. The only interesting thing I see here is the fact that using it disables nvidia's stereo correction, but we can usually just subtract that ourselves if needed. Better off to stick to the 3DMigoto stereo texture I think.
This might be interesting to people - I've worked out how nvidia inject the separation and convergence into vertex shaders to apply their stereo correction.
I found this while I was adding a feature to 3DMigoto to copy vertex buffers into shaders as constant buffers (although I have since added the ability to copy them in as structured buffers, which are a lot easier to work with, but I digress - I'll cover that in more detail when I release the FC4 update that uses it). At one point I had this:
[ShaderOverrideHUD]
vs-cb12 = vb0
Which wasn't working, but I couldn't find any reason why it wasn't working - frame analysis showed that my injected buffer was loaded in the cb12 slot and it contained the correct data copied from the correct offset from the vertex buffer, but it's values were complete garbage when I tried to use them in the shader - they weren't the values I was seeing dumped in frame analysis, but they weren't 0 either. Eventually, I tried this:
if (cb12[0].x > 0) {
o0 = 0;
return;
}
As expected that disabled the shader... but unexpectedly it only disabled it in one eye! I then changed it to use constant buffer 11 instead and everything started working.
So, I seem to have found a constant buffer that is hidden from the CPU (frame analysis doesn't show it), but available to the GPU and appears to contain different values in each eye. And if the game happened to use constant buffer 12 itself it would be clobbered by this hidden stereo constant buffer (perhaps there is a setting somewhere to change which constant buffer it uses).
So, today I experiemented a little more with the values in constant buffer 12 and have determined that the structure seems to be:
So, the first value might look a bit weird, but it's a precomputation of the part of the formula that does not depend on the depth (I don't think it saves them any instructions though, but maybe they have another reason for doing it that way).
Seeing if we can apply this, if this is how we would usually fix a halo type issue:
But it turns out that doesn't work - if the shader is accessing cb12, the driver will not apply it's stereo correction, so we actually need to apply it before o0 is set:
Notably this constant buffer does not seem to be available in pixel shaders (of at least it doesn't seem to be in cb12), which makes sense since the driver doesn't change them.
Should you use this? Probably not - there's no way to know if nvidia will change this in the future, and it's only injected into vertex shaders. Performance might be slightly better (this generally applies to constant buffers over shader resources), but it would be marginal. The only interesting thing I see here is the fact that using it disables nvidia's stereo correction, but we can usually just subtract that ourselves if needed. Better off to stick to the 3DMigoto stereo texture I think.
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
Hi, I've got a couple of questions.
Does 3DM give the ability to add another render target to the shader and use it in another as a texture?
[code]
[ShaderOverride-9a1f808870ae1e1d]
Hash = 9a1f808870ae1e1d
ps-t108 = o1
[/code]
[code]void main(
float4 v0 : SV_Position0,
float2 v1 : TEXCOORD0,
float2 w1 : TEXCOORD1,
float4 v2 : TEXCOORD2,
float4 v3 : TEXCOORD3,
float3 v4 : TEXCOORD4,
out float4 o0 : SV_Target0,
out float4 o1 : SV_Target1) //added render target
[/code]
The above doesn't seem to work. Am I doing something wrong or, its just not possible?
Another question: How can I check if the texture generated form a rendertarget has been updated in the current frame?
Thanks in advance.
@DHR:
o0.x -= stereo.x * stereo.y; => DCS06_90.jps
o0.x += stereo.x * 0.5; => DCS07_90.jps
o0.x += stereo.x * -0.5; => DCS08_90.jps
I do not believe that working wih o0 is the solution, because of the black bar on left on right side and also because the sun has the same wrong position for each eye. My try on o2 put the sun on a good position (same as the sun halo drawn by another shader) without black sidebar, but it has stil the same position for each eye.
I do not believe that working wih o0 is the solution, because of the black bar on left on right side and also because the sun has the same wrong position for each eye. My try on o2 put the sun on a good position (same as the sun halo drawn by another shader) without black sidebar, but it has stil the same position for each eye.
I added this lines in the VS shader:
[code]float4 stereo = StereoParams.Load(0);
if ( stereo.x < 0) {
o0.xy= float2(0,0);
}[/code]
=> give DCS10_90.jps
then replace it by
[code]float4 stereo = StereoParams.Load(0);
if ( stereo.x > 0) {
o0.xy= float2(0,0);
}[/code]
=> give DCS09_90.jps
the sky in DCS10_90.jps is normal for each eye and is black for each eye in DCS09_90.jps.
If the stereo variable was working for this shader shouldn't have a black sky for only one eye ? (opposite for each modification)
the sky in DCS10_90.jps is normal for each eye and is black for each eye in DCS09_90.jps.
If the stereo variable was working for this shader shouldn't have a black sky for only one eye ? (opposite for each modification)
[quote="Oomek"]Hi, I've got a couple of questions.
Does 3DM give the ability to add another render target to the shader and use it in another as a texture?[/quote]This is a planned feature for the near future - the pieces are almost all there, all that's missing is the ability to create a new render target compatible with what the shader is already using.
That said, depending on exactly what the game does and exactly what you need it might be possible to achieve this already.
For example, you could try making a copy of the existing render target (so that the copy will have the same size as the original which is necessary to have both assigned at the same time), then add a reference to it in another output slot, then copy it into the destination shader as a texture. That would look something like this:
Note that this example will exercise untested code paths (namely, assigning a render target) so there could be bugs - if you find any let me know:
[code]
[ResourceNewRenderTarget]
[ShaderOverrideWithInjectedRenderTarget]
Hash = ...
; Make the new render target compatible with the existing one (3DMigoto will
; automatically choose "copy" since the destination is a custom resource, but
; it's important for this scenario so I'm specifying it explicitly):
ResourceNewRenderTarget = copy o0
; Then add it as a second render target (3DMigoto should automatically choose
; "reference" since the destination is an output slot and the source is a
; custom resource, but it's important for this scenario so I'm specifying it
; explicitly):
o1 = reference ResourceNewRenderTarget
; Unbind the render target after the draw call to make sure it won't cause
; any issues for the game, and so we can reference it in a texture slot later:
post o1 = null
[ShaderOverrideWithInjectedTexture]
Hash = ...
; Now copy it into this shader as a texture (either "copy" or "reference"
; should work, but if you use reference make sure it's not bound as both an input
; and an output simultaneously by explicitly unbinding it after the draw
; calls):
ps-t108 = copy ResourceNewRenderTarget
; Unbind the texture after the draw call - not strictly necessary since we
; copied it into this shader instead of referencing it, but good practice for
; any resource that is to be used as both an input and an output:
post ps-t108 = null
[/code]
3DMigoto 1.2.11 (coming soon!) will have a new feature to load a texture from a file (.dds, .png and .jpg should all work) which could also be used to create a new render target, but you would have to know the right size ahead of time (which may mean the user has to run it at a specific resolution):
[code]
[ResourceNewRenderTarget]
filename = ShaderFixes\InjectedRenderTarget.png
[ShaderOverrideWithInjectedRenderTarget]
Hash = ...
; Add the new resource as a second render target:
o1 = reference ResourceNewRenderTarget
post o1 = null
[ShaderOverrideWithInjectedTexture]
Hash = ...
; Now copy it into this shader as a texture:
ps-t108 = copy ResourceNewRenderTarget
post ps-t108 = null
[/code]
In the near future I will be adding an alternative keyword to do what you want - it would work similar to the first example, but instead of copying o0 it will just ensure that the resource is compatible with it (and therefore won't overwrite any data already in the resource so long as it doesn't need to be resized). I will also be adding more options to the [Resource] sections to give us more options to create custom resources.
One of my goals with this functionality is to allow custom shaders using custom resources to be run whenever we need - I'm particularly interested in gaining the ability to run a custom compute/pixel shader with an AppendStructuredBuffer (or other UAV) assigned to allow us to collect information throughout the frame (say... the location of all characters on the screen) that we can then check later in the frame (say... from a health bar shader) and make some decision on. I also believe this functionality will finally give me all the tools I need to re-fix DreadOut 100% as I will be able to collect two sets of matrices for both the main game window and the in-game cameraphone display and ensure I'm using the correct set to match the current render target's FOV.
Big plans take time to implement though, but it's getting closer every day and the end is in sight :)
[quote]Another question: How can I check if the texture generated form a rendertarget has been updated in the current frame?[/quote]I'm doing exactly this in the WIP update to Far Cry 4 to determine if the depth buffer has been copied in the current frame so I can avoid adjusting UI elements from it while the game is in a menu. You use one of the ini params to signify this - you clear it from [Present] and set it in any of the [ShaderOverride] sections that set the render target.
This is what I'm doing in FC4:
[code]
[ResourceZBuffer]
[Present]
; Clear W to signify that ResourceZBuffer has not been set yet this frame:
w = 0
[ShaderOverrideDepthNoAA]
Hash = 93351bc8c3e6bac3
; Copy both eyes depth buffers into a mono side-by-side resource:
post ResourceZBuffer = stereo2mono o0
; Set W to signify that ResourceZBuffer has been set this frame:
w = 1
[/code]
(oops - did I just let slip that I've implemented the ability to use the reverse stereo blit in the resource copying as an upcoming feature in 3DMigoto 1.2.11? ;-)
You might also choose to wipe out the custom resource on the [Present] as well, which will mean any loads from it in shaders will return 0 until it is set again:
[code]
[Present]
ResourceZBuffer = null
[/code]
Let me know how this goes for you :)
Does 3DM give the ability to add another render target to the shader and use it in another as a texture?
This is a planned feature for the near future - the pieces are almost all there, all that's missing is the ability to create a new render target compatible with what the shader is already using.
That said, depending on exactly what the game does and exactly what you need it might be possible to achieve this already.
For example, you could try making a copy of the existing render target (so that the copy will have the same size as the original which is necessary to have both assigned at the same time), then add a reference to it in another output slot, then copy it into the destination shader as a texture. That would look something like this:
Note that this example will exercise untested code paths (namely, assigning a render target) so there could be bugs - if you find any let me know:
[ResourceNewRenderTarget]
[ShaderOverrideWithInjectedRenderTarget]
Hash = ...
; Make the new render target compatible with the existing one (3DMigoto will
; automatically choose "copy" since the destination is a custom resource, but
; it's important for this scenario so I'm specifying it explicitly):
ResourceNewRenderTarget = copy o0
; Then add it as a second render target (3DMigoto should automatically choose
; "reference" since the destination is an output slot and the source is a
; custom resource, but it's important for this scenario so I'm specifying it
; explicitly):
o1 = reference ResourceNewRenderTarget
; Unbind the render target after the draw call to make sure it won't cause
; any issues for the game, and so we can reference it in a texture slot later:
post o1 = null
[ShaderOverrideWithInjectedTexture]
Hash = ...
; Now copy it into this shader as a texture (either "copy" or "reference"
; should work, but if you use reference make sure it's not bound as both an input
; and an output simultaneously by explicitly unbinding it after the draw
; calls):
ps-t108 = copy ResourceNewRenderTarget
; Unbind the texture after the draw call - not strictly necessary since we
; copied it into this shader instead of referencing it, but good practice for
; any resource that is to be used as both an input and an output:
post ps-t108 = null
3DMigoto 1.2.11 (coming soon!) will have a new feature to load a texture from a file (.dds, .png and .jpg should all work) which could also be used to create a new render target, but you would have to know the right size ahead of time (which may mean the user has to run it at a specific resolution):
[ShaderOverrideWithInjectedRenderTarget]
Hash = ...
; Add the new resource as a second render target:
o1 = reference ResourceNewRenderTarget
post o1 = null
[ShaderOverrideWithInjectedTexture]
Hash = ...
; Now copy it into this shader as a texture:
ps-t108 = copy ResourceNewRenderTarget
post ps-t108 = null
In the near future I will be adding an alternative keyword to do what you want - it would work similar to the first example, but instead of copying o0 it will just ensure that the resource is compatible with it (and therefore won't overwrite any data already in the resource so long as it doesn't need to be resized). I will also be adding more options to the [Resource] sections to give us more options to create custom resources.
One of my goals with this functionality is to allow custom shaders using custom resources to be run whenever we need - I'm particularly interested in gaining the ability to run a custom compute/pixel shader with an AppendStructuredBuffer (or other UAV) assigned to allow us to collect information throughout the frame (say... the location of all characters on the screen) that we can then check later in the frame (say... from a health bar shader) and make some decision on. I also believe this functionality will finally give me all the tools I need to re-fix DreadOut 100% as I will be able to collect two sets of matrices for both the main game window and the in-game cameraphone display and ensure I'm using the correct set to match the current render target's FOV.
Big plans take time to implement though, but it's getting closer every day and the end is in sight :)
Another question: How can I check if the texture generated form a rendertarget has been updated in the current frame?
I'm doing exactly this in the WIP update to Far Cry 4 to determine if the depth buffer has been copied in the current frame so I can avoid adjusting UI elements from it while the game is in a menu. You use one of the ini params to signify this - you clear it from [Present] and set it in any of the [ShaderOverride] sections that set the render target.
This is what I'm doing in FC4:
[ResourceZBuffer]
[Present]
; Clear W to signify that ResourceZBuffer has not been set yet this frame:
w = 0
[ShaderOverrideDepthNoAA]
Hash = 93351bc8c3e6bac3
; Copy both eyes depth buffers into a mono side-by-side resource:
post ResourceZBuffer = stereo2mono o0
; Set W to signify that ResourceZBuffer has been set this frame:
w = 1
(oops - did I just let slip that I've implemented the ability to use the reverse stereo blit in the resource copying as an upcoming feature in 3DMigoto 1.2.11? ;-)
You might also choose to wipe out the custom resource on the [Present] as well, which will mean any loads from it in shaders will return 0 until it is set again:
[Present]
ResourceZBuffer = null
Let me know how this goes for you :)
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
I am still stuck with the problem of the sky in DCS world (the previous post regarding the horizon problem is linked to the shader drawing the sky).
I try to make a lot of things, but I still have the sky in 2D...
I used the sun instead of horizon to check the effects of my modification, because it shows easier the problem than the horizon.
What did I try ?
At fisrt I tried to stereoize the o0 of vertex shader: no success (see DCS05_90.jps).
Then I tried to steroize the o1 and o2 part common with o0 : I had a strange result where the sun is only shifted to the left (see DCS_0390.jps)!
VS shader is here:
After that I tried to work on pixel shader: "stereoizing" the v2 input, modifying numbers or formulas in shader : no succes !
Then I comment most of the shader to have it as simple as possible : here is the remaining code.
I used it with the "steroized" VS and had the following result : DCS04_90.jps. Of course there is few of the original effect, but, as for the sun, the result is not stereoscopic !
So I dont not understand why I can not have different X shift for each eye for this shader !
I already use 3dmigoto for HUD and label shader for this version of DCS and it works. Why not for this one ?
If someone can help...
Post the original VS for the Sky.
Try add the code after o0.xy (stereoize o0)
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
I included the original VS and PS and my d2dx.ini in the enclosed zip (remove the jps extension)
i don't know if you removed in the copy-paste....
edit: Sorry, i just saw the line upper in the code.
Also the sun siluette/halo have to be fixed....is in depth, but not infinite (use the same code).
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
By the way, DCS world 1.5b is freely downloadable, and the problems can be showned with the free plane.
I know that the sun halo is not at 100% depth, but I can not start to fix its dedicated shader until I have a solution for the sun (and horizon) shader bugs, which are much more annoying.
Change sign:
Try different values between 0.1 and 1 in "CORRECT" (with + and - sign):
For example, using CORRECT = 1 (check with - sign also):
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
Here is aiming by dominant eye
Except that I'm left eye dominant, but it looks great. Is this from Tridef or a 3Dmigoto experiment?
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
3Dmigoto, 3rd pers view, Free cam ("tfc" command) and than find pozition for screenshot. ("sucsm 0.5" - set camera speed.)
I found this while I was adding a feature to 3DMigoto to copy vertex buffers into shaders as constant buffers (although I have since added the ability to copy them in as structured buffers, which are a lot easier to work with, but I digress - I'll cover that in more detail when I release the FC4 update that uses it). At one point I had this:
Which wasn't working, but I couldn't find any reason why it wasn't working - frame analysis showed that my injected buffer was loaded in the cb12 slot and it contained the correct data copied from the correct offset from the vertex buffer, but it's values were complete garbage when I tried to use them in the shader - they weren't the values I was seeing dumped in frame analysis, but they weren't 0 either. Eventually, I tried this:
As expected that disabled the shader... but unexpectedly it only disabled it in one eye! I then changed it to use constant buffer 11 instead and everything started working.
So, I seem to have found a constant buffer that is hidden from the CPU (frame analysis doesn't show it), but available to the GPU and appears to contain different values in each eye. And if the game happened to use constant buffer 12 itself it would be clobbered by this hidden stereo constant buffer (perhaps there is a setting somewhere to change which constant buffer it uses).
So, today I experiemented a little more with the values in constant buffer 12 and have determined that the structure seems to be:
So, the first value might look a bit weird, but it's a precomputation of the part of the formula that does not depend on the depth (I don't think it saves them any instructions though, but maybe they have another reason for doing it that way).
Seeing if we can apply this, if this is how we would usually fix a halo type issue:
Then you might expect we would change it to this:
But it turns out that doesn't work - if the shader is accessing cb12, the driver will not apply it's stereo correction, so we actually need to apply it before o0 is set:
Notably this constant buffer does not seem to be available in pixel shaders (of at least it doesn't seem to be in cb12), which makes sense since the driver doesn't change them.
Should you use this? Probably not - there's no way to know if nvidia will change this in the future, and it's only injected into vertex shaders. Performance might be slightly better (this generally applies to constant buffers over shader resources), but it would be marginal. The only interesting thing I see here is the fact that using it disables nvidia's stereo correction, but we can usually just subtract that ourselves if needed. Better off to stick to the 3DMigoto stereo texture I think.
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
Does 3DM give the ability to add another render target to the shader and use it in another as a texture?
The above doesn't seem to work. Am I doing something wrong or, its just not possible?
Another question: How can I check if the texture generated form a rendertarget has been updated in the current frame?
Thanks in advance.
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
o0.x -= stereo.x * stereo.y; => DCS06_90.jps
o0.x += stereo.x * 0.5; => DCS07_90.jps
o0.x += stereo.x * -0.5; => DCS08_90.jps
I do not believe that working wih o0 is the solution, because of the black bar on left on right side and also because the sun has the same wrong position for each eye. My try on o2 put the sun on a good position (same as the sun halo drawn by another shader) without black sidebar, but it has stil the same position for each eye.
=> give DCS10_90.jps
then replace it by
=> give DCS09_90.jps
the sky in DCS10_90.jps is normal for each eye and is black for each eye in DCS09_90.jps.
If the stereo variable was working for this shader shouldn't have a black sky for only one eye ? (opposite for each modification)
That said, depending on exactly what the game does and exactly what you need it might be possible to achieve this already.
For example, you could try making a copy of the existing render target (so that the copy will have the same size as the original which is necessary to have both assigned at the same time), then add a reference to it in another output slot, then copy it into the destination shader as a texture. That would look something like this:
Note that this example will exercise untested code paths (namely, assigning a render target) so there could be bugs - if you find any let me know:
3DMigoto 1.2.11 (coming soon!) will have a new feature to load a texture from a file (.dds, .png and .jpg should all work) which could also be used to create a new render target, but you would have to know the right size ahead of time (which may mean the user has to run it at a specific resolution):
In the near future I will be adding an alternative keyword to do what you want - it would work similar to the first example, but instead of copying o0 it will just ensure that the resource is compatible with it (and therefore won't overwrite any data already in the resource so long as it doesn't need to be resized). I will also be adding more options to the [Resource] sections to give us more options to create custom resources.
One of my goals with this functionality is to allow custom shaders using custom resources to be run whenever we need - I'm particularly interested in gaining the ability to run a custom compute/pixel shader with an AppendStructuredBuffer (or other UAV) assigned to allow us to collect information throughout the frame (say... the location of all characters on the screen) that we can then check later in the frame (say... from a health bar shader) and make some decision on. I also believe this functionality will finally give me all the tools I need to re-fix DreadOut 100% as I will be able to collect two sets of matrices for both the main game window and the in-game cameraphone display and ensure I'm using the correct set to match the current render target's FOV.
Big plans take time to implement though, but it's getting closer every day and the end is in sight :)
I'm doing exactly this in the WIP update to Far Cry 4 to determine if the depth buffer has been copied in the current frame so I can avoid adjusting UI elements from it while the game is in a menu. You use one of the ini params to signify this - you clear it from [Present] and set it in any of the [ShaderOverride] sections that set the render target.
This is what I'm doing in FC4:
(oops - did I just let slip that I've implemented the ability to use the reverse stereo blit in the resource copying as an upcoming feature in 3DMigoto 1.2.11? ;-)
You might also choose to wipe out the custom resource on the [Present] as well, which will mean any loads from it in shaders will return 0 until it is set again:
Let me know how this goes for you :)
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
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64