Try dumping out the intermediate values as a second render target and see if they make sense. You can learn to interpret the colours of view-space coordinates, normals, etc. Think about how reflections are supposed to work and see if the reflected coordinate represented as a colour makes sense. Set the max steps to 1, then 2, then 3, and so on and see if the result of the ray tracing looks sane.
That is what I did when I looked at these - I started from the start of the shader and made sure that the result of every step was what I expected before moving on.
Try dumping out the intermediate values as a second render target and see if they make sense. You can learn to interpret the colours of view-space coordinates, normals, etc. Think about how reflections are supposed to work and see if the reflected coordinate represented as a colour makes sense. Set the max steps to 1, then 2, then 3, and so on and see if the result of the ray tracing looks sane.
That is what I did when I looked at these - I started from the start of the shader and made sure that the result of every step was what I expected before moving on.
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="DarkStarSword"]Try dumping out the intermediate values as a second render target and see if they make sense. You can learn to interpret the colours of view-space coordinates, normals, etc. Think about how reflections are supposed to work and see if the reflected coordinate represented as a colour makes sense. Set the max steps to 1, then 2, then 3, and so on and see if the result of the ray tracing looks sane.
That is what I did when I looked at these - I started from the start of the shader and made sure that the result of every step was what I expected before moving on.[/quote]
Brefore I do this I need to make sure I have the input values right. Your fix was based on my assumption only that near = 10 and far = 10000 which Is wrong apparently
DarkStarSword said:Try dumping out the intermediate values as a second render target and see if they make sense. You can learn to interpret the colours of view-space coordinates, normals, etc. Think about how reflections are supposed to work and see if the reflected coordinate represented as a colour makes sense. Set the max steps to 1, then 2, then 3, and so on and see if the result of the ray tracing looks sane.
That is what I did when I looked at these - I started from the start of the shader and made sure that the result of every step was what I expected before moving on.
Brefore I do this I need to make sure I have the input values right. Your fix was based on my assumption only that near = 10 and far = 10000 which Is wrong apparently
I think, I'm going to give up. I've spent to much of my energy for circling in the dark with those reflections. Besides, with recently Dirt 4 announced and Dirt 3 taken down from Steam it has not much sense now...
I think, I'm going to give up. I've spent to much of my energy for circling in the dark with those reflections. Besides, with recently Dirt 4 announced and Dirt 3 taken down from Steam it has not much sense now...
[quote="Oomek"]projection._m32 = -1 and projection._m22 ≈ -1.0[/quote]Then they are NOT using reverse Z projection since _m22 is not zero. I doubt _m32 would be exactly -1 or +1, more likely that was _m23 (or maybe I've got that the wrong way around, fecking transposed notation makes this confusing as hell), which from what Bo3b suggested they are probably using a right handed coordinate system, but I don't think that makes a difference for you. You don't even need these values - I've clearly confused you with the theory, just use the linear depth function I gave you and forget the rest.
[quote="Oomek"]Your fix was based on my assumption only that near = 10 and far = 10000 which Is wrong apparently[/quote]Near=10 is definitely too high since there are things drawn closer, but just use the linear depth function to calculate that dynamically and forget about trying to hard code it.
If you did hardcode it, just set it to something small like 0.01 - I don't honestly think it should matter for what you are doing if you don't have it exact - it's only used to cap the ray tracing if it is tracing *towards* the camera, which it won't be because it's a reflection on a water surface so the angle will never be right (if it was a reflection on a wall that would be a totally different matter).
The far clipping plane doesn't even come into this equation - the max distance thing does not have to match that, though it does make some sense to use it... but any large value that will be close to the vanishing point on the horizon should be ok, and 10000 seems reasonable to me. Just not FLT_MAX or infinity that will throw out the multiplication - keep it sane.
The problem you had before was that you were using bad guesses for near & far to calculate the linear depth, which was massively throwing out the starting coordinate for ray tracing. With the linear depth function I gave you this is a non-issue because it doesn't need to know those values.
[quote="Oomek"]I think, I'm going to give up. I've spent to much of my energy for circling in the dark with those reflections. Besides, with recently Dirt 4 announced and Dirt 3 taken down from Steam it has not much sense now...[/quote]That would be a shame. I can look at these again when I have some time, but I'm pretty busy.
Oomek said:projection._m32 = -1 and projection._m22 ≈ -1.0
Then they are NOT using reverse Z projection since _m22 is not zero. I doubt _m32 would be exactly -1 or +1, more likely that was _m23 (or maybe I've got that the wrong way around, fecking transposed notation makes this confusing as hell), which from what Bo3b suggested they are probably using a right handed coordinate system, but I don't think that makes a difference for you. You don't even need these values - I've clearly confused you with the theory, just use the linear depth function I gave you and forget the rest.
Oomek said:Your fix was based on my assumption only that near = 10 and far = 10000 which Is wrong apparently
Near=10 is definitely too high since there are things drawn closer, but just use the linear depth function to calculate that dynamically and forget about trying to hard code it.
If you did hardcode it, just set it to something small like 0.01 - I don't honestly think it should matter for what you are doing if you don't have it exact - it's only used to cap the ray tracing if it is tracing *towards* the camera, which it won't be because it's a reflection on a water surface so the angle will never be right (if it was a reflection on a wall that would be a totally different matter).
The far clipping plane doesn't even come into this equation - the max distance thing does not have to match that, though it does make some sense to use it... but any large value that will be close to the vanishing point on the horizon should be ok, and 10000 seems reasonable to me. Just not FLT_MAX or infinity that will throw out the multiplication - keep it sane.
The problem you had before was that you were using bad guesses for near & far to calculate the linear depth, which was massively throwing out the starting coordinate for ray tracing. With the linear depth function I gave you this is a non-issue because it doesn't need to know those values.
Oomek said:I think, I'm going to give up. I've spent to much of my energy for circling in the dark with those reflections. Besides, with recently Dirt 4 announced and Dirt 3 taken down from Steam it has not much sense now...
That would be a shame. I can look at these again when I have some time, but I'm pretty busy.
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
You were right,
linearizeDepth(0) spits out 0.6
linearizeDepth(1) = 10000
so I set cb_nearPlaneZ and cb_maxDistance, but still the shift remains.
I've recorded a short video showing the sampling shift and the artiffacts outside the texture coordinates which show up on the red area (you can press C in game to change the camera's angle) maybe that will give you some clues, as I'm still clueless.
Besides the whole reflection is moved up, even the rocks are not showing up on the reflection.
[url]https://youtu.be/o2uICcgWYxs[/url]
You were right,
linearizeDepth(0) spits out 0.6
linearizeDepth(1) = 10000
so I set cb_nearPlaneZ and cb_maxDistance, but still the shift remains.
I've recorded a short video showing the sampling shift and the artiffacts outside the texture coordinates which show up on the red area (you can press C in game to change the camera's angle) maybe that will give you some clues, as I'm still clueless.
Besides the whole reflection is moved up, even the rocks are not showing up on the reflection.
I need a little bit of help.
I am trying to reduce depth allocation for the weapons in Call of duty Black ops 2 Zombies. I used for this the shaderoverride field in d3dx.ini and I was successful until a certain point.
I have certain PS&VS (ex. Hands, handgun) that affect also other objects.
I will take the hands as example. see images.
PS
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/71525/[/img]
VS
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/71524/[/img]
I tried this
[ShaderOverride27] ;hand
Hash=94c92cdd1efef1a6
Convergence=0.3
Separation=0.7
partner=282ef6805ab210fa
Result
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/71523/[/img]
However it does not work, whatever I tried.
What am I doing wrong? how should this be solved?
I need a little bit of help.
I am trying to reduce depth allocation for the weapons in Call of duty Black ops 2 Zombies. I used for this the shaderoverride field in d3dx.ini and I was successful until a certain point.
I have certain PS&VS (ex. Hands, handgun) that affect also other objects.
I will take the hands as example. see images.
PS
VS
I tried this
[ShaderOverride27] ;hand
Hash=94c92cdd1efef1a6
Convergence=0.3
Separation=0.7
partner=282ef6805ab210fa
Result
However it does not work, whatever I tried.
What am I doing wrong? how should this be solved?
Intel i7 8086K
Gigabyte GTX 1080Ti Aorus Extreme
DDR4 2x8gb 3200mhz Cl14
TV LG OLED65E6V
Avegant Glyph
Windows 10 64bits
Do it in the shader so you can add depth threshold tests - the formula for a convergence override is:
[code]pos.x += separation * (convergence - convergence_override);[/code]
Thanks DSS!
This is a little bit above my understanding :))
Just ust copy pasting this above return in the file does not work
Could you please give me more detail? :D
Attached the VS
Have you gone through the shaderhacker school?
Assuming o0 is SV_Position (it might not be - check the function prototype), add this to the end of the main function:
[code]
float4 stereo = StereoParams.Load(0);
if (o0.w < something) {
o0.x += stereo.x * (stereo.y - something_else);
}
[/code]
Replace something and something_else with numbers, using trial and error to find values that work well.
A couple of points of warning:
- You are going to be adjusting vertex shaders with "bones" - we rarely need to edit these and they often suffer from decompiler bugs causing them to move somewhere weird, introduce gaps or misalignments, completely disappear, etc. If they do, you either need to find and fix the decompiler bug, or switch to assembly, which gets even more complicated.
- There may not be a value you can use for "something" that works in every situation.
- There may not be a value for "something_else" that works in every situation (different convergence settings), though there are other types of adjustments you could use instead to achieve a similar result that might work better or worse (such as a depth bias or capping the depth to a minimum value).
- If this adjustment messes up the lighting/shadows on the hands, you might need to use a different type of adjustment, such as multiplying all four components of the coordinate by a value, e.g. o0 *= 1.1;
I almost never add these type of overrides because they usually involve compromises that I don't deem acceptable (e.g. get too close to one of the other objects the shader controls and it will break, might cause issues in cutscenes, etc), but that depends on the game. You could add a toggle key if those compromises are situational.
Replace something and something_else with numbers, using trial and error to find values that work well.
A couple of points of warning:
- You are going to be adjusting vertex shaders with "bones" - we rarely need to edit these and they often suffer from decompiler bugs causing them to move somewhere weird, introduce gaps or misalignments, completely disappear, etc. If they do, you either need to find and fix the decompiler bug, or switch to assembly, which gets even more complicated.
- There may not be a value you can use for "something" that works in every situation.
- There may not be a value for "something_else" that works in every situation (different convergence settings), though there are other types of adjustments you could use instead to achieve a similar result that might work better or worse (such as a depth bias or capping the depth to a minimum value).
- If this adjustment messes up the lighting/shadows on the hands, you might need to use a different type of adjustment, such as multiplying all four components of the coordinate by a value, e.g. o0 *= 1.1;
I almost never add these type of overrides because they usually involve compromises that I don't deem acceptable (e.g. get too close to one of the other objects the shader controls and it will break, might cause issues in cutscenes, etc), but that depends on the game. You could add a toggle key if those compromises are situational.
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
Thank you DSS! Very comprehensive explanation.
Meanwhile, I received some guidance from DHR for this shaders, and did the fix using a similar formula
[code] float4 stereo = StereoParams.Load(0);
if (o0.z < 0.4)
{
o0.x += stereo.x * 19;
}[/code]
It works very well, no artefacts during gameplay (only in SP and MP menu, but nothing major). I already put the fix on the forum in case there are others that still play this game from time to time.
I will try with your recommendation also to see how it works, I suppose the result will be similar.
Thank you!
It works very well, no artefacts during gameplay (only in SP and MP menu, but nothing major). I already put the fix on the forum in case there are others that still play this game from time to time.
I will try with your recommendation also to see how it works, I suppose the result will be similar.
Thank you!
Intel i7 8086K
Gigabyte GTX 1080Ti Aorus Extreme
DDR4 2x8gb 3200mhz Cl14
TV LG OLED65E6V
Avegant Glyph
Windows 10 64bits
I've started looking at RE7 along with mike, and it's in a pretty rough state to work on. It's not so much that there are a large number of things that are broken, but more that what is broken is hard to track down due to issues with shader hunting and frame analysis and/or in cases where I may have found the appropriate shader, it doesn't seem any adjustments made in the shader can fix the problem (which has me thinking this could be some driver heuristics issues at play here).
Biggest issues are several effects render in one eye only (I suspect these are compute shaders, and unfortunately stereoflagsdx10 0x00004000 can't be used here and breaks things even further. More on this later), and some other effects are rendering in mono (although strangely they are in the correct position in one eye).
First thing I'll talk about is the issue with shader hunting and frame analysis dumping. As mike reported in the RE7 thread, manually hunting for shaders is not very effective in this game. I won't go into detail on that though, as I much prefer using frame analysis and would rather discuss that.
The first hurdle that I got over was that I was using the clear_rt flag like I normally do and all the images were dumping as completely black, and thankfully removing that helped somewhat. The remaining problem is that for VS/PS shaders 3DM can only dump o1 and o2 drawcall outputs as JPS files, but the o0 output (which is the one that would actually be helpful) can only be dumped as a dds file. Normally that's not a problem, and I could use DSS's python tool to convert it, but these get converted as completely black images. I've tried nearly every single DDS viewer out there, and all of them can't open these files due to an unsupported compression. I'm guessing that frame analysis dumping is probably in a "as good as it gets" state, but is there anything that can be done here?
Back to the issue about the compute shaders / one eye rendering effects. Frame analysis does dump some CS drawcalls as JPS, and when it does it always comes out as left eye shows the image, and right eye is all black. If I try enabling stereoflags, then it breaks pretty much EVERYTHING to being one eye only, and doing a frame analysis dump will have all the VS/PS images look the same as a CS image dump usually does. I've tried all the known common bits for stereoflags, and they all produce the same result. Is there any way for 3DM to force the same result as what the stereoflags achieves and get separate outputs for each eye?
Lastly, also coming back to the effects I mentioned that render in mono. The most common broken effect like this are specular highlights / light reflections on surfaces. There's one PS that can be disabled that will remove a large portion of these, but not all, and disabling them loses a lot of fidelity so would rather try to avoid resorting to this. Modifying that PS or the VS paired to it does not adjust the position of it, rather doing so adjusts an entire screen effect. Here's a couple screenshots to demonstrate:
Broken specular highlights. Note they appear correct in left eye:
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/71571/[/img]
More broken speculars (and other details/lines) before disabling HDR shader:
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/71569/[/img]
After disabling HDR shader, removes specular highlights but other broken effects remain:
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/71570/[/img]
HDR shader still disabled, note that trees still have broken lighting reflections:
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/71572/[/img]
In the screenshots above you'll see that there are 2 different broken effects, the specular highlights and also other details/outlines on the car. Through some additional hunting I managed to find the VS/PS pair responsible for rendering the entire body of the car, which seems to be the best candidate I can find for this, but even still I'm not certain if it's the correct shader to be working on. Reasons why I think this could be a candidate are when making the VS mono the body and the broken effects are perfectly aligned, and I found that adjusting the o1 output in the VS does cause the specular highlights to move, but not in the proper way (like, the area of effect's position itself doesn't move, only the visual effects inside of it does. Have tried different fix methods, ie. world space and clip space), and adjusting o2 causes those other details to move (but just like the specular highlights, it doesn't adjust in the correct fasion). I'm thinking these effects will require some other type of fixing magic... because these appear correct in one eye I'm thinking driver heuristics are off, and it may need one of those fancy custom resource tricks DSS uses in his fixes. Any suggestions here?
Guess that's enough for now. Hope I was able to explain things clearly enough. Thanks for reading all that. ;)
I've started looking at RE7 along with mike, and it's in a pretty rough state to work on. It's not so much that there are a large number of things that are broken, but more that what is broken is hard to track down due to issues with shader hunting and frame analysis and/or in cases where I may have found the appropriate shader, it doesn't seem any adjustments made in the shader can fix the problem (which has me thinking this could be some driver heuristics issues at play here).
Biggest issues are several effects render in one eye only (I suspect these are compute shaders, and unfortunately stereoflagsdx10 0x00004000 can't be used here and breaks things even further. More on this later), and some other effects are rendering in mono (although strangely they are in the correct position in one eye).
First thing I'll talk about is the issue with shader hunting and frame analysis dumping. As mike reported in the RE7 thread, manually hunting for shaders is not very effective in this game. I won't go into detail on that though, as I much prefer using frame analysis and would rather discuss that.
The first hurdle that I got over was that I was using the clear_rt flag like I normally do and all the images were dumping as completely black, and thankfully removing that helped somewhat. The remaining problem is that for VS/PS shaders 3DM can only dump o1 and o2 drawcall outputs as JPS files, but the o0 output (which is the one that would actually be helpful) can only be dumped as a dds file. Normally that's not a problem, and I could use DSS's python tool to convert it, but these get converted as completely black images. I've tried nearly every single DDS viewer out there, and all of them can't open these files due to an unsupported compression. I'm guessing that frame analysis dumping is probably in a "as good as it gets" state, but is there anything that can be done here?
Back to the issue about the compute shaders / one eye rendering effects. Frame analysis does dump some CS drawcalls as JPS, and when it does it always comes out as left eye shows the image, and right eye is all black. If I try enabling stereoflags, then it breaks pretty much EVERYTHING to being one eye only, and doing a frame analysis dump will have all the VS/PS images look the same as a CS image dump usually does. I've tried all the known common bits for stereoflags, and they all produce the same result. Is there any way for 3DM to force the same result as what the stereoflags achieves and get separate outputs for each eye?
Lastly, also coming back to the effects I mentioned that render in mono. The most common broken effect like this are specular highlights / light reflections on surfaces. There's one PS that can be disabled that will remove a large portion of these, but not all, and disabling them loses a lot of fidelity so would rather try to avoid resorting to this. Modifying that PS or the VS paired to it does not adjust the position of it, rather doing so adjusts an entire screen effect. Here's a couple screenshots to demonstrate:
Broken specular highlights. Note they appear correct in left eye:
More broken speculars (and other details/lines) before disabling HDR shader:
After disabling HDR shader, removes specular highlights but other broken effects remain:
HDR shader still disabled, note that trees still have broken lighting reflections:
In the screenshots above you'll see that there are 2 different broken effects, the specular highlights and also other details/outlines on the car. Through some additional hunting I managed to find the VS/PS pair responsible for rendering the entire body of the car, which seems to be the best candidate I can find for this, but even still I'm not certain if it's the correct shader to be working on. Reasons why I think this could be a candidate are when making the VS mono the body and the broken effects are perfectly aligned, and I found that adjusting the o1 output in the VS does cause the specular highlights to move, but not in the proper way (like, the area of effect's position itself doesn't move, only the visual effects inside of it does. Have tried different fix methods, ie. world space and clip space), and adjusting o2 causes those other details to move (but just like the specular highlights, it doesn't adjust in the correct fasion). I'm thinking these effects will require some other type of fixing magic... because these appear correct in one eye I'm thinking driver heuristics are off, and it may need one of those fancy custom resource tricks DSS uses in his fixes. Any suggestions here?
Guess that's enough for now. Hope I was able to explain things clearly enough. Thanks for reading all that. ;)
3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot
[quote="DJ-RK"]The remaining problem is that for VS/PS shaders 3DM can only dump o1 and o2 drawcall outputs as JPS files, but the o0 output (which is the one that would actually be helpful) can only be dumped as a dds file. Normally that's not a problem, and I could use DSS's python tool to convert it, but these get converted as completely black images.[/quote]Can you send me a sample of one of these and I'll see if I can improve it. Also be sure to try the --auto-scale option to ddsinfo, which will try to scale the images to maximise the dynamic range.
[quote]I'm guessing that frame analysis dumping is probably in a "as good as it gets" state, but is there anything that can be done here?[/quote]Hehe, never say that - it's only "as good as we've made it so far". Improvements are definitely possible, it's just a question of spending time on it as opposed to other things.
[quote]Back to the issue about the compute shaders / one eye rendering effects. Frame analysis does dump some CS drawcalls as JPS, and when it does it always comes out as left eye shows the image, and right eye is all black. If I try enabling stereoflags, then it breaks pretty much EVERYTHING to being one eye only, and doing a frame analysis dump will have all the VS/PS images look the same as a CS image dump usually does. I've tried all the known common bits for stereoflags, and they all produce the same result. Is there any way for 3DM to force the same result as what the stereoflags achieves and get separate outputs for each eye?[/quote]
Ok, I've just done something like this in the WATCH_DOGS2 fix - I needed stereo compute shaders enabled for certain effects, but enabling them broke the wind simulation leading to leaves, grass, bushes, etc getting desynchronised between each eye.
The trick is that you need to identify any compute shaders that get broken by enabling stereo compute shaders and make sure that their inputs are identical between both eyes - if their inputs are identical and their code is identical than they should produce an identical result. That's the theory anyway - things can get a little tricky in practice.
The fix for WATCH_DOGS2 involved several parts. Firstly, the wind simulation used a Texture2D, which was getting stereoised on single GPU (but not on SLI). Forcing the texture to mono crashed the game, so instead I had to do this:
[code]
;;;;;;;;;;;;;;;;;; WIND FIX ;;;;;;;;;;;;;;;;;;;;
; On single GPU systems the wind fluid dynamics simulation gets stereoised,
; which leads to leaves, grass, bushes, trees, etc desyncing between each eye.
; Tracing the exact point where it is first steroised is not easy since there
; are a lot of compute shaders that are chained together, and most of the
; buffers carry over to the next frame, but we can interject here - the last
; compute shader in the fluid dynamics simulation to force it to mono.
;
; On SLI this doesn't seem to (often?) get steroeised, so the fact the mono
; copy may not work there doesn't matter.
;
; Note that the leaves simulation has additional depth buffer inputs that will
; mess them up if they are stereo, so they are disabled elsewhere in this file.
[ShaderOverrideWindSimulation]
hash = 91006003dd480d20
cs-t2 = mono copy cs-t2
[/code]
The second problem was that the leaves simulation took copies of three depth buffers (from the POV of the camera and overhead), which it used so the leaves would land on the ground, but could lead to a desync between both eyes. The above approach *might* have worked for a single GPU, but it did not for SLI - I had to kill those inputs instead (which means the leaves never settle on the ground, but who will notice?). There's also some remnants here of the debug shaders I was using to identify this - dig through the rest of the d3dx.ini and custom shaders shipped with that fix if you are interested to see what I did there:
[code]
;;;;;;;;;;; LEAVES ;;;;;;;;;;;;;
; The leaves falling from the trees get out of sync when Stereo compute shaders
; and/or SLI are enabled. This is due to the leaf physics compute shader using
; a stereo depth buffer, which leads to physics desync. To fix this, we unbind
; the depth buffer from cs-t3, effectively stopping the leaves from interacting
; with the world, and keeping them in sync. It does mean they don't settle on
; the ground, but I doubt anyone will notice.
;
; Alternative solutions that did not work:
; - cs-t3 = mono copy cs-t3 (driver heuristics ignored this and did it stereo)
; - cs-t3 = stereo2mono cs-t3 (not working in this game for some reason)
; - disable stereo compute shaders (ignored in SLI (driver bug?), breaks fog)
; - restrict stereo compute shaders to same resources as graphics (no effect)
; - force the leaf structured buffer to mono at time of creation (no hash to match)
; - ask the driver not to stereoise this paricular CS (no API to do this)
; - replace the leaf buffer with our own mono buffer (driver seems to be
; ignorring the creation mode, and even if it wasn't this would need 3DMigoto
; support to match original buffer as there are multiple active at a time)
;
; If examining this, remember the SGraphicParticle structured buffer must be
; cleared to resync the physics (including spawning new leaves). One way to do
; this is to set 'analyse_options = clear_rt' globally then run frame analysis.
;
; Also disable cs-t2 and cs-t4 - these are mostly mono depth buffers (for cs-t2
; that is probably a bug since it is from the POV of the camera, but cs-t4 is
; probably supposed to be mono since it is an overhead view), but include some
; stereo elements that could cause desync.
[ShaderOverrideLeavesCS1]
hash = 74cb1f2b7151ee43
;post ResourceDebugLeaves = copy cs-u2
;ResourceDebug2D = copy cs-t3
ResourceDebugTransparentDepthBuffer = ref cs-t2 unless_null
cs-t2 = null
cs-t3 = null
cs-t4 = null
[/code]
[quote]Lastly, also coming back to the effects I mentioned that render in mono. Here's a couple screenshots to demonstrate:[/quote]The fact that these look to be correct in one eye tells you that it is not a problem that can be fixed by editing a shader. Some possibilities:
- These might have used a compute shader that was mono, and by enabling stereo compute shaders they might be fixed
- The driver might be creating a mono texture where it needed to be stereo - you should be able to identify it with frame analysis (look for either a texture missing the left eye, or with a left eye that is exactly the same as the right eye) and use a TextureOverride to force it to stereo.
- The game may be doing a depth only pass with no render target assigned. In theory, StereoTextureEnable = 0x00000400 (ENABLE_SEPARATION_IF_MONORT) is supposed to fix this, but has never worked for me. This does:
[code]
;;;;;;;;;; TEMPORAL FILTERING + SSR + SINGLE GPU FIX ;;;;;;;;;;;;;;
; The screen space reflections use a depth buffer, which was drawn to with no
; render target or pixel shader assigned, so the driver does not stereoise it.
; This assigns a dummy render target for this depth pass, which causes the
; driver to stereoise the depth buffer and fixes the reflections.
[ResourceDummyRenderTarget]
format = R8G8B8A8_UNORM
[ResourceDummyRenderTargetBak]
[ShaderOverrideDepthPass]
hash = cdf6be32865cf758
ResourceDummyRenderTarget = copy_desc oD
ResourceDummyRenderTargetBak = ref o0
o0 = ResourceDummyRenderTarget
post o0 = ResourceDummyRenderTargetBak
[/code]
- The game may be doing a graphics only pass with no depth target assigned. In theory, StereoTextureEnable = 0x00000080 (ENABLE_SEPARATION_IF_ZBNULL) is supposed to fix this, but has also never worked for me. Something like this should do the trick:
[code]
[ResourceDummyDepthTarget]
format = R32_FLOAT
[ResourceDummyDepthTargetBak]
[ShaderOverrideDepthPass]
hash = ...
ResourceDummyDepthTarget = copy_desc o0
ResourceDummyDepthTargetBak = ref oD
oD = ResourceDummyDepthTarget
post oD = ResourceDummyDepthTargetBak
[/code]
DJ-RK said:The remaining problem is that for VS/PS shaders 3DM can only dump o1 and o2 drawcall outputs as JPS files, but the o0 output (which is the one that would actually be helpful) can only be dumped as a dds file. Normally that's not a problem, and I could use DSS's python tool to convert it, but these get converted as completely black images.
Can you send me a sample of one of these and I'll see if I can improve it. Also be sure to try the --auto-scale option to ddsinfo, which will try to scale the images to maximise the dynamic range.
I'm guessing that frame analysis dumping is probably in a "as good as it gets" state, but is there anything that can be done here?
Hehe, never say that - it's only "as good as we've made it so far". Improvements are definitely possible, it's just a question of spending time on it as opposed to other things.
Back to the issue about the compute shaders / one eye rendering effects. Frame analysis does dump some CS drawcalls as JPS, and when it does it always comes out as left eye shows the image, and right eye is all black. If I try enabling stereoflags, then it breaks pretty much EVERYTHING to being one eye only, and doing a frame analysis dump will have all the VS/PS images look the same as a CS image dump usually does. I've tried all the known common bits for stereoflags, and they all produce the same result. Is there any way for 3DM to force the same result as what the stereoflags achieves and get separate outputs for each eye?
Ok, I've just done something like this in the WATCH_DOGS2 fix - I needed stereo compute shaders enabled for certain effects, but enabling them broke the wind simulation leading to leaves, grass, bushes, etc getting desynchronised between each eye.
The trick is that you need to identify any compute shaders that get broken by enabling stereo compute shaders and make sure that their inputs are identical between both eyes - if their inputs are identical and their code is identical than they should produce an identical result. That's the theory anyway - things can get a little tricky in practice.
The fix for WATCH_DOGS2 involved several parts. Firstly, the wind simulation used a Texture2D, which was getting stereoised on single GPU (but not on SLI). Forcing the texture to mono crashed the game, so instead I had to do this:
;;;;;;;;;;;;;;;;;; WIND FIX ;;;;;;;;;;;;;;;;;;;;
; On single GPU systems the wind fluid dynamics simulation gets stereoised,
; which leads to leaves, grass, bushes, trees, etc desyncing between each eye.
; Tracing the exact point where it is first steroised is not easy since there
; are a lot of compute shaders that are chained together, and most of the
; buffers carry over to the next frame, but we can interject here - the last
; compute shader in the fluid dynamics simulation to force it to mono.
;
; On SLI this doesn't seem to (often?) get steroeised, so the fact the mono
; copy may not work there doesn't matter.
;
; Note that the leaves simulation has additional depth buffer inputs that will
; mess them up if they are stereo, so they are disabled elsewhere in this file.
[ShaderOverrideWindSimulation]
hash = 91006003dd480d20
cs-t2 = mono copy cs-t2
The second problem was that the leaves simulation took copies of three depth buffers (from the POV of the camera and overhead), which it used so the leaves would land on the ground, but could lead to a desync between both eyes. The above approach *might* have worked for a single GPU, but it did not for SLI - I had to kill those inputs instead (which means the leaves never settle on the ground, but who will notice?). There's also some remnants here of the debug shaders I was using to identify this - dig through the rest of the d3dx.ini and custom shaders shipped with that fix if you are interested to see what I did there:
;;;;;;;;;;; LEAVES ;;;;;;;;;;;;;
; The leaves falling from the trees get out of sync when Stereo compute shaders
; and/or SLI are enabled. This is due to the leaf physics compute shader using
; a stereo depth buffer, which leads to physics desync. To fix this, we unbind
; the depth buffer from cs-t3, effectively stopping the leaves from interacting
; with the world, and keeping them in sync. It does mean they don't settle on
; the ground, but I doubt anyone will notice.
;
; Alternative solutions that did not work:
; - cs-t3 = mono copy cs-t3 (driver heuristics ignored this and did it stereo)
; - cs-t3 = stereo2mono cs-t3 (not working in this game for some reason)
; - disable stereo compute shaders (ignored in SLI (driver bug?), breaks fog)
; - restrict stereo compute shaders to same resources as graphics (no effect)
; - force the leaf structured buffer to mono at time of creation (no hash to match)
; - ask the driver not to stereoise this paricular CS (no API to do this)
; - replace the leaf buffer with our own mono buffer (driver seems to be
; ignorring the creation mode, and even if it wasn't this would need 3DMigoto
; support to match original buffer as there are multiple active at a time)
;
; If examining this, remember the SGraphicParticle structured buffer must be
; cleared to resync the physics (including spawning new leaves). One way to do
; this is to set 'analyse_options = clear_rt' globally then run frame analysis.
;
; Also disable cs-t2 and cs-t4 - these are mostly mono depth buffers (for cs-t2
; that is probably a bug since it is from the POV of the camera, but cs-t4 is
; probably supposed to be mono since it is an overhead view), but include some
; stereo elements that could cause desync.
[ShaderOverrideLeavesCS1]
hash = 74cb1f2b7151ee43
;post ResourceDebugLeaves = copy cs-u2
;ResourceDebug2D = copy cs-t3
ResourceDebugTransparentDepthBuffer = ref cs-t2 unless_null
cs-t2 = null
cs-t3 = null
cs-t4 = null
Lastly, also coming back to the effects I mentioned that render in mono. Here's a couple screenshots to demonstrate:
The fact that these look to be correct in one eye tells you that it is not a problem that can be fixed by editing a shader. Some possibilities:
- These might have used a compute shader that was mono, and by enabling stereo compute shaders they might be fixed
- The driver might be creating a mono texture where it needed to be stereo - you should be able to identify it with frame analysis (look for either a texture missing the left eye, or with a left eye that is exactly the same as the right eye) and use a TextureOverride to force it to stereo.
- The game may be doing a depth only pass with no render target assigned. In theory, StereoTextureEnable = 0x00000400 (ENABLE_SEPARATION_IF_MONORT) is supposed to fix this, but has never worked for me. This does:
;;;;;;;;;; TEMPORAL FILTERING + SSR + SINGLE GPU FIX ;;;;;;;;;;;;;;
; The screen space reflections use a depth buffer, which was drawn to with no
; render target or pixel shader assigned, so the driver does not stereoise it.
; This assigns a dummy render target for this depth pass, which causes the
; driver to stereoise the depth buffer and fixes the reflections.
[ResourceDummyRenderTarget]
format = R8G8B8A8_UNORM
[ResourceDummyRenderTargetBak]
[ShaderOverrideDepthPass]
hash = cdf6be32865cf758
ResourceDummyRenderTarget = copy_desc oD
ResourceDummyRenderTargetBak = ref o0
o0 = ResourceDummyRenderTarget
post o0 = ResourceDummyRenderTargetBak
- The game may be doing a graphics only pass with no depth target assigned. In theory, StereoTextureEnable = 0x00000080 (ENABLE_SEPARATION_IF_ZBNULL) is supposed to fix this, but has also never worked for me. Something like this should do the trick:
[ResourceDummyDepthTarget]
format = R32_FLOAT
[ResourceDummyDepthTargetBak]
[ShaderOverrideDepthPass]
hash = ...
ResourceDummyDepthTarget = copy_desc o0
ResourceDummyDepthTargetBak = ref oD
oD = ResourceDummyDepthTarget
post oD = ResourceDummyDepthTargetBak
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="bo3b"][quote]Success :)
So, maybe the answer is that we need to use m22 * m23 everywhere I put m22 above. Maybe - it certainly looks that way, but I'm not willing to call it without understanding why m23 is negated in the first place.[/quote]
For Akiba's trip, that looks like they are using a Right-handed coordinate system to me, instead of the normal Left-handed one that DirectX uses by default.
With the RH coordinates, the Z is inverted, which is where the negative comes from. If that is correct, then m22 * m23 should always work.
[url]https://msdn.microsoft.com/en-us/library/windows/desktop/bb205355(v=vs.85).aspx[/url]
Super great post, thanks for writing that up.[/quote]
One more complexity here worth noting. Probably you cannot always blindly use m22*m23, because the matrix could also be transposed from the default column major packing used for HLSL.
Because Microsoft's goal is to make every programmer's life worse in every way possible, they inconsistently use row major ordering for some math libraries, but not all. The upshot is that for any given game, I don't think we can be certain that it is packed the same way.
SimpleMath, XNA, DirectXMath, and DX9 fixed pipeline all use row-major matrices. HLSL and BasicMath (Win8) use column-major packing.
See: http://www.catalinzima.com/2012/12/a-word-on-matrices/
and: https://github.com/Microsoft/DirectXTK/wiki/SimpleMath
In this case, the starting LH matrix is:
[code]2*zn/w 0 0 0
0 2*zn/h 0 0
0 0 zf/(zf-zn) 1
0 0 zn*zf/(zn-zf) 0[/code]
But if the packing has been changed, you might see a transposed matrix:
[code]2*zn/w 0 0 0
0 2*zn/h 0 0
0 0 zf/(zf-zn) zn*zf/(zn-zf)
0 0 1 0
[/code]
So... it's probably best to add an additional check that the _m23 value should be either exactly -1 or 1, and that if it is some floating point value, it has probably been transposed.
So, maybe the answer is that we need to use m22 * m23 everywhere I put m22 above. Maybe - it certainly looks that way, but I'm not willing to call it without understanding why m23 is negated in the first place.
For Akiba's trip, that looks like they are using a Right-handed coordinate system to me, instead of the normal Left-handed one that DirectX uses by default.
With the RH coordinates, the Z is inverted, which is where the negative comes from. If that is correct, then m22 * m23 should always work.
One more complexity here worth noting. Probably you cannot always blindly use m22*m23, because the matrix could also be transposed from the default column major packing used for HLSL.
Because Microsoft's goal is to make every programmer's life worse in every way possible, they inconsistently use row major ordering for some math libraries, but not all. The upshot is that for any given game, I don't think we can be certain that it is packed the same way.
SimpleMath, XNA, DirectXMath, and DX9 fixed pipeline all use row-major matrices. HLSL and BasicMath (Win8) use column-major packing.
So... it's probably best to add an additional check that the _m23 value should be either exactly -1 or 1, and that if it is some floating point value, it has probably been transposed.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
That is what I did when I looked at these - I started from the start of the shader and made sure that the result of every step was what I expected before moving on.
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
projection._m32 = -1 and projection._m22 ≈ -1.0
inverseProj._m32 ≈ -1.666 and inverseProj._m22 = 0.0
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
Brefore I do this I need to make sure I have the input values right. Your fix was based on my assumption only that near = 10 and far = 10000 which Is wrong apparently
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
Near=10 is definitely too high since there are things drawn closer, but just use the linear depth function to calculate that dynamically and forget about trying to hard code it.
If you did hardcode it, just set it to something small like 0.01 - I don't honestly think it should matter for what you are doing if you don't have it exact - it's only used to cap the ray tracing if it is tracing *towards* the camera, which it won't be because it's a reflection on a water surface so the angle will never be right (if it was a reflection on a wall that would be a totally different matter).
The far clipping plane doesn't even come into this equation - the max distance thing does not have to match that, though it does make some sense to use it... but any large value that will be close to the vanishing point on the horizon should be ok, and 10000 seems reasonable to me. Just not FLT_MAX or infinity that will throw out the multiplication - keep it sane.
The problem you had before was that you were using bad guesses for near & far to calculate the linear depth, which was massively throwing out the starting coordinate for ray tracing. With the linear depth function I gave you this is a non-issue because it doesn't need to know those values.
That would be a shame. I can look at these again when I have some time, but I'm pretty busy.
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
linearizeDepth(0) spits out 0.6
linearizeDepth(1) = 10000
so I set cb_nearPlaneZ and cb_maxDistance, but still the shift remains.
I've recorded a short video showing the sampling shift and the artiffacts outside the texture coordinates which show up on the red area (you can press C in game to change the camera's angle) maybe that will give you some clues, as I'm still clueless.
Besides the whole reflection is moved up, even the rocks are not showing up on the reflection.
https://youtu.be/o2uICcgWYxs
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
I am trying to reduce depth allocation for the weapons in Call of duty Black ops 2 Zombies. I used for this the shaderoverride field in d3dx.ini and I was successful until a certain point.
I have certain PS&VS (ex. Hands, handgun) that affect also other objects.
I will take the hands as example. see images.
PS
VS
I tried this
[ShaderOverride27] ;hand
Hash=94c92cdd1efef1a6
Convergence=0.3
Separation=0.7
partner=282ef6805ab210fa
Result
However it does not work, whatever I tried.
What am I doing wrong? how should this be solved?
Intel i7 8086K
Gigabyte GTX 1080Ti Aorus Extreme
DDR4 2x8gb 3200mhz Cl14
TV LG OLED65E6V
Avegant Glyph
Windows 10 64bits
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
This is a little bit above my understanding :))
Just ust copy pasting this above return in the file does not work
Could you please give me more detail? :D
Attached the VS
Intel i7 8086K
Gigabyte GTX 1080Ti Aorus Extreme
DDR4 2x8gb 3200mhz Cl14
TV LG OLED65E6V
Avegant Glyph
Windows 10 64bits
Assuming o0 is SV_Position (it might not be - check the function prototype), add this to the end of the main function:
Replace something and something_else with numbers, using trial and error to find values that work well.
A couple of points of warning:
- You are going to be adjusting vertex shaders with "bones" - we rarely need to edit these and they often suffer from decompiler bugs causing them to move somewhere weird, introduce gaps or misalignments, completely disappear, etc. If they do, you either need to find and fix the decompiler bug, or switch to assembly, which gets even more complicated.
- There may not be a value you can use for "something" that works in every situation.
- There may not be a value for "something_else" that works in every situation (different convergence settings), though there are other types of adjustments you could use instead to achieve a similar result that might work better or worse (such as a depth bias or capping the depth to a minimum value).
- If this adjustment messes up the lighting/shadows on the hands, you might need to use a different type of adjustment, such as multiplying all four components of the coordinate by a value, e.g. o0 *= 1.1;
I almost never add these type of overrides because they usually involve compromises that I don't deem acceptable (e.g. get too close to one of the other objects the shader controls and it will break, might cause issues in cutscenes, etc), but that depends on the game. You could add a toggle key if those compromises are situational.
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
Meanwhile, I received some guidance from DHR for this shaders, and did the fix using a similar formula
It works very well, no artefacts during gameplay (only in SP and MP menu, but nothing major). I already put the fix on the forum in case there are others that still play this game from time to time.
I will try with your recommendation also to see how it works, I suppose the result will be similar.
Thank you!
Intel i7 8086K
Gigabyte GTX 1080Ti Aorus Extreme
DDR4 2x8gb 3200mhz Cl14
TV LG OLED65E6V
Avegant Glyph
Windows 10 64bits
Biggest issues are several effects render in one eye only (I suspect these are compute shaders, and unfortunately stereoflagsdx10 0x00004000 can't be used here and breaks things even further. More on this later), and some other effects are rendering in mono (although strangely they are in the correct position in one eye).
First thing I'll talk about is the issue with shader hunting and frame analysis dumping. As mike reported in the RE7 thread, manually hunting for shaders is not very effective in this game. I won't go into detail on that though, as I much prefer using frame analysis and would rather discuss that.
The first hurdle that I got over was that I was using the clear_rt flag like I normally do and all the images were dumping as completely black, and thankfully removing that helped somewhat. The remaining problem is that for VS/PS shaders 3DM can only dump o1 and o2 drawcall outputs as JPS files, but the o0 output (which is the one that would actually be helpful) can only be dumped as a dds file. Normally that's not a problem, and I could use DSS's python tool to convert it, but these get converted as completely black images. I've tried nearly every single DDS viewer out there, and all of them can't open these files due to an unsupported compression. I'm guessing that frame analysis dumping is probably in a "as good as it gets" state, but is there anything that can be done here?
Back to the issue about the compute shaders / one eye rendering effects. Frame analysis does dump some CS drawcalls as JPS, and when it does it always comes out as left eye shows the image, and right eye is all black. If I try enabling stereoflags, then it breaks pretty much EVERYTHING to being one eye only, and doing a frame analysis dump will have all the VS/PS images look the same as a CS image dump usually does. I've tried all the known common bits for stereoflags, and they all produce the same result. Is there any way for 3DM to force the same result as what the stereoflags achieves and get separate outputs for each eye?
Lastly, also coming back to the effects I mentioned that render in mono. The most common broken effect like this are specular highlights / light reflections on surfaces. There's one PS that can be disabled that will remove a large portion of these, but not all, and disabling them loses a lot of fidelity so would rather try to avoid resorting to this. Modifying that PS or the VS paired to it does not adjust the position of it, rather doing so adjusts an entire screen effect. Here's a couple screenshots to demonstrate:
Broken specular highlights. Note they appear correct in left eye:
More broken speculars (and other details/lines) before disabling HDR shader:
After disabling HDR shader, removes specular highlights but other broken effects remain:
HDR shader still disabled, note that trees still have broken lighting reflections:
In the screenshots above you'll see that there are 2 different broken effects, the specular highlights and also other details/outlines on the car. Through some additional hunting I managed to find the VS/PS pair responsible for rendering the entire body of the car, which seems to be the best candidate I can find for this, but even still I'm not certain if it's the correct shader to be working on. Reasons why I think this could be a candidate are when making the VS mono the body and the broken effects are perfectly aligned, and I found that adjusting the o1 output in the VS does cause the specular highlights to move, but not in the proper way (like, the area of effect's position itself doesn't move, only the visual effects inside of it does. Have tried different fix methods, ie. world space and clip space), and adjusting o2 causes those other details to move (but just like the specular highlights, it doesn't adjust in the correct fasion). I'm thinking these effects will require some other type of fixing magic... because these appear correct in one eye I'm thinking driver heuristics are off, and it may need one of those fancy custom resource tricks DSS uses in his fixes. Any suggestions here?
Guess that's enough for now. Hope I was able to explain things clearly enough. Thanks for reading all that. ;)
3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot
Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king
Hehe, never say that - it's only "as good as we've made it so far". Improvements are definitely possible, it's just a question of spending time on it as opposed to other things.
Ok, I've just done something like this in the WATCH_DOGS2 fix - I needed stereo compute shaders enabled for certain effects, but enabling them broke the wind simulation leading to leaves, grass, bushes, etc getting desynchronised between each eye.
The trick is that you need to identify any compute shaders that get broken by enabling stereo compute shaders and make sure that their inputs are identical between both eyes - if their inputs are identical and their code is identical than they should produce an identical result. That's the theory anyway - things can get a little tricky in practice.
The fix for WATCH_DOGS2 involved several parts. Firstly, the wind simulation used a Texture2D, which was getting stereoised on single GPU (but not on SLI). Forcing the texture to mono crashed the game, so instead I had to do this:
The second problem was that the leaves simulation took copies of three depth buffers (from the POV of the camera and overhead), which it used so the leaves would land on the ground, but could lead to a desync between both eyes. The above approach *might* have worked for a single GPU, but it did not for SLI - I had to kill those inputs instead (which means the leaves never settle on the ground, but who will notice?). There's also some remnants here of the debug shaders I was using to identify this - dig through the rest of the d3dx.ini and custom shaders shipped with that fix if you are interested to see what I did there:
The fact that these look to be correct in one eye tells you that it is not a problem that can be fixed by editing a shader. Some possibilities:
- These might have used a compute shader that was mono, and by enabling stereo compute shaders they might be fixed
- The driver might be creating a mono texture where it needed to be stereo - you should be able to identify it with frame analysis (look for either a texture missing the left eye, or with a left eye that is exactly the same as the right eye) and use a TextureOverride to force it to stereo.
- The game may be doing a depth only pass with no render target assigned. In theory, StereoTextureEnable = 0x00000400 (ENABLE_SEPARATION_IF_MONORT) is supposed to fix this, but has never worked for me. This does:
- The game may be doing a graphics only pass with no depth target assigned. In theory, StereoTextureEnable = 0x00000080 (ENABLE_SEPARATION_IF_ZBNULL) is supposed to fix this, but has also never worked for me. Something like this should do the trick:
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
One more complexity here worth noting. Probably you cannot always blindly use m22*m23, because the matrix could also be transposed from the default column major packing used for HLSL.
Because Microsoft's goal is to make every programmer's life worse in every way possible, they inconsistently use row major ordering for some math libraries, but not all. The upshot is that for any given game, I don't think we can be certain that it is packed the same way.
SimpleMath, XNA, DirectXMath, and DX9 fixed pipeline all use row-major matrices. HLSL and BasicMath (Win8) use column-major packing.
See: http://www.catalinzima.com/2012/12/a-word-on-matrices/
and: https://github.com/Microsoft/DirectXTK/wiki/SimpleMath
In this case, the starting LH matrix is:
But if the packing has been changed, you might see a transposed matrix:
So... it's probably best to add an additional check that the _m23 value should be either exactly -1 or 1, and that if it is some floating point value, it has probably been transposed.
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
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64