New shader: cinematic depth of field

OtisInf
Topic Author

5 years 8 months ago #21 by OtisInf Replied by OtisInf on topic New shader: cinematic depth of field

crosire wrote: Fixed the bug: github.com/crosire/reshade/commit/5d56c8...dc62093efa0006ee475d . Workaround should no longer be necessary with that.

While visiting the AST ReShade builds a string with the sampler definitions for the current pass. Before the fix it accidentally combined the definitions of the vertex and pixel shader, so if you used the same texture in both, that would cause a redefinition. Now they are seperate like it should be.

Excellent! I indeed lacked the necessary info to fix it properly. Shall I leave the workaround in the shader though? I don't think it does that much harm (it's a preprocessor directive after all), and it then works on people with reshade dlls that don't contain the fix (yet).

The following user(s) said Thank You: Ryukou36, Sinclair

Please Log in or Create an account to join the conversation.

OtisInf
Topic Author

5 years 8 months ago - 5 years 8 months ago #22 by OtisInf Replied by OtisInf on topic New shader: cinematic depth of field

Have updated the shader a bit, with a separation of the near / far plane highlight strength, and a better fading in for the highlights so it's now better controllable, as near plane highlights kick in rather hard as the CoC's are much higher and it's often desired to have no highlights at all in the near plane (or just very soft).

Also added a fix for the focusing helper plane not rendering correctly when the hyperfocal far plane became negative due to long focal length

Last edit: 5 years 8 months ago by OtisInf.

Please Log in or Create an account to join the conversation.

Daodan

5 years 8 months ago #23 by Daodan Replied by Daodan on topic New shader: cinematic depth of field

I added a crosshair to the manual autofocus that shows up in the focus helper:

I think it's very useful, maybe you want to add something like that to the shader.

Added uniform:

Warning: Spoiler!

PS_FocusHelper:
(The last couple of lines)

Warning: Spoiler!

One additional suggestion regarding the uniform "AutoFocusPoint": the default step size is very coarse, setting it to 0.001 makes it more controllable.

The following user(s) said Thank You: OtisInf

Please Log in or Create an account to join the conversation.

OtisInf
Topic Author

5 years 8 months ago - 5 years 8 months ago #24 by OtisInf Replied by OtisInf on topic New shader: cinematic depth of field

Thanks Daodan! I added your code, and also the slider step fix. I credited you in a thanks in the code. Pushed to PR. I found it so helpful that I also added the crosshair when doing mousedriven autofocusing, Good idea!

If you don't mind me asking, do you have a reference for the math you're using? My math is rather rusty after doing high speed database code for the past 20 years so I didn't understand the exp() usage and I'd like to learn more about that approach as it likely will help me with future shader coding

A link to an explanation or even a term is fine/enough. Thanks!

Last edit: 5 years 8 months ago by OtisInf.

Please Log in or Create an account to join the conversation.

Daodan

5 years 8 months ago - 5 years 7 months ago #25 by Daodan Replied by Daodan on topic New shader: cinematic depth of field

Well thanks!

The idea behind using the exponential function is to prevent sharp edges when drawing something onto the screen (lines, arbitrary curves, etc.) .
Check the plot below out. The y-axis is the value exp() spits out, and the x-axis is basically the distance between the current texcoord and the point to draw.
One property of the exponential function is that is always equals to 1 when the argument is 0. So, when texcoord and the point to draw are fairly close (or overlap) you always get 1 (because the distance is 0). With increasing distance exp()'s result creeps towards 0. The negative factor with which the distance gets multiplied dictates how fast exp()'s result goes to 0.
WolframAlpha Plot Example

[Edit] [strike]The repo is not quite up to date. Will fix it![/strike] Should be fine now.
You can also check out one of my shaders that uses that: AdaptiveTint.fx (the AdaptiveTintDebug technique)
For that to work you also need Stats.fx(h) and Tools.fxh
Shader repository

Last edit: 5 years 7 months ago by Daodan.

The following user(s) said Thank You: OtisInf

Please Log in or Create an account to join the conversation.

OtisInf
Topic Author

5 years 8 months ago #26 by OtisInf Replied by OtisInf on topic New shader: cinematic depth of field

@Daodan: awesome, thanks! Will study this some more and look where I can use this instead of some if's I've in the code!

The following user(s) said Thank You: WalterDasTrevas

Please Log in or Create an account to join the conversation.

WalterDasTrevas

5 years 8 months ago #27 by WalterDasTrevas Replied by WalterDasTrevas on topic New shader: cinematic depth of field

Greetings. I came to thank and share a video of Rising World that I recorded with your Cinematic DOF! Thank you! :cheer:

Please Log in or Create an account to join the conversation.

NesQEdits

5 years 8 months ago #28 by NesQEdits Replied by NesQEdits on topic New shader: cinematic depth of field

Hey! I tryed your shader in CSGO. For the POV its kind of cool, because the gun is sharp and the rest is blurred. But it would be really cool, if there were an option which can adjust the place of the dof itself like "just far in the background" or "closer to the weapon itself". I hope you understand what i mean

Thanks!
drive.google.com/open?id=1DT7KJlxEe7VtEqt12WRT5W_W8WBWxbCr

Please Log in or Create an account to join the conversation.

OtisInf
Topic Author

5 years 8 months ago #29 by OtisInf Replied by OtisInf on topic New shader: cinematic depth of field

Isn't that just adjusting the focus plane? I.e. specifying it manually? I didn't add code to work around a gun element in the depth buffer tho

Please Log in or Create an account to join the conversation.

NesQEdits

5 years 8 months ago #30 by NesQEdits Replied by NesQEdits on topic New shader: cinematic depth of field

thank you for you answer! i managed to get the dof a little bit away from the gun by settings the manuel-focus plane to max 100.000 and the focal length to 10.000. with aperture i adjusted the dof value. for me this result is definitely better than my first try drive.google.com/open?id=1gPAV3lDiJAsL5k-LQQNfR_6M07stZDM0

Please Log in or Create an account to join the conversation.

MaxG3D

5 years 8 months ago #31 by MaxG3D Replied by MaxG3D on topic New shader: cinematic depth of field

That was THE DOF shader I was waiting for. The lack of edge blurring in the already existing shaders was the most off putting thing ever. Thank you very, very, very much for this shader!

The following user(s) said Thank You: OtisInf

Please Log in or Create an account to join the conversation.

OtisInf
Topic Author

5 years 8 months ago #32 by OtisInf Replied by OtisInf on topic New shader: cinematic depth of field

Updated the highlighting code with new code which gives much better control over the highlighted areas and is closer to what happens IRL in lenses. See PR: github.com/crosire/reshade-shaders/pull/96

Please Log in or Create an account to join the conversation.

Daodan

5 years 8 months ago - 5 years 8 months ago #33 by Daodan Replied by Daodan on topic New shader: cinematic depth of field

@OtisInf
Just read the comment to the PR and i'm curious about the attached image. Do you use a custom version of ReShade or the official one? It's just that accessing the depth buffer in Remember Me has never worked for me.

Last edit: 5 years 8 months ago by Daodan.

Please Log in or Create an account to join the conversation.

OtisInf
Topic Author

5 years 8 months ago - 5 years 8 months ago #34 by OtisInf Replied by OtisInf on topic New shader: cinematic depth of field

Daodan wrote: @OtisInf
Just read the comment to the PR and i'm curious about the attached image. Do you use a custom version of ReShade or the official one? It's just that accessing the depth buffer in Remember Me has never worked for me.

It's the official one (3.4.0). It's tricky indeed. I got it working when I enabled supersampling in-game. Disabling that and it doesn't work. I haven't tried the depth buffer options now available in reshade btw, with supersampling disabled, so dunno if that can work around that. Did you try supersampling on ? (If you use gedosato to get a high resolution btw it will kill the depth buffer if you downsample through gedosato)

Last edit: 5 years 8 months ago by OtisInf.

The following user(s) said Thank You: Daodan

Please Log in or Create an account to join the conversation.

Daodan

5 years 8 months ago #35 by Daodan Replied by Daodan on topic New shader: cinematic depth of field

OtisInf wrote: It's the official one (3.4.0). It's tricky indeed. I got it working when I enabled supersampling in-game. Disabling that and it doesn't work. I haven't tried the depth buffer options now available in reshade btw, with supersampling disabled, so dunno if that can work around that. Did you try supersampling on ? (If you use gedosato to get a high resolution btw it will kill the depth buffer if you downsample through gedosato)

Thanks alot! It indeed works in 3.4.1 with in-game supersampling enabled. I usually use DSR, so i had supersampling disabled. Because using both of them is quite demanding on the GPU.

Please Log in or Create an account to join the conversation.

Marty McFly

5 years 8 months ago - 5 years 8 months ago #36 by Marty McFly Replied by Marty McFly on topic New shader: cinematic depth of field

Hey would you mind if I "borrow" that physical based focusing code at some point?

Also, since I finally had the opportunity to test the shader thanks to crosire's update, I cannot quite reproduce this:

OtisInf wrote: Performance is on par with qUINT ADOF, often faster (9 passes, 6 rings).

Used quality 6 (6 rings like in your text), picking a scene with about 30% stuff in focus and 70% out of focus, I get 276 fps with no effects whatsoever, 176 fps with qUINT DOF and 50 fps with yours. Using 8 rings, the difference is even stronger, 153 vs 32 fps. With no quality setting I can achieve comparable performance. You are rendering in 50% width 50% height, did you by accident measure performance with my DOF rendered in fullscreen because then the numbers are close (my DOF in fullres, quality 3 for both: my DOF 190ish fps, yours 170).

Last edit: 5 years 8 months ago by Marty McFly.

Please Log in or Create an account to join the conversation.

OtisInf
Topic Author

5 years 8 months ago - 5 years 7 months ago #37 by OtisInf Replied by OtisInf on topic New shader: cinematic depth of field

Marty McFly wrote: Hey would you mind if I "borrow" that physical based focusing code at some point?

If you credit me, sure.

Also, since I finally had the opportunity to test the shader thanks to crosire's update, I cannot quite reproduce this:
OtisInf wrote: Performance is on par with qUINT ADOF, often faster (9 passes, 6 rings).
Used quality 6 (6 rings like in your text), picking a scene with about 30% stuff in focus and 70% out of focus, I get 276 fps with no effects whatsoever, 176 fps with qUINT DOF and 50 fps with yours. Using 8 rings, the difference is even stronger, 153 vs 32 fps. With no quality setting I can achieve comparable performance. You are rendering in 50% width 50% height, did you by accident measure performance with my DOF rendered in fullscreen because then the numbers are close (my DOF in fullres, quality 3 for both: my DOF 190ish fps, yours 170).

The numbers were indeed from a version older than the last one (and I measured in full res for both). Mine gives good results with 4-5 rings, no need to go higher in most cases. On 1920x1200 that runs around 9-10ms. When I measured it it was around 6-7ms but contained some bugs I had to fix later on which caused it to go slower. Yours ran at that time with the same results around 7-8ms sometimes as high as 12ms. Likely me having a value for the bokeh shape to a value higher than needed.

I'm not rendering at 50% width/height though. Only the near plane blurred CoC texture is 50% width/height. All buffers are full res.

texture texCDBuffer1 		{ Width = BUFFER_WIDTH; Height = BUFFER_HEIGHT; Format = RGBA8; };
texture texCDBuffer2 		{ Width = BUFFER_WIDTH; Height = BUFFER_HEIGHT; Format = RGBA8; }; 
texture texCDBuffer3 		{ Width = BUFFER_WIDTH; Height = BUFFER_HEIGHT; Format = RGBA8; };

For the purpose I wrote it, screenshots, the performance is OK for now, but I do realize I'm doing a lot, and all at full res, which might be overkill. E.g. I noticed I likely have too many sample points on the inner rings if the COC is small (so some overlap), which could shave off some performance...

(edit)
Tweaking things a bit, I noticed having a 'continue' is terrible for performance. I expected the compiler to emit fast code with jumps but apparently that's not the case!

So:

if(!someBool)
{
    continue;
}
// code

is much slower than

if(someBool)
{
    // code
}

I have it now hovering around 7.2ms, full res at 1920x1200 with 5 rings and 9.9ms with 6 rings. With max blur settings (300mm and 1.0 aperture) this gives still reasonable results (there's undersampling in highlights, which due to the blur size are massive and the undersampling is easy to spot) and with a post smooth factor of e.g. 0.4 you get perfectly clean bokeh highlights with no undersampling spots.

As I don't want to cut any corners for quality as that's my top priorioty, it's reasonable I think. It's taxing of course, but that's always the case with these kind of effects at full res.

(edit) now around 6.7ms for 5 rings. If I remove the if altogether and do the texture fragment read always, and depending on the boolean expression of the if I removed, multiply the weight with either 0 or 1, it's faster.
github.com/FransBouma/reshade-shaders/bl...CinematicDOF.fx#L437

I knew if statements could slow things down but that they're this inefficient is quite remarkable

Will use it a bit to see if this didn't introduce any more bugs.

Last edit: 5 years 7 months ago by OtisInf.

The following user(s) said Thank You: MaxG3D

Please Log in or Create an account to join the conversation.

Marty McFly

5 years 7 months ago #38 by Marty McFly Replied by Marty McFly on topic New shader: cinematic depth of field

You can tune your post gaussian to calculate the samples on the fly, otherwise you apply a large kernel on 2x2 pixels, that'll further improve performance.

Please Log in or Create an account to join the conversation.

OtisInf
Topic Author

5 years 7 months ago #39 by OtisInf Replied by OtisInf on topic New shader: cinematic depth of field

Marty McFly wrote: You can tune your post gaussian to calculate the samples on the fly, otherwise you apply a large kernel on 2x2 pixels, that'll further improve performance.

Thing is, the gaussian post pass isn't very slow, < 0.5ms at most. So optimizing it further won't help much.

btw:

Marty McFly wrote: Hey would you mind if I "borrow" that physical based focusing code at some point?

To clarify: you may, as it's licensed under the BSD2 license, but you have to obey that license when borrowing that code, s copy the whole license in your shader file as instructed. A simple "some code by Frans Bouma" won't cut it.

Please Log in or Create an account to join the conversation.

crosire

5 years 7 months ago #40 by crosire Replied by crosire on topic New shader: cinematic depth of field

OtisInf wrote: Tweaking things a bit, I noticed having a 'continue' is terrible for performance. I expected the compiler to emit fast code with jumps but apparently that's not the case!

You are writing code for the GPU, branches are the single worst thing you can do (anything that splits the code path, so that's ifs, fors, whiles, ... unless they can be unrolled which the compiler will try to do as best as possible). With the massive parallelism the GPU does multiple threads are always executed in a group (on NVIDIA this is called a warp of 32 threads, on AMD I believe it's called a wavefront of 64 threads). These run instructions in lockstep, meaning they always run the same instruction at the same time. As soon as you branch and one thread jumps to a different target than another in the same group, that thread has to wait for the first thread to finish before it continues, and then the first thread has to wait for that thread to finish going through its instructions until all threads converge to the same location again (after the if/else). If you are very unlucky and a single thread in a warp branches to a different location than all other threads, this effectivly means you force 31 threads to do absolutly nothing. That kills performance. So, it's important to remember that GPUs work very differently from CPUs (which are optimized for very fast branching via a lot of horse power put into branch prediction).

The following user(s) said Thank You: OtisInf

Please Log in or Create an account to join the conversation.