qUINT

Marty McFly wrote: Which version are you using and which other settings?

the one from patreon, archive name: "Reshade 0.6C"

u can see setting below. RESHADE_DEPTH_LINEARIZATION_FAR_PLANE is set 10000 ( i found that with high FAR plane and low thickness I get fewer halos )

AO IL miplevels are set to 2, yet shader takes alot to compute with INFINITE_BOUNCES

along with setttings u can see some "noisy dots".. they actually look like they were cropped with "saturate()" at some point at the shader.

Message me on Patreon or the discord server, I'll send you a build that runs a little faster, something I discovered yesterday but will release for the patrons along the the planned sky color update.

Siridon wrote: Hi, I noticed that in dx12 games RT works by half, AO works, but GI does not, I tested SOTR and Elevator Demo, the access depth works correctly, I used the user dll thalixte.
Do not know what could be the reason that GI does not work?

I can confirm this issue (with MXAO, which RT is based off of), here are DX11 vs 12 comparisons I made with Serious Sam Fusion 2017: imgur.com/a/LSfIlo1
I included both how MXAO compares between DX11 and 12 and DisplayDepth, to show that the depth information (at least visually) is identical. I should also note that mxao's "normal vectors" view is pure blue.
This is of course using thalixte's latest D3D12 depth commits and the latest version of quint.

Huh, I have no idea what could possibly cause this - as MXAO normal vector calculation is highly similar to display depth. To me it looks like the depth is inverted on DX 12 but that would flip all normal vectors and the colors would be swapped on the right side. I also don't know how to fix this since I don't have a single DX12 game. Maybe it's a ReShade problem?

Marty McFly wrote: Huh, I have no idea what could possibly cause this - as MXAO normal vector calculation is highly similar to display depth. To me it looks like the depth is inverted on DX 12 but that would flip all normal vectors and the colors would be swapped on the right side. I also don't know how to fix this since I don't have a single DX12 game. Maybe it's a ReShade problem?

Yes, in the Niko of Death screens, the depth seems to be inverted. Maybe changing the preprocessor values will help.

Marty McFly wrote: Huh, I have no idea what could possibly cause this - as MXAO normal vector calculation is highly similar to display depth. To me it looks like the depth is inverted on DX 12 but that would flip all normal vectors and the colors would be swapped on the right side. I also don't know how to fix this since I don't have a single DX12 game. Maybe it's a ReShade problem?

Yeah, its definitely not a depth inversion issue (at least not in a way reshade was built around), here are examples of DMC5 with/without the depth reversed setting enabled, as well as SMAA depth detection working properly:
imgur.com/a/dWpD4bZ
(IL is also supposed to be enabled in these)
I should note that PPFX SSDO is also broken (more broken actually, as I'm not getting any output from that). DOF shaders seem to be working though (hard to test exactly due to lack of a debug view).
As for testing, HITMAN 2 has a DX12 version and the first level is free, so that's a possible testbed (although it has forced temporal AA, so not a perfect choice for testing AO), HITMAN (2016) is in the same boat. I believe WOW has a DX12 renderer now too (and of course has a free trial). If you do end up testing it note that reshade will reload constantly in the menu if you don't manually select a depth buffer due to depth buffer selection constantly changing (Also exclusive fullscreen doesn't work, has to be windowed or borderless windowed).

du wrote: My English is poor
I wrote a shader
It uses a 3dlut to generate a mask
Put ssr between lutmask1 and lutmask2
.......

Thanks so much, this is everything I wanted!

@Marty: Yep, completely understandable, black things can be shiny too. Still, I rarely use quint's SSR for newer games, which most often already have that feature built in. For older, low poly stuff, masking blacks seemed like the simplest solution, and imo it does the job pretty well in games like Quake 2, where most stuff is metal.
Again, thank you both for you efforts.

Hey. Is there any way to get rid of this outline on the edges? Using the last version of shader and reshade.

Hello,
is there any plan at all to support rtx implementation with dx12 api ?

tirrorex wrote: Hello,
is there any plan at all to support rtx implementation with dx12 api ?

That would have to be an addition to reshade, not an addition to any specific shader. Shaders just take the info provided by reshade and performs their operations on it, and reshade does not provide any DXR info as it stands.

Is this possible to use with ReShade 1.1?
If not which version is the ideal (less issues) to use with?

The latest one?

Hey Marty, I really appreciate all the great work you've done for us; it's allowed so many people to mold games to their liking, and that's not something many people can boast about. I've been using your shaders forever, and always found a way to do exactly what I wanted to do with them.

Recently, I started playing Bloodstained, and that game exhibits an issue that isn't all too uncommon (and isn't easy to work around in this particular game, for various reasons e.g. being 2.5D). I think I have a solution, and I was wondering if it's something you can easily implement (I don't think it would be worth much of your time, but from my layman point of view it seems like it would be a quick and easy addition).

The problem is that the game blanks out the depth buffer whenever a menu is opened (or rather, fills it up full white) which obviously doesn't play well with your DoF. How difficult would it be to add an option to disable dof whenever there is no depth information? Is this something that is difficult to detect? This fix wouldn't work for games that retain their buffer under the menu, but this isn't the first game I've seen that blanks it out. MXAO doesn't interfere with this, but dof just blurs the entire screen.

This may already be possible by changing a line of code or something, if that's the case I'd really appreciate it if anyone can point me in the right direction.

Thanks!

Apart from binding ReShade to the same button that the menu uses, no real way. I can detect that every pixel onscreen has the same value - with a vast performance overhead - so this isn't feasible. The problem happens when you use static dof, which means the focal depth is a static number.

The more the depth of any pixel deviates from this value the higher the blur intensity. If every pixel has the same value, every pixel gets the same absolute difference between focal depth and actual depth and therefore same blur intensity. Autofocus mode doesn't suffer from this, all sample points will have same depth as the rest and result in no blur.

My solution to this problem would be either toggling ReShade off each time or binding ReShade to the same key as the menu. There's really nothing else you can do.

Have you tried to use UIDetect?

Marty McFly wrote: Apart from binding ReShade to the same button that the menu uses, no real way. I can detect that every pixel onscreen has the same value - with a vast performance overhead - so this isn't feasible. The problem happens when you use static dof, which means the focal depth is a static number.

The more the depth of any pixel deviates from this value the higher the blur intensity. If every pixel has the same value, every pixel gets the same absolute difference between focal depth and actual depth and therefore same blur intensity. Autofocus mode doesn't suffer from this, all sample points will have same depth as the rest and result in no blur.

My solution to this problem would be either toggling ReShade off each time or binding ReShade to the same key as the menu. There's really nothing else you can do.

Ah! That's exactly the information I was looking for. Thank you very much for your thoughtful explanation, I now understand.

And yeah, I've had to use static dof because of the 2.5d nature of the game, and the way enemies are layered (flying enemies are very close to the camera etc...) Thankfully it works perfectly fine for everything, except menus (fixable with uidetect as Durante points out), and a couple boss rooms where the camera zooms out.

Duran.te wrote: Have you tried to use UIDetect?

Hey! I didn't know you posted here, I'm also very thankful for all the work you've done (you allowed me to fully discover my favorite game!).

Thanks for the suggestion, this is exactly what I will end up doing for this game. UIdetect works great, but it does require more setting up so I wanted to check if it could be done automatically for cases like these.

Thank you both for your help!

I'm new and I have a question about RT shaders.

the quality of the Benchmark Superposition without defects of Halos or bleeding in Fog/volumetric lights will be achieved?.

Rayman_77 wrote: I'm new and I have a question about RT shaders.

the quality of the Benchmark Superposition without defects of Halos or bleeding in Fog/volumetric lights will be achieved?.

Unfortunatly not. It's an inherent limitation of ReShade since it's postprocessing only and the results will ever only be layered on top of the original output. Yout can try to alleviate it but never get rid of it. And not only RT but all shaders.

btw your rt shaders have flickering issues, removing this line solved it. framecount is culprit here
-snip-

Good job, you murdered the temporal supersampling and got strong noise with absolutely no performance gain.