TES Skyrim 0.144

[ENBSeries]

Samurai_Smartie
I haven't changed subsurface scattering code at all, it's only separated by object types in two variables, so if you have that bug, compare to previous versions in equal conditions.

Facebook users say in comments that this version have very low fps compared to 0.139, but i absolutely out of ideas, could somebody proove this and find out why? Ssao and reflections code was not changed so much for drop from 40 to 15.
Also i forgot to set higher quality noise function when ssao quality is 2, fixed now but not released, i hardly working on ssao to completely remove noise (or at least as AOType=1 noise for type 0) and keep it precise. Computations with per pixel normals (after 0.119) greatly increasing amount of noise and cut off many denoising techniques, but triangulation artifacts of pre 0.120 are horrible.

jonwd7
Visualizing only few effects will give more pain, because ssao is not applied everywhere, same for reflections or anything else. When seen only one effect it's much more noticable than in game. And the worse side of this information will be paranoid increasing of quality which is not visible in game. Another bad thing is that users may compare effects and start bother me that one previous looks better, but i don't want such reports, in most cases they not have anything closer to my movement closer to valid computations of software renders. Visualizing specular data or transparent objects (no depth draw) is good idea. And yes, separate dll required for performance reasons.
Mixing terrain textures is done by blending 5 diffuse and 5 normal maps together (as i remember), the source data for blending amount is got from vertices (may be not for all shaders, haven't checked all of them). Because amount of compiled terrain shaders is 33 (for nvidia only and which i found, but could be much more), i don't want to edit them all if result will not matter a lot. Guess better to use alpha data from textures (it's specular in normal maps, don't remember what is in diffuse maps) and change shaders to blend by height of pixels (i have screenshots of same code on facebook in some album), this i guess what you want. But the amount of editing scaring me and ATI users will not see these changes probably. I made damn water shaders long time ago, but because game have many of them i don't make them for public yet, the same reason with terrain.

Wolfstryder
Native hardware multisampling is always better than any fake methods, expect "transparent" objects (z test or alpha test actually). But for not thin edges all kind of fxaa/smaa/mlaa etc are fine. Edge aa is same as fxaa, but not applied to entire screen, so almost no false blurring and performance is higher. For edges it looks like 2x-4x multisamples, depending from edge angle.
I decrease multiplier of subsurface scattering, always. As some users reported, vampires are vegetables, so not all types of objects properly separated (i really wish to find myself such wrong separationg to see WHY???).
Version 0.143 was slow with ssao, because i forgot to turn off timing measurements for ssao which makes videocard to wait till drawing done, so 0.144 is faster. Ssao type 1 is a bit faster (almost invisible difference) and much less noisy than type 0, but type 0 is better quality. In new version i'm doing now, combined both types to get better darkening in some areas, this will be type 0, but type 1 will be the same as it's now, low noise and bright (AOIntensity should be increased for it).

[chan]

I compared with 126, and for me the performance is same or better with 144
If I use EnableSupersampling then I see a large frame rate drop. Off=60FPS On=30FPS
1080P
GTX 660 3GB

btw, thank you for the Adaptation switch for old version. CoT was making me insane with the other Adaptation.


jonwd7
In SweetFX, there is a debug for sharpness. Maybe you can use this to assist you with SSAO?
I never thought of it before, but I will try it tomorrow if I am not busy.

[Unreal Warfare]

In regards to performance I haven't had any issues with it. I expect a few hiccups with running an AMD rig but overall it's been pretty good so far even with all the bells and whistles enabled.

[Oyama]

Boris
No issue with performance using 0.144.
On the contrary, better than with previous version.

Also, for information, using Nvidia GTX580 and Windows 7 64bits version, latest 313.96 work PERFECTLY on my side.
Since 306.97, the latest betas are the FIRST drivers that work with no issues. (tested with 0.132 and 0.144).

Have you find your way fixing the noise with SSAO ?
If using high enough scales and filter to 1, I didn't notice any noise on my side.

[ENBSeries]

The last 4 days only working on ssao denoising entire days/nights, experimenting with various noise patterns and sampling types. Problem is with per pixel normals, filter of them decrease quality and details too much (gta4 and deus ex3 mods also), other games with "polygonal" ssao (or 0.119 and older) do not suffer from this problem, curvature of visible geometry is very low, so filtering may have many passes or bigger radius, but with filtering of mine code only loose great details when rendered at 1.0 sizescale. I want to make it fast enough to draw in full resolution with lowest possible filtering range, now this is possible on my videocard only when indirect lighting not enabled (which eat twice more performance). Whatever i do, to get data from space some minimal amount of texture reads per pixel required and even 4 not enough if to use extremely preoptimized input data instead of randomization for textures. Because of per pixel normals can't do optimizations like multiresolution ssao rendering. Well, it's kind of jumping above head, trying to find genius solution and know it's not possible by only modifying existing code.

[Oyama]

Okay, Understood. (really ).
Take your time, seems to be something really hard and needing lots of testing.... different choices I guess, and maybe have an impact on some other effects, don't know.
Good luck for finding this genius solution, no doubt you will

[ENBSeries]

Here are two tests of ssao performance. Part of description is in file, but make sure UseIndirectLighting=true is set and SamplingQuality=0, SizeScale=1.0. Not sure about SourceTexturesScale and SamplingRange, they may affect performance differently for various models of videocards, if it's not a big problem, test twice, one for SourceTexturesScale=1.0 and SamplingRange=1.0, second test both values 0.3. For me "flow" is slower than "noflow", but i 100% sure it was faster earlier when i worked on ssao code, perhaps it's my videocard. And of course optimizations for new videocards and ati/amd are different, so this test may help a lot.
Thanks


EDIT: file deleted

[Oyama]

Got it. On my way for testing.


EDIT : Some really quick testing.
Well, my rig might not be the best for testing since SLI and latest beta drivers. But drivers are stable so far (first that are working on my system since 306.97).
So, with 2x 580GTX 3 GB vRAM ,@1080p. (also tested on LED TV via HDMI, so huge screen size)

Tested in Whiterun exteriors, several characters, night and day, and in Whiterun's interior (Dragonsreach, same, several NPCs and objects on screen).

- Sampling range makes almost no differences, both versions. 0.3 or 0.5 almost the same, and starting loosing FPS only when going full range1.0 (5 to 10 FPS lost)
- "Flow" is running faster for me than " No Flow"
- kept Filter quality to 1 for testing

Flow :
With sampling quality 0, and both scales to 1.0 (sourcetexturescale makes almost no difference, except lowering it gives me stuttering, and having it to 1.0 makes game smoother) : average 30-35 FPS exteriors, and 45 (quick drops) to 60 FPS interiors). Sampling range 0.3 or 0.5, no differences. Sampling range to 1.0, 5 to 10 FPS lost (in exteriors)
The Temp 0 is 0.00 to 0.01 average.

Lowering scales to 0.5 makes winning back 5 FPS only. Lowering to 0.3 gives 2 to 5 FPS more than 0.5.

No Flow :
Same FPS than "flow" in exteriors, maybe 1 or 2 less, but 10 FPS drop in interiors compared to "Flow" (?), hardly go over 50 FPS. The Temp 0 is 0.00-0.02, same as feedback below (forgot to note it before)
Noticed also that IL was really stronger and less tight with "No Flow", and AO was lighter.

In any case, performance hit is really heavy compared to released 0.144. (10 FPS less in exteriors)
Will continue testing for more precise values, just a quick feedback.

[jonwd7]

Boris,

What MixingType were we supposed to be testing? Flow is much faster for me than noflow.

I turned all other options off other than SSAO. I am running 2560x1440, using:

Code: Select all

[SSAO_SSIL]
UseIndirectLighting=true
UseComplexIndirectLighting=false
SamplingQuality=0
SamplingRange=0.3
FadeFogRangeDay=2.0
FadeFogRangeNight=2.0
FadeFogRangeInteriorDay=2.0
FadeFogRangeInteriorNight=2.0
SizeScale=1.0
SourceTexturesScale=1.0
FilterQuality=0
AOAmount=1
AOAmountInterior=1
ILAmount=1
ILAmountInterior=1
AOMixingType=2
AOMixingTypeInterior=2
AOIntensity=1
AOIntensityInterior=1
AOType=0

Flow = 24.3-24.6FPS, Temp 0 = 0.00-0.01 (avg 0.005)

Noflow = 20.3-20.7FPS, Temp 0 = 0.01-0.02 (avg 0.015)

There were some qualitative differences in the AO for me. Here is the AO ONLY contributions:

Flow

Full-Size Link

NoFlow

Full-Size Link

These were with ILAmount set to 0.0 so I could get the AO-only contribution (Still using UseIndirectLighting=true).

I have a full gallery with all the images here, which also includes the AO+IL1.0 contribution. The IL looked very different between the two as well.

I myself don't use MixingType 2 anymore, if you also wanted testing for MixingType 0...



Edit: For comparison, the released 0.144 falls right in the middle of these two tests.

v0.144 = 22.6FPS

Added more images to the gallery.


Edit2: Once while getting v144 images, I noticed my FPS was 27FPS, and not 22.6FPS. This must have been a fluke. It went away. Without any ENB effects except for Edge AA, FPS is about 35FPS at 2560x1440 in that scene.

Not sure why Oyama's performance is so low with Flow and NoFlow. Flow is faster for me than v144, NoFlow is slower than v144.

[ENBSeries]

Oyama
I need only F0 variable value, exactly what is in there, not 0.0-0.02, it's precision is 4 decimal and it's time in seconds. Frame rate absolutely doesn't matter in these tests. SLI/Crossfire must be disabled.

jonwd7
I don't know what you videocard model. Also on screenshot sky and far distance takes huge part of screen, results are not objective. Same as for Oyama, i need only precise F0 variable value, it can't change more than 10% each frame when camera is not moving.
These test are only for performance, how fast work dynamic flow in shader cycle (not compute some data if not really required). Ssao mixing, intensities or anything else do not any effect on performance.