Marty McFly's Advanced Depth of Field (standalone)

Thanks, Eric for the correction!

@Marty: I tested the shader in The Witcher 3. Works with the linearization code from the original reshade.fx in the linearization function. it doesn't work obviously with the default code.

As far as I tested things on OpenGL, it always had the same result as in DirectX. It was just that the old function for log depth inverted it along. But these were just poor experiments as most of the GLSL stuff I did aas on minecraft and there I used the GLSL shaders mod instead of ReShade.

Dumb question perhaps, but is there a reason why you didn't create the DoF as a framework effect, e.g. with a cfg and .h file? E.g. is there a technical one (you need a feature which isn't available as a .h effect, but only as a stand alone shader etc.)? I saw you use a timer, couldn't find info about how that's integrated in reshade (is there any documentation about the HLSL dialect used by reshade?)).

About the timer and similar HLSL extensions, you can get the information in the previous stand alone version of ReShade

www.dropbox.com/sh/jzn2jsb0zt55ci3/AAC83...ublic%20Beta.7z?dl=0

Edit: If you use the Framework, there is a global timer (and other) defined in the ReShade.fx file which can be used in any individual shader.

Super stupid noob questions: How does one go about installing this standalone? Can it be used/incorporated with other shaders? How would one go about doing that?

Plz forgive my ignorance (lack of will to use the forum search function) but the mediator spoiled the fuck out of me



THX! (in advance)

Thanks for the info!

OtisInf

Quentin-Taranrino
Problematic because it does not fit the render chain I set up for the DoF's. Either I migrate all DoF's to this focussing and masking and break all existing configs in the process or I set up a separate chain which is what I wanted to prevent when I unified the DoF shaders in the first place.

Until I make a definite choice, I won't integrate the DoF in the framework.


JohnSlayer1337
Very simple. I am unsure if the mediator renames the ReShade.dll to the correct API (DirectX 9 for example needs d3d9.dll). However, all you need is the ReShade dll and the files of the DoF archive. Drop the ReShade.fx and the ADOF folder into the same folder where ReShade resides in.

Thank you for the Dof , Marty. Much appreciated.

Marty McFly wrote: OtisInf

Quentin-Taranrino
Problematic because it does not fit the render chain I set up for the DoF's. Either I migrate all DoF's to this focussing and masking and break all existing configs in the process or I set up a separate chain which is what I wanted to prevent when I unified the DoF shaders in the first place.

Until I make a definite choice, I won't integrate the DoF in the framework.

Ok, but there's no technical limitation? (as in: you need something that's not doable in the HLSL dialect etc.). I ask this because it looked (but haven't checked at detail level) not totally impossible to convert this into a .h + cfg file. (I'll give it a try over the weekend if I have time)

What render chain problems do you run into exactly? aren't you using your own buffers? Or in other words: all shaders coming after it don't run into problems because some buffer provided by reshade is ruined.

It's all made so vague and cloudy, while it shouldn't. I have no idea why there's not more openness, as the more devs step in and port shaders or make existing shaders better, the better it is for reshade. E.g. why not put the framework shaders on github or bitbucket? Devs can fork it, make changes, send a PR and you or another team member can decide whether they commit the changes or not. Everybody benefits.

McFX has its fixed structure. If it's cloudy, then because it's my own code, nothing related to ReShade itself. DoF render chain I set up works like this:
Focus pass calculates CoC (circle of confusion, basically how much out of focus something is).
Now the actual DoF shaders come. All of them use this CoC texture and the other global variables that apply to all DoF's.
But my own DoF here (actually not the onky DoF of mine, I also wrote Magic DoF from scratch) has a different focussing and masking. Means I either have to use the old McFX masking instead (which I don't want because this one is better). Or I make all DoF's now use this focussing here (breaking all configs for the framework because they depend on the current focussing). Or I implement this DoF here separately. But I implemented this chain to avoid this in the first place.
All of this is shader internal stuff only the developer (in this case me) has to worry about.
I've also set up an AO chain. Purpose of this is that implementing new optioms (both DoF and AO) are now easier because I only have to swap the blur generation pass (or AO accumulate pass).

@Otisinf, it is no problem to add the ADOF shader to McFX suite in the Framework, if this was not clear (or did you want to merge both DoF implementations?). I did a clean port already but it is ultimately up to Marty whether he wants it to be integrated in the release build.
If you want the experience how to do it, you can of course still try to add it yourself.
There is quiet a bit to change (though its simple changes) to create a ADOF.h out of the ReShade.fx and integrate its value defines in the McFX.cfg but that was true for any ported shader
If you have specific questions on how to "translate" certain parts, feel free to ask!
A shader is also currently limited to max 2 tabs in the mediator but this beast of a shader will need 3 tabs to cover all its functionality. As Marty said in his original post, much more control than before.

Lucifer, I will probably make some major changes to DoF in McFX which will also improve performance. Fuck it, then I break all configs, I did that before. And people complained that they couldn't achieve certain looks with the new focussing. They will with this one because it resembles a tuned gp DoF focussing.

From my few tests I see performance and the smooth auto focus as the biggest strength of this new ADOF! Am I right, assuming that ADOF will still be a seperated alternative in McFX to the "traditional" DOF in McFX (which you now plan to improve too) or will you try to combine them again?
By the way, did you get the latest skype discussion, cause we were talking about a release date?

I was't at home all week (will be on friday evening) so I didn't read anything that was written after last sunday, sorry.
I will be going for that option: merging this new DoF with the others and make the others use the same focussing as this one.

Marty McFly wrote: McFX has its fixed structure. If it's cloudy, then because it's my own code, nothing related to ReShade itself. DoF render chain I set up works like this:
Focus pass calculates CoC (circle of confusion, basically how much out of focus something is).
Now the actual DoF shaders come. All of them use this CoC texture and the other global variables that apply to all DoF's.
But my own DoF here (actually not the onky DoF of mine, I also wrote Magic DoF from scratch) has a different focussing and masking. Means I either have to use the old McFX masking instead (which I don't want because this one is better). Or I make all DoF's now use this focussing here (breaking all configs for the framework because they depend on the current focussing). Or I implement this DoF here separately. But I implemented this chain to avoid this in the first place.
All of this is shader internal stuff only the developer (in this case me) has to worry about.
I've also set up an AO chain. Purpose of this is that implementing new optioms (both DoF and AO) are now easier because I only have to swap the blur generation pass (or AO accumulate pass).

Ok, my thought was: this is simply a separate effect, like FXAA is: if you want to have this ADOF, enable it, set its settings, that's it. If you want the behavior of the other DoF, use that, set its settings, the end I understand you might want to create a general setup pass or set of passes and then put after that the particular DoF the user chose, but that can be done in steps: if the ADOF is added as a separate effect, you can after that, if you want, or somebody else, port the different postprocessing in the old DoF over to ADOF. When all are ported, kill off the old DoF. People want to play games and use what works, if a preset they like uses ADOF, they'll use that, otherwise they'll use the old dof. If you keep the setting names the same when porting the old aspects to the new one, configs should be easier to port (copy/paste from one cfg to the other).

If it's a separate .h file and the settings are copied into mcfx.cfg, as a separate effect, it's up to the user to enable one or the other. People messing with the cfg files don't really care I think, whether they have to enable x or y.

LuciferHawk wrote: @Otisinf, it is no problem to add the ADOF shader to McFX suite in the Framework, if this was not clear (or did you want to merge both DoF implementations?). I did a clean port already but it is ultimately up to Marty whether he wants it to be integrated in the release build.
If you want the experience how to do it, you can of course still try to add it yourself.

I was indeed wondering whether it's doable, as the shader pipeline looks familiar to the one in kingeric1992's one for ENB which I like a lot. If I can port marty's, porting that one will not be that hard anymore. Merging everything into one file is IMHO a lot of work for little gain (see above). users don't care in general, they want to play a game and make it look great, preferably by doing as less work as possible (read: download a preset, apply it, game on)

There is quiet a bit to change (though its simple changes) to create a ADOF.h out of the ReShade.fx and integrate its value defines in the McFX.cfg but that was true for any ported shader
If you have specific questions on how to "translate" certain parts, feel free to ask!

Thanks, no questions at the moment.

A shader is also currently limited to max 2 tabs in the mediator but this beast of a shader will need 3 tabs to cover all its functionality. As Marty said in his original post, much more control than before.

You could opt for a bigger dialog default size, it's currently very small, merging tabs into one. If you want me to write an LL(1) cfg file parser which produces an object tree, let me know.(object tree as in: suite with effects, effect with config options). I've done this before (file parsing to object trees) and can re-use an existing lexer+parser for this (the UBB parser in HnD a forum system I wrote). The object tree can have undo/redo built in if you want (no work, outside code doesn't have to do anything ), events exposed so just bind them to controls, undo -> value reset->events raised, UI changes. Redo-> same (based on Algorithmia, a datastructure lib, so no extra work )

I have spent a lot of thinking on my DoF chain and the structure of ME/McFX, things will stay same. For the user, the only noticeable effect will be a fifth DoF to choose from and the focussing values will behave slightly different, that's all. After doing some function plotting I saw that with InfiniteFocus 1.0 values behave almost same, except if objects are close in focus. Generally, with my new focussing, blur behaves much more natural.

Marty McFly wrote: JohnSlayer1337
Very simple. I am unsure if the mediator renames the ReShade.dll to the correct API (DirectX 9 for example needs d3d9.dll). However, all you need is the ReShade dll and the files of the DoF archive. Drop the ReShade.fx and the ADOF folder into the same folder where ReShade resides in.

Thank you for the help, it worked!

And I also have to Thank You for this shader, it works wonderfully!!!

Ported it to reshade framework, was indeed very straight forward. Works great! (and uses the default linearized depth buffer of reshade)

Marty, if you want to, I can include it in my otisFX (with full credit to you) on github. If not, that's fine too, I then keep it separate locally and it won't leave my hdd. With this knowledge it should be easy to port kingeric1992's enb dof too. Will try that later this weekend.

I said already that I will port it to McFX
Oh and nearly all standalone shaders are easy to port, there are no dependancies except linearizing depth.