Understanding Ambient Light
Dependent on what other shader you use, the default settings are usually already tweaked decently. For me personally, there is usually only minor things to change.
If the game has not a lot of UI elements I enable AL_Lens.
Depending on the dominant scene colors, I select the AL_Adaptive setting. Usually for dominant cold scenes I set it to warm and for dominant warm scenes to cold (so always the contrary).
After AL I apply a LUT or simple palette that emphasis darker areas and in some cases also slightly reduces the color range (mainly with the palette).
If you are looking for a gritty, more cinematic look, a combination of CA, Advanced_CRT, slight sharpening and film grain can help on top of AL.
| .................................. |
| [GemFX] ................... |
| [SweetFX] ................ |
| [MasterEffect] ......... |
[ .................................. ]
The latest version of MasterEffect is already included in the Framework. As I remember, the latest (stand-alone) DoF shader update was only included in the Framework, since Marty also wanted to steer towards the Framework support.
Though that update added plenty of new options to the DoF, you should still be able to recreate previous results.
@Marty, any other comments on that?
- Posts: 133
Edit: i fixed using framework 1.0 and get all effects but now i cant add mcfly advanced dof : (
i love that buffer possibilities but i dont want to miss Ambient Light, high pass sharpen or clarity : (
- Posts: 209
Actually, I believe F4 uses a linear depthbuffer. The Witcher 3 and AC: Unity are recent open world games that use logarithmic depthbuffers though.
Ganossa wrote: The framework supports logarithmic depthbuffer which wasn't supported in the ME releases. Using the framework, you therefore need to toggle between logarithmic and non logarithmic depth buffer dependent on the game. Newer open world games such as Fallout 4 or GTA V need the logarithmic depth buffer support found in the framework.
SunBroDave wrote: Actually, I believe F4 uses a linear depthbuffer. The Witcher 3 and AC: Unity are recent open world games that use logarithmic depthbuffers though.
not linear, F4 follows conventional D3D zbuffer. other game is probably just using reverse mapped zbuffer, at least I can confirm mad max is.
not sure if there is any commercial game uses logarithmic depth while reverse z can handle the precision pretty well.
GTA V and Witcher 3 use the logarithmic depth buffer for their vast distances.
Using the conventional value distribution in a vast open world game would mean that you loose about 70% (or more) of your precision in the not detailed distance of the world. That would leave you only 30% to cover the precision and detail of objects that are as close as in an fps title while those games have the complete 100% precision range to do that. To keep potential for the detailed part of the view, it clearly makes sense to use logarithmic distribution for your values. Lets say that leaves you with 20% of the values for the distance and 80% precision for the close and detailed view, this ratio very lilely represent the distribution of actual detail (LoD) in an open world with a vast view.
Here an example of the logarithmic depth buffer (in Witcher 3) linarized and displayed in the ReShade Framework:
here is a comparison around near plane.
(zN = 0.002, zF = doesn't matters on large scale (except for outerra's logarithmic depth))
X axis is z-buffer value
Y is restored value
orange: Logarithmic from outerra blog
Red: Logarithmic here
and if check out outerra's research, he's log depth is designed to have constant error on "planet scale" (like google earth or sort) with 24bit z.
This assumption we had is proven correct when applying the linearization function a physicist colleague and I wrote for the assumed logarithmic depth buffer.
depth = (exp (pow (depth, 150 * pow (depth, 55) + 32.75f / pow(depth, 5) - 1850f * (pow ((1 - depth), 2)))) - 1) / (exp (depth) - 1);
We do not know the exact logarithmic function used but the linarization function proves its logarithmic behavior.
Since it seems to be close to the "reversed" function I will eat my hat if thats the quick alternative -_-
Its not a natural reverse function (1/x) by the way, what function did you use, 0.001/x?
reversed-z linearize function is driven from d3d projection matrix with flipped zF zN.
Z = F * N / (F + z * (N - F)); //classic
Z = F * N / (N + z * (F - N)); //reversed
or you can just google d3d depth linearize function driven by others and flip zF zN
actually, I think crosire mentioned it once in the forum.
also the technique itself is not something new and have been discussed / on SIGGRAPH talks / papers for years.
but the game companies probably only change to new resolves when the old one isn't enough.
We went to logarithmic approach right away instead of trying the reverse function here, how would you call such depth buffer then?
Just tested the revers function (and we might have tried that actually in the past cause the result looks familiar).
"Your" Reverse-Z function
The real Reverse function (1/x)
My linearization function
"Your" Reverse-Z function is basically the same as the real reverse function with varying 1/x to ~0/x. The distance it can cover is yet as small as for the conventional depth buffer and therefore wasting its potential (that ~70% I was taking about).
With my linearization function it covers a farther distance, so I guess I will stick to that
you will need to normalize the output to display on screen.
I believe ppl referring it as reversed-z or reversed mapped float point z buffer.
and it is not mine, ppl been doing that for years, and even promoted by Nvidia dev and MJP and other ppl.
also the "reversed" comes from mapping zFar to 0, zNear to 1, not reciprocal.
for proper zF zN, If not doing shader hunt, I don't know exactly how. (by guess?)
for say Mad Max use zN = 0.1, zF = 40000 is legibly from cbuffer by shader dump and math.
others like skyrim /fallout has setting ini fNearDistance. zN = 0.15, zF = 3000
I have no wish to change any of the framework standard, just replying about games using logarithmic depthbuffer. (which normally refers to outerra's work, and games that uses logarithmic depth doesn't need to flip the mapping, the algorithm itself is design to spread the precision on forward mapped/ near = 0 buffer.)
it appears that ReShade values are just (really!) far off from the usual.
//Changed our linearization function accordingly, so thanks for the hint!