TES Skyrim 0.266

[prod80]

Thanks Boris

I make bloom to LDR, that's why saturate(). I don't like bloom output in HDR (personal preference). The default setup of file as it is uses Sigma value of 6, which is equal to a blur of 35 pixel wide (both horizontal and vertical) in fullscreen, or when computed on 512 texture when screen is 1920x1080 it is 9 pixel wide blur. In my setup I use Sigma of 24 which is a lot wider; 149 pixel wide blur, which on 512 texture is 40 pixel wide blur. I am aware that computing against depth cause some aliasing... the mix I use using;

bloom += lerp( srcbloom * Sigma.x, bloom1, smoothstep( d-d1, d, d1 ));
bloom += lerp( srcbloom * Sigma.x, bloom2, smoothstep( d-d2, d, d2 ));

Makes this a bit less of an issue because it mixes smoothly when depth between 2 objects is not too large. In some cases there may be some aliasing but it is manageable.

Partially possible to implement bicubic filtering in postpass shader for low resolution textures, huge quality boost, but still with artifacts noticable when rotating camera on small bright objects, so bigger blurring range must be used anyway.

Interesting. Similar bicubic as done in Prepass?

I'll do some testing.

PS.

for(int i = 1; i < LOOPCOUNT && SigmaSum < Q; ++i)

This works correctly. Some reference material where it comes from:
http://http.developer.nvidia.com/GPUGem ... _ch40.html

SigmaSum basically contains the completeness of Gaussian curve... if SigmaSum=1.0 then there's no further weight left to compute. The weights themselves are computed using Sigma.xyz. Q is quality factor because Gaussian has a lot of values with very low value which cannot be seen in game anyway. So by setting Q to something like 0.9 one would compute the Gaussian curve until it reaches a total weight of 0.9 and then exit the loop. It has almost no visual difference but is much cheaper.

Sigma=24 needs a total of 139 loops to become complete but already reaches 90% of the bell curve after 39 loops. The last 10% is very heavy and you cant see difference as it's too minimal. So I just build that quality factor in to exit loop and not doing very heavy computation for nothing.

[ENBSeries]

prod80
I don't get it. How amount of pixels for blur are related to screen resolution if it's done with fixed sizes? I'm talking about bloomtexture1/2 shaders, not prepass.

[prod80]

They are not related. Its just me and my stupid stuff.
I relate them to screen resolution when texture upscaled to fullscreen to get correct output. What I mean is if I do 9 pixel wide blur on 512px texture I know when upscaled to fullscreen this will look like 35 pixel wide. You can ignore that logic.

[prod80]

Tested some more to rule out a few things

1-Not related to depth
2-Bicubic filtering in postpass didn't help other than that I get smooth horizontal lines now
3-Increasing blur to insane high or very low values doesn't help
4-Running blur over different math using a normal kernel doesn't help

Only thing that appears to work is manually setting pixel size to 1/512 ignoring TempParameters.z, but this gives wrong output and costs performance. Especially Tex4 becomes very bad and can't be used (lots of shimmering).

Having lot of trouble to find exactly which pass it happens, and why it happens. It is like the offset suddenly skips a pixel.

It also only happens in Vertical pass, not horizontal, annoying the crap out of me too.

Can it be that due to lowered resolution doing the below causes a precision problem and me doing horizontal and vertical blurring separated makes this visible?

Code: Select all

float2 pixelsize = TempParameters.z;
pixelsize.y *= ScreenSize.z;

Im pretty much out of idea's

I doubt there is little chance to add bloom quality back in? :S God I hate directx by now.

Rant over :\

[Jafin16]

Just as a note, I haven't noticed any difference in bloom. Could be that my eyes aren't well trained enough, but if it takes trained eyes to notice it I wonder on the practicality or necessity of adding further development. I don't mean to put a damper on the discussion of bloom, but I just wanted the throw in my opinion as a modest tweaker and user, not a coder.

Regarding the ctdtest, sorry I didn't get back to you earlier, I haven't had any time for Skyrim in the last day or two, but I haven't noticed any change whatsoever between the ctdtest and current 0.266 regarding performance, stability or anything else. At first I thought I noticed a little more stutter but after further testing I realized it was due to decreasing the overclock on my VRAM (my power supply is starting to get unstable so I'm limping it along until I can get a new one).

[prod80]

Stupid mounts of bilinear filtering solved it, but not pretty solution

[HizFather]

Ok im kinda scared guys, I don't know what happened but this update literally double my fps, from 45 to 90 and i have everything maxed with like 500 mods, does this sound normal; im thinking its too good to be true. I enabled fix lag and zprepass or whatever it was called. I've only tested for like 10 min but this just seems crazy, also i had terrain parallax disabled so im thinking thats what was killing my fps, any thoughts?

Parallaxed terrain can't harm your performance at that point. I mean dividing your FPS by 2.
Same goes for what you're describing, such a FPS boost is pretty crazy... What are your specs plz ?...

Boris
off-topic

Sorry if that has already been answered, but would it be possible to have two sets of settings for Reflections, Amount and Power, Interior and Exterior ?....

GTX 980, i7 2600k @ 4.5, 16 gb ram, 1080p. I still dont understand why I gained such an immense performance boost.

[prod80]

probably something not working as intended or you had a setting enabled previously which you disabled now like WaitBusyRenderer in enblocal.ini, or FPSLimiter ...

[kchati]

EnableZPrepass cause the game random freeze in my system。
FixLag parameter Locked my FPS in 30

I use ForceBorderlessFullscreen mode

[ENBSeries]

prod80
I've replaced your internal cycles code with standart accumulative bloom with variable for scaling and that showed the issues. Anyway, you can't do anything with depth inside blurring passes, this always produce aliasing. Writing blurred depth to alpha channel partially fix the issue at performance cost, but don't think it's what you tried to achieve (i don't know what is that anyway). One more thing, gaussian blur without proper modification can't fix the issue with aliasing at any blurring ranges. Lower render target size with bigger source texture for aliasing-free must read all texels covered by pixel at same weight. For example, if render target is 32*32 and source is 128*128, 16 pixels must be blurred at factor 1 or which is the biggest for your gaussian code, all other near by with fading. Not same weight equal to misses of sampling thin objects. Btw, don't forget that uv offset is applied in vertex shader and TempParameters.xy is already halfed.

HizFather
Answered.

kchati
Wrong skyrimprefs.ini.