3.1
- thalixte
OtisInf wrote: @thalixte: weird! I load your save file, but everything keeps on working here... No matter what angle I take, or where I move the player ... I also downgraded every gfx setting to 'low' as you suggested that the # of vertices dropped below a given threshold so I thought perhaps it's the gfx settings I have (everything maxed) but... nope 1920x1200... works like a charm. Will try other resolutions now but I don't know what triggers it on your part...
(edit) windowed mode, 1440x900 or so, no problem either... very odd. ..
Will now install the photomode mod to see if I can reproduce it without gerhalt's ass in the way
(edit) I remembered I could just use Ansel and I can't reproduce it with that either. Flying around, like you in your video, same spot, using displaydepth, not a problem at all, right depth buffer is chosen every time, looking at a clear sky, all OK... really weird.
Ansel simply disables reshade effects. I use a TW3 mod ( PhotoMode 2inOne for Debug Console Enabler ) to enable the flight mode (with "F1" key).
Really strange, indeed... I play both TW3 and ACO in 1440p...
It seems that the buffer detection fails when sizeinfo.width and sizeinfo.height return 0. It might be related to the depthstencil_size depth_counter_tracker::get_depth_stencil_size method, not returning the right value.
However, i found a workaround to the pb on my config. I made a slight change in the depth_counter_tracker.cpp method named ID3D11DepthStencilView* depth_counter_tracker::get_best_depth_stencil, like this:
ID3D11DepthStencilView* depth_counter_tracker::get_best_depth_stencil(std::unordered_map<ID3D11DepthStencilView*, depthstencil_size> const& depthstencils, UINT width, UINT height)
{
depthstencil_counter_info best_info = { 0 };
ID3D11DepthStencilView *best_match = nullptr;
float aspect_ratio = ((float)width) / ((float)height);
for (auto it : _counters_per_used_depthstencil)
{
const auto depthstencil = it.first;
auto &depthstencil_info = it.second;
if (depthstencil_info.drawcall_count == 0)
{
continue;
}
auto sizeinfo = get_depth_stencil_size(depthstencils, depthstencil);
bool size_mismatch = false;
LOG(INFO) << "Returning sizeinfo.width " << sizeinfo.width;
LOG(INFO) << "Returning sizeinfo.height " << sizeinfo.height;
// if the size of the depth stencil has the size of the window, we'll look at its counters. If it doesn't we'll try some heuristics, like
// aspect ratio equivalence or whether the height is 1 off, which is sometimes the case in some games.
// ****** slight modification: check if sizeinfo.width and sizeinfo.height are returned ******
if (sizeinfo.width > 0 && sizeinfo.height > 0)
{
if (sizeinfo.width != width)
{
size_mismatch = true;
}
if (sizeinfo.height != height)
{
// check if height is uneven, some games round depthsize height to an even number.
if (sizeinfo.height != (height - 1) && sizeinfo.height != (height + 1))
{
// not a matching height
size_mismatch = true;
}
}
if (size_mismatch)
{
// check aspect ratio.
float stencilaspectratio = ((float)sizeinfo.width) / ((float)sizeinfo.height);
if (fabs(stencilaspectratio - aspect_ratio) > 0.1f)
{
// still no match, not a good fit
continue;
}
}
if (depthstencil_info.drawcall_count >= best_info.drawcall_count)
{
best_match = depthstencil;
best_info = depthstencil_info;
LOG(INFO) << "Match found !!!";
}
}
}
return best_match;
}
With this, no more buffer detection fails, except in one case: in ACO, if i return to desktop, then i revert back to the game. For a reason i ignore, the sizeinfo retrieval fails. It does not happen with TW3.
I added some logs to check it, and here is what it returns for ACO in this specific case:
2018-01-02T21:31:40:401 [03832] | INFO | Redirecting 'IDXGISwapChain::SetFullscreenState(00000001A92EE7D0, FALSE, 0000000000000000)' ...
2018-01-02T21:31:40:559 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:40:559 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:40:559 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:40:559 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:40:559 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:40:559 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:40:559 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:40:559 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:40:559 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:40:559 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:40:559 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:40:559 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:40:858 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:40:858 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:40:858 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:40:858 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:40:858 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:40:858 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:40:858 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:40:858 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:40:858 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:40:858 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:40:858 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:40:858 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:41:164 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:41:164 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:41:164 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:41:164 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:41:164 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:41:164 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:41:164 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:41:164 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:41:164 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:41:164 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:41:164 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:31:41:164 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:31:41:447 [03832] | INFO | Returning sizeinfo.width 0
I should have this, when it works:
2018-01-02T21:30:41:724 [03832] | INFO | Redirecting 'IDXGISwapChain::SetFullscreenState(00000001A92EE7D0, FALSE, 0000000000000000)' ...
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.width 512
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.height 512
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.width 1024
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.height 1024
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.width 64
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.height 64
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.width 2048
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.height 2048
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.width 0
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.height 0
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.width 2144
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.height 1208
2018-01-02T21:30:41:973 [03832] | INFO | Match found !!!
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.width 64
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.height 64
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.width 1280
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.height 720
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.width 64
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.height 64
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.width 1072
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.height 604
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.width 2560
2018-01-02T21:30:41:973 [03832] | INFO | Returning sizeinfo.height 1440
2018-01-02T21:30:42:327 [03832] | INFO | Returning sizeinfo.width 2048
2018-01-02T21:30:42:327 [03832] | INFO | Returning sizeinfo.height 2048
2018-01-02T21:30:42:327 [03832] | INFO | Returning sizeinfo.width 2144
2018-01-02T21:30:42:327 [03832] | INFO | Returning sizeinfo.height 1208
2018-01-02T21:30:42:327 [03832] | INFO | Match found !!!
I tested Mass Effect Andromeda (with TAA on), and it works well on it, even if i go back to desktop, then return to the game:
(edit) I have a Maxwell Titan, but not a Pascal one, and a gsync monitor.
(edit) Two other videos from ACO showing the buffer detection fail with the original code, so you can try to reproduce it on ACO: ACO videos
- OtisInf
Yes I know it well, but it took more effort (as I've finished TW3 some time ago ) ansel only disables depth buffer when taking a screenshot (as it uses tile-based rendering, even for native res shots, for the rest it's just a camera manipulation system so it uses the same framebuffer), when flying around the display depth shader worked fine and I couldn't detect any problems whatsoever.thalixte wrote:
OtisInf wrote: @thalixte: weird! I load your save file, but everything keeps on working here... No matter what angle I take, or where I move the player ... I also downgraded every gfx setting to 'low' as you suggested that the # of vertices dropped below a given threshold so I thought perhaps it's the gfx settings I have (everything maxed) but... nope 1920x1200... works like a charm. Will try other resolutions now but I don't know what triggers it on your part...
(edit) windowed mode, 1440x900 or so, no problem either... very odd. ..
Will now install the photomode mod to see if I can reproduce it without gerhalt's ass in the way
(edit) I remembered I could just use Ansel and I can't reproduce it with that either. Flying around, like you in your video, same spot, using displaydepth, not a problem at all, right depth buffer is chosen every time, looking at a clear sky, all OK... really weird.
Ansel simply disables reshade effects. I use a TW3 mod ( PhotoMode 2inOne for Debug Console Enabler ) to enable the flight mode (with "F1" key).
What's so strange about this is that width and height are the texture width/height from the D3D11_TEXTURE2D_DESC struct, which are never 0 (range is 1-max_based_on_feature_level), see: msdn.microsoft.com/en-us/library/windows...476253(v=vs.85).aspx ). Perhaps this is a driver issue, no idea, but something's off. I use windows 8.1 x64, latest nvidia driversReally strange, indeed... I play both TW3 and ACO in 1440p...
It seems that the buffer detection fails when sizeinfo.width and sizeinfo.height return 0. It might be related to the depthstencil_size depth_counter_tracker::get_depth_stencil_size method, not returning the right value.
As in: it then never recovers? Or after 30 frames? (as there's a delay). Checking for 0 could be a valuable workaround, however adding code for something that has its cause elsewhere is never a good idea. that said, I'll see if I can find evidence on my system if width/height are 0 as well in some cases...However, i found a workaround to the pb on my config. I made a slight change in the depth_counter_tracker.cpp method named ID3D11DepthStencilView* depth_counter_tracker::get_best_depth_stencil, like this:
(snip)
With this, no more buffer detection fails, except in one case: in ACO, if i return to desktop, then i revert back to the game. For a reason i ignore, the sizeinfo retrieval fails. It does not happen with TW3.
I do see I can get rid of the sizeinfo struct there so I at least will make that change.
Thanks for testing it on more games btw!
(edit) I put a breakpoint with a conditional after the texture retrieval, but it never reports either width or height being 0 in ACO, alt-tabbing or not, looking up to the sky...
Perhaps crosire has an idea, but other than that, I don't know what causes this. I'll ask him in the PR if the workaround is required.
- thalixte
OtisInf wrote: As in: it then never recovers? Or after 30 frames? (as there's a delay). Checking for 0 could be a valuable workaround, however adding code for something that has its cause elsewhere is never a good idea. that said, I'll see if I can find evidence on my system if width/height are 0 as well in some cases...
No, it never recovers, except if i change the graphics settings, but to do so, i must disable the shader. Obviously, it do not happens on the other games i have tested...
(edit) Ok, tested your last commit on ACO and TW3, and no more problems... It works perfectly. Thks a lot !!
If i understand how it works, may i suggest you a very slight modification in ID3D11DepthStencilView* depth_counter_tracker::get_best_depth_stencil(UINT width, UINT height): if the retrieval of texture_desc fails with resource->QueryInterface(&texture), it is not necessary to run the code above, so, i would suggest:
depthstencil->GetResource(&resource);
if (!FAILED(resource->QueryInterface(&texture)))
{
texture->GetDesc(&texture_desc);
}
else continue;
- OtisInf
Your change proposal is a good catch! it's indeed a dumb mistake I made. I'll make the necessary changes and push to the PR so it gets merged too Thanks for testing and feedback!
- thalixte
OtisInf wrote: Ah you weren't using the latest build! I already wondered wtf was wrong haha Ok, that's a relief, glad it's not something with the code
Your change proposal is a good catch! it's indeed a dumb mistake I made. I'll make the necessary changes and push to the PR so it gets merged too Thanks for testing and feedback!
Maybe you're right , but i'm glad to tell you that your latest build has resolved all my issues
Again, thks for all. I think you will make some gamers happy with those modifications on Reshade. I think, for instance, of the SuperDepth3d shader, that will work with almost every game, if the buffer data retrieval is solved with Reshade (VR in ACO, yesssss !!!):
- Marty McFly
- Martigen
I second this. Not just for reasons above, but because sometimes using the display-depth shader you get all black or all white, and I don't know if the depth buffer hasn't been found, or it -has- been found but I need to tweak logarithmic/reversed/setting far distance etc to get it working. Would simply save time knowing if it couldn't be found in the first place.Marty McFly wrote: Quick question, is it possible to replace the depth buffer with a reserved value like -1 or whatever outside [0,1] range to allow for checking in shader if buffer is invalid? Or for example, add a warning ingame that the correct depth buffer hasn't been found? I get quite a lot of messages about DoF not working, MXAO not working, blaming the shader all the time.
- OtisInf
Games often use multiple depth stencil buffers. E.g. in AC:Origins there were sometimes 24 or more per frame, with various sizes. Reshade did a good job picking the right one out of that set which had the output frame's depth buffer but in some cases this went wrong for reasons already discussed here (like in AC:O) and other code was needed. I too thought about checking the depth buffer and simply check whether it's empty and skip it if it is. That however requires a read of the texture to CPU, which will always be slow(er): compute/pixelshader renders value(s) to a render target which is then read back using CopyResource. This can be a small texture of course, we just need 1 value back (is it empty or not). the value read back is then used to either accept the buffer or not.Marty McFly wrote: Quick question, is it possible to replace the depth buffer with a reserved value like -1 or whatever outside [0,1] range to allow for checking in shader if buffer is invalid? Or for example, add a warning ingame that the correct depth buffer hasn't been found? I get quite a lot of messages about DoF not working, MXAO not working, blaming the shader all the time.
there might be a radical different way tho: move everything to the GPU: reshade first runs shader which renders to its output the depth info from the texture that contains data, it renders to the depth buffer texture used by all other shaders (so basically copying it). This is also slower than what we have today btw but could mean an alternative.
tho I doubt that will solve all problems regarding users who blame the wrong thing: e.g. in a game like TombRaider (2013), the game clears the depth buffer before Present, so there's no info in the buffers (there are 2, both are empty), nothing can preserve that. Telling them 'the depth buffer is empty' will mean as much to them as "ahy45r022hgfh shfd!", i.e.: nothing, as a lot of them don't know what a depth buffer is, nor that it's essential for some shaders.
- thalixte
OtisInf wrote: tho I doubt that will solve all problems regarding users who blame the wrong thing: e.g. in a game like TombRaider (2013), the game clears the depth buffer before Present, so there's no info in the buffers (there are 2, both are empty), nothing can preserve that. Telling them 'the depth buffer is empty' will mean as much to them as "ahy45r022hgfh shfd!", i.e.: nothing, as a lot of them don't know what a depth buffer is, nor that it's essential for some shaders.
So, the buffer detection you implemented will not work for every game, what a pity ! But it will for the majority i guess. I don't think there are a big number of games that clear the depthbuffer before the end of the frame rendering.
So, maybe i will tell something really stupid, but i remember that dxd9 GeDoSaTo injector had the ability to inject its own shaders, not only at the end of frame rendering, but also during the frame rendering, as it is explained here ( PC Gamer Durante's article on geDoSaTo ). So, in this case, it would be possible to retrieve depth buffer data before they are removed by the game engine...
- OtisInf
indeed, it just picks the buffer, if it's empty that's not determinable. If the game clears it, then it won't be helpful to pick any buffer, it's just empty. Some engines also render several parts to different buffers and blend the results together (e.g. assassin's creed 3 did this in e.g. cutscenes: the backgrounds were in the main depth buffer but the character was often not in the depth buffer, suggesting it was rendered off screen and the result then blended with the background in the main output buffer. this only works if there's nothing in front of the character, but that's often the case with cutscenes. )thalixte wrote:
OtisInf wrote: tho I doubt that will solve all problems regarding users who blame the wrong thing: e.g. in a game like TombRaider (2013), the game clears the depth buffer before Present, so there's no info in the buffers (there are 2, both are empty), nothing can preserve that. Telling them 'the depth buffer is empty' will mean as much to them as "ahy45r022hgfh shfd!", i.e.: nothing, as a lot of them don't know what a depth buffer is, nor that it's essential for some shaders.
So, the buffer detection you implemented will not work for every game, what a pity ! But it will for the majority i guess. I don't think there are a big number of games that clear the depthbuffer before the end of the frame rendering.
d3d9 is different tho, I think he detected the switch to an orthogonal viewport (for hud rendering) and thus ran the shaders right before that, but that's guessing. Reshade could intercept the call to D3D11DeviceContext::ClearDepthStencilView and e.g. postpone it till after the reshade shaders have run, IF the view to clear is the chosen depth buffer of the previous frame. But this likely has side effects: perhaps the game clears the depth buffer for other reasons (not every pass uses the depth buffer after all). so all in all, it's not a simple problemSo, maybe i will tell something really stupid, but i remember that dxd9 GeDoSaTo injector had the ability to inject its own shaders, not only at the end of frame rendering, but also during the frame rendering, as it is explained here ( PC Gamer Durante's article on geDoSaTo ). So, in this case, it would be possible to retrieve depth buffer data before they are removed by the game engine...
- Marty McFly
OtisInf wrote: there might be a radical different way tho: move everything to the GPU: reshade first runs shader which renders to its output the depth info from the texture that contains data, it renders to the depth buffer texture used by all other shaders (so basically copying it). This is also slower than what we have today btw but could mean an alternative.
As far as I know, this is what ENBSeries does. I read multiple times on enbdev that Boris creates his own buffer so I assume he assembles his own one from various accessible as Skyrim has a shitload of different ones.
Also, about HUD masking, are there any identifiers like switch to orthogonal viewport or similar that are always true for when HUD is drawn (but for other occurences as well)? If so, maybe add a switch that cycles through all of them until the right one is found. Current ini layout would allow for such a game specific value. I know you're looking for a way that works on all games automatically but even the depth linearizing requires user interaction.
- sean
- crosire
- Topic Author
- sean
CAT-QuickHeal: Trojan.Shelma
CrowdStrike Falcon: malicious_confidence_60% (D)
Fortinet: W32/Shelma.VNW!tr
MAX: malware (ai score=99)
ViRobot: Trojan.Win32.Z.Shelma.4160512
and the ones I really trust didn't find any malware at all: Kaspersky, Avira, Avast, NOD32 - so, I would assume there is no virus. Just wanted to double check. I guess, thanks.
- crosire
- Topic Author
- soetdjur
Kind regards!
- Martigen
Just released Nvidia 390.65 drivers. Apart from a security fix for the meltdown/spectre debacle, there's also this:
Gaming Technology
Adds support for NVIDIA Freestyle which lets you apply post-processing filters to your games while you play.
us.download.nvidia.com/Windows/390.65/39...op-release-notes.pdf
Some of these look like they're Reshade shaders (Clarity, HDR toning...)
- thalixte
crosire wrote: Because it's a false positive. AntiVirus software is not perfect, they make mistakes. For some reason the signature of the setup tool has similarities to an existing malware application, which is why some raise the alarm. A few of the big ones initially complained too, but were since notified, so that their labs checked ReShade, deemed it safe and therefore the detection was fixed so they don't find malware anymore (since there is none).
Crosire,
First of all, thk U for this fantastic tool ! I have just two little questions:
- Do you plan to change the release version of reshade after your last commits to the master branch on github, that included the lastest updates from OtisInf, and to make it available on the reshade site (or, maybe it is already the case) ?
- Are you working with nvidia folks to provide freestyle, or is it an nvidia exclusive implementation ?
Also, would it be possible for you to merge branch master into openvr ?
Bya advance, thks a lot ...
- crosire
- Topic Author
All code is used with explicit permission by the authors (and was actually partly written specifically for FreeStyle). Nothing wrong here.Martigen wrote: Some of these look like they're Reshade shaders (Clarity, HDR toning...)
1) Yeah. Soon™.thalixte wrote: First of all, thk U for this fantastic tool ! I have just two little questions
2) I am involved with NVIDIA, yes.
3) Sure, I will merge over once the next release is ready.
- OtisInf
Cool, could you ask them to not use tiled based rendering when they take a screenshot that has the same resolution as the backbuffer? Because it looks like they do now which means they kill off the depth buffer and the effects that rely on itcrosire wrote: 2) I am involved with NVIDIA, yes.
Not sure that's what he does tho. All you need to do is create a texture from the depthbuffer and add a sampler on it (afaik that's what reshade does) and I doubt boris does something else. (but it might be he does something different. the AO in ENB is so terribly slow that it can't be he does something efficient)Marty McFly wrote: As far as I know, this is what ENBSeries does. I read multiple times on enbdev that Boris creates his own buffer so I assume he assembles his own one from various accessible as Skyrim has a shitload of different ones.
In general rendering a HUD is using orthogonal projection so when the projection matrix is switched to an orthogonal projection matrix, it's assumable HUD elements are rendered. But it can also be elements from the game are rendered, so I don't think it's a 100% guaranteed thing, but surely something to look into. HUD toggles based on shaderhashes are doable but you first have to determine the shader hashes for a game and that can be a tedious process without tooling (3d migoto helps, but not always).Also, about HUD masking, are there any identifiers like switch to orthogonal viewport or similar that are always true for when HUD is drawn (but for other occurences as well)? If so, maybe add a switch that cycles through all of them until the right one is found. Current ini layout would allow for such a game specific value. I know you're looking for a way that works on all games automatically but even the depth linearizing requires user interaction.