New DoF with DSLR model [WIP] need help

[Aiyen]

I meant that using a shader where you are going for real world distance units make no sense in the game world since it use some arbitrary scale depending on what you are trying to get a shot of.

The scale of the landscape compared to the scale of the objects in the landscape does not make much sense.. and the depth is based on the scale of the landscape, not the scale of the models.

Hence you can make a shader that works nice for models.. or one that works nice for landscapes.. but not both at the same time with the same math, since they scale differently.

This is what I struggled quite a bit with, since I could do the math you would use in photography in the real world.. but when I applied that in game then it would never behave as expected because of this.

In the end I just changed my way of thinking to something that had nothing to do with photography. But my end point goal was also a DoF you could play the game with not one for fancy screenshots... And most photography models kinda assume that you are standing still taking a picture.. while I more wanted something that was more over in how the eye behaves.. with a few artistic liberties ofc. Since the pure "how the eye works" models again fail for the above reasons when you put those in.

Hope that made more sense.

[kingeric1992]

From what I learned(google), coord in the screen space are calculated by using perspective matrix on world space coord and camera angles, z component in screen space is compressed by zNear and zFar which define viewing frustum along with FOVx FOVy.

With inverse function, actual depth can be obtained from z-buffer. So, setting the correct zNear and zFar for decompression is crucial, they must be identical to the one used in z compression in order to restore the original value( there is still precision lost with the process).

What you've experience about different scale with objects at different depth is because incorrect zNear zFar.
In GP's dof, zNear = 0.0509804; zFar = 3098.0392, depth value is biased like crazy within 10 meters.
but with zNear = 0.15; zFar = 3000, it seems to work, at least I can focus by setting focusing depth(in meter) to the depth of a object. (I've only tested 1~100m though)

Eye also applied to the same math, just set parameters according to retina(as film size), eyeball(focal length), and pupil(as aperture).

ref: http://msdn.microsoft.com/en-us/library ... s.85).aspx
http://msdn.microsoft.com/en-us/library ... s.85).aspx

[Aiyen]

Yes that is ofc. correct... But that was not my point.

The point was that the scale between models and the gameworld is rather weird.

For example the distance between two mountains in the game is no where near what it would be in real life. While the height of a character is somewhat close to what it would be.

When you use those super proper values for the linearization and get the ability to use proper metrics in your inputs then you run into the issue of... 100m being REALLY far in the game.. while in real life it would be next to nothing.

Hence those values while being right if you want to use proper metrics... are perhaps not the best to use in game.

I just use the following

Code: Select all

float linearize(float nonLinDepth)
{ 
float Z_near = 1.0;
float Z_far = 100.0; 
return -Z_far * Z_near / (nonLinDepth * (Z_far - Z_near) - Z_far);
}

Using this I am able to control the focal distance in a 0-100 range with a second variable to really REALLY finetune it for those situations that require it.

However they will not relate to any metric at all ofc. But again because of the above mentioned example I just decided to ditch the proper metric variables and simply just use what allowed smooth control in game.

I am sure prod80 can go all nuts and rage and rant about the precision of the depth conversion... and I am inclined to agree with him.. it is just silly that only about 1% of the entire 0-1 range is actually used (Here used means what you actually render in a ugrids = 5 range) causing all sorts of rounding errors to affect the computations since they are so touchy.

Anyways.. the whole point of all this was just that I found it curious that you went ahead and used things that have proper metrics.. since it just behaves so weirdly when the relative scale of the gameworld is as it is.

[number6]

Are the znear and zfar values that you and GP are using just empirical guesses as to what the game is set to or are they taken from somwhere?

[Aiyen]

They should be locked to the values mentioned (zNear = 0.0509804; zFar = 3098.0392) to convert 100% properly... assuming that the projection matrix is made that way... but it is in most applications.

However when you do that and have your 0-1 range then you only really use from about 0.99999 to 0.98 or something similar (I forgot the exact specifics sorry). Once you get to a value less then this you are effectively at the game world edge in distance... which is kinda silly and not practical when making a shader. The reason is that even small rounding errors will influence the distance rather largely. Hence when you focus on something then it will not always be entirely in focus even though it should... depending on the distance from the camera.

Anyways regardless of this then it does not really matter what you have the values at since they just function like an offset... you can use any offset you want, the only thing they determine is how your other scales react.
Ofc. if you want them to react to proper real world metrics then you need as perfect to linear conversion as possible since in the real world the distances are linear for all intents and purposes.

At least that is the way I understand it so far! I am sure someone else will poke in and say how I am wrong on some level!

[kingeric1992]

Hay, just found out zNear is defined in skyrimperfs.ini
fNearDistance=

zFar is probably this
fBlockMaximumDistance=

not sure about zFar, but STEP stated that these values affect z-fighting which is related to lack of precision because that zN is too small.

Edit: default fNearDistance = 15, so according to this page, 5% error should happen around 52500 (PS. if 16bit zbuffer). and since game unit is in cm, error should be 26m at 525m. ( 11cm if 24bit zbuffer).

[prod80]

Ask Boris to port matrices to fx file? Then you can do good linear conversion without a huge loss in precision. In any case the texDepth must also be best-effort-guesswork from Boris, so I don't know if all this logic makes sense in well, a logical way.

[ENBSeries]

Near and far clip planes are the same in skyrim and far differ only in interiors, but also the same for all of them. No reasons to bother, matrices just make a lot of issues, somebody will make changes to 3d space and users will bother me why this is buggy with my own effects. All calculations non 2d are on my side for your own good.

[kingeric1992]

Prod80

Check this out, optical vignette. Just a proof of concept, haven't relate the deform strength with DSLR model yet.

TESV.exe_DX9_20140911_174942 by kingeric1992311, on Flickr

sadly, it will downscale the sample. but again, blur probably doesn't need full res.

[prod80]

Nice
Would be nice to have RTR "fantasy"-ish bokeh effects because I completely dislike the "bokeh" textures used for the majority of lens dirt textures. Just haven't got time to put into it myself, pretty damn stuffed with work right now (currently on airport traveling between clients, etc). Curious to see where this will go