TES Skyrim 0.139

[spyridon]

spyridon
I wasn't referring to you specifically as I'm not even familiar with your problem. But while on the subject, does the issue persist with stock ENB files?

And please all, stay on the subject and forget the stupid who called who first, it's not going to do any good.

In response to staying on subject, no problem, I just don't like false accusations since I didn't throw any insults .

Now back on to the issue, it doesn't seem to happen with the stock files, at least not that I noticed (I didn't spend as much time testing those). But it's happening in nearly every preset I have (and I have quite a few downloaded). It also sort of fades in and out of it at times. So I get the feeling it's related to some effect, but haven't been able to pinpoint exactly what since it's inconsistent, aside from it affecting daytime much more often than night (although a couple times has hit me at night too).

I also have a feeling it may be a driver issue and attempted to try various versions to see if any would help, but this is a new PC that was built just under 2 weeks ago, and I don't have older driver versions to test with anymore. But I do know that I had issues with before on this PC with ENBseries version 119, did NOT have problems on version 12x and 13x prior to this, but the new version is having problems again. Now this current issue seems to be affecting all driver versions I have available. But again, I don't have all the drivers available to test anymore.

On the driver topic, many games that came out over the holidays require newer driver versions to function, so I constantly have to switch versions just to play Skyrim (currently I need newer ones for Planetside 2 to function at all, HotS has performance problems without them, and TSW has DX11 features that don't work without them). Since these driver versions are out of beta now and older are not supported, I really hope the workaround Boris discussed will finally happen, since it seems to be needed more than ever, or else noone with NVidia cards is going to be able to use enbseries soon. Which according to steam hardware statistics (which all Skyrim players are on), is more than 52% of players.

[mindflux]

spyridon
No worries, I never hold grudges against anyone and I hope no one else does either. The matter of fact is that most old presets will need some kind of adaptation to make them work nicely with the newest ENB binaries. As far I know the issues are mostly plaguing presets derived from a specific old preset with a substantial amount of custom code not made by Boris, so to me it does look like some of this custom code might not be compatible with either the new drivers or ENB versions. Also the fact that there are almost always no issues with the stock files suggests this. I hope all this will also help understand Boris' stance on the issue.

But back on your specific problem, does the issue look like adaptation? Just a brightness shift, or color shift as well? Name a couple of presets that you've tried that have this problem, I'll check them out and try to reproduce the issue with the latest Nvidia drivers.

[Dinkledorf]

I not sure what the issue here is but from my testing, the transition from night to day has changed and is directly affected by the Horizon color, as a result a weather change in the game can cause a significant change in the display as values settle somewhere between night and day. I suggest keeping the GUI up with the Statistics selected so you can visually see what ENB is seeing and how it is reacting to the weather. Perhaps you will find a correlation this way. If your enbeffect.tx file is performing a number of lerp's based on ENightDayFactor its a sure bet, especially if you are using CoT (or something like it).

[chan]

I not sure what the issue here is but from my testing, the transition from night to day has changed and is directly affected by the Horizon color, as a result a weather change in the game can cause a significant change in the display as values settle somewhere between night and day. I suggest keeping the GUI up with the Statistics selected so you can visually see what ENB is seeing and how it is reacting to the weather. Perhaps you will find a correlation this way. If your enbeffect.tx file is performing a number of lerp's based on ENightDayFactor its a sure bet, especially if you are using CoT (or something like it).

Agreed. I force clear weather a 1200, and again at 0000, and make adjustments.
With CoT, many weather styles will use night parameters.
I don't understand what lerp's are, this coding is new to me.
I have day/night/interior separation in my enbeffect.fx file, but have not tested any interior (probably broken code now with new binary).

[spyridon]

spyridon
No worries, I never hold grudges against anyone and I hope no one else does either. The matter of fact is that most old presets will need some kind of adaptation to make them work nicely with the newest ENB binaries. As far I know the issues are mostly plaguing presets derived from a specific old preset with a substantial amount of custom code not made by Boris, so to me it does look like some of this custom code might not be compatible with either the new drivers or ENB versions. Also the fact that there are almost always no issues with the stock files suggests this. I hope all this will also help understand Boris' stance on the issue.

But back on your specific problem, does the issue look like adaptation? Just a brightness shift, or color shift as well? Name a couple of presets that you've tried that have this problem, I'll check them out and try to reproduce the issue with the latest Nvidia drivers.

I currently have version 119 setup (Project ENB is the only config I seem to not be having problems with ATM) and am leaving soon so I'll need to do the testing a bit later, but I'll share some things I've noticed so far.

I think the problem is a combination of both the drivers and ENB versions. 119 has been fairly problematic with me, but the reason I'm using it atm is because when it has problems they are more obvious. For example, 119 has a "darkening" issue sometimes, and I know when it's happening because if I take a screenshot it "snaps out of it". Same as if I try to record a fraps video - whenever it's recording it's normal, but as soon as recording stops its dark again. So for 119 I know it was a driver related issue with dx rendering not applying properly. This is very similar to the old issue discussed in the Kali ENB thread. Another point for the 119 driver issue is that it did not happen at night, so it was something related to daytime rendering.

With the 2xx and earlier 3xx versions, I wasn't having these issues. But now with 139, there is a new darkening issue, at first glance it seems familiar, but it's different this time. Taking the screenshots does NOT fix the issue. Also it's not an "immediate flash" as happens with the old driver issues. This is a more gradual blend. Somewhat akin to the darkness adjustment when looking up, but a little bit quicker, and much more inconsistent. But in common with the 119 issue, it's only happening in daytime.

So it seems to be similar in some ways, but a new issue in some ways as well. That's why I get the impression that it is somewhat driver related, but also somewhat related to new code in 139 that seems to have reverted part of the 119 issues.

As for presets, I can't name every single one as I deleted a number of them that were made for earlier enbseries versions since those versions are now not available anymore, but two specific ones I remember are superb and the wilds, as well as I had the problems Phinix was having with his (but it sounds he found the solution to his issue).

If you are able to reproduce the current issue and you would like to see the 119 driver issue that I was talking about for a comparison, that issue was very apparent with 119 and True Vision.

I will do some more testing later when I get home and set 139 back up.

[mindflux]

Thanks for the detailed info. For once, I wish had even one of these bugs on my system to help pinpoint the cause.

By your description it sounds like the latest issues with 0.139 could be somehow tied to the new day-night detector and adaptation. I will do some testing later when I have time, but just in case I can't reproduce the issue, you can help yourself by doing some testing: first, open enbeffect.fx and comment out the line that says #define APPLYGAMECOLORCORRECTION by inserting // in front. Then, scroll down or use search to find two lines of code that read:

Code: Select all

	float toobright = max(0,tex2D(_s2, _v0).xyz - 0.4); // 0.5
	color.xyz *= 1-(1 * toobright); // 1.3

Comment them out as well, go back to the game, hit backspace and test. Don't care about the image going awry, that's to be expected, just check whether you can still reproduce the bug. If you still can, go to the beginning of enbeffect.fx and comment out every single line starting with #define, except #define POSTPROCESS 5. Do it one at a time, checking every time whether the bug persists. Good luck.

[chidosity]

Guys, I'm really stuck.

I've been fairly comfortable working with enb, but the one area I've never been comfortable with, and had to rely on the work of others, is with adaptation and day/night detection. Now Boris has gone and made changes to the one area I just can't seem to wrap my head around. It appears that it comes easy to some of you, so I'd like to ask for some help, as I can't seem to find any documentation/tutorials that have helped me work with these settings successfully.

If I understand correctly, I don't need to "reinvent the wheel", and redo a config from scratch as long as I'm not using an fx file adjusted by HD6, but only adjust the day/night and adaptation.

[NIGHTDAY]
DetectorDefaultDay=false
DetectorLevelDay=1
DetectorLevelNight=1
DetectorLevelCurve=1

[ADAPTATION]
ForceMinMaxValues=false
AdaptationSensitivity=1
AdaptationTime=1
AdaptationMin=1
AdaptationMax=100.0

Would someone be willing to take a few moments to explain how these sections of the ini operate? As in, best practices for making changes, and how to go about them? Could you also perhaps explain if the changes Boris has made require any adjustments to the fx files?

I know this is pushing things, but I just can't seem to "get" what is going on in here since the changes from 138 forward.

EDIT: User Dinkledorf gave me a very good answer to this, below:

Hey there, I can give you a hand with NightDay but not Adaptation as I don't use it. Also I do not believe that standard Adaptation is actually in use by HD6 enbeffect as he employs his own method and disables the standard ENB implementation.

NightDay settings are as follows:

First thing to understand is that there is no concept of time in ENB as it relates to time of day. It determines Day and Night very differently.

ENB uses the added RGB (Red, Green, Blue) values of the scene Horizon color to derive a value between 0 and 1. This value and the settings of DetectorLevelDay and DetectorLevelNight is how ENB determines whether it is Night, Day or something in between. Not to get too technical or too remedial (depending on your knowledge) but each pixel on the screen is made up of three parts Red, Green and Blue values each of which can have a value somewhere between 0 and 255. The higher the number the brighter the color. When all three color values are 255 the pixel is pure white and when they are all 0 it is pure black. If the Red portion is 255 and Green and Blue are 0, the pixel is as pure bright Red as it can get.

What ENB does is look at the average color value of the Horizon (in the sky) and samples the RGB value of it. ENB then adds these three values together (R + G + B) and divides that number by the maximum possible brightness (3 x 255, pure white) which yields a value between 0 and 1.

Now DetectorLevelDay and Night are represented not as decimal numbers but are subsequently treated that way by ENB. So you will be setting a number between 0 and 100 for each (not between 0 and 1). Each value then determines at which point you want ENB to consider Night and Day.

Typical values are:
DetectorLevelDay = 65 (at this point, mine is at 45)
DetectorLevelNight = 35 (at this point, mine is at 20)

This says that when the Horizon brightness is 65% or above of the maximum possible brightness, it is Day and conversely when the brightness is at or below 35% of maximum, it is night. Anything in between 35% and 65% will cause ENB to mix Day and Night values based on the DetectorLevelCurve value.

Its hard to explain curve, it determines how the transition (values between Day and Night) are handled. A good place to start is to set Curve at 1 and narrow in your Day and Night settings and then experiment with Curve. You will find that lowering the number will start to favour the Day value (your screen will become brighter) and upping the number will favour Night (make it darker).

DetectorDefaultDay - leave this at "false" as "true" enables an old method that has not been in use for ages. Not sure why Boris keeps it around.

If you understand the above (feel free to ask for additional explanation if necessary), you will notice that ENB is heavily influenced by weather since color of the Horizon is weather controlled. This will cause you grief and how much will depend on whether or not you are using Weather mods. Vanilla weather is not too bad and reasonably consistent but it may still end up skewing your screen towards night in stormy day weather if the values for Horizon dip too low. It ends up being a compromise and search for the optimal value.

From my testing, Vanilla weather works pretty good with the defaults of 65 for day and 35 for night. You may get better results by lowering Night to 25 or even 20. The ENB GUI now provides a realtime display of this in the Statistics section. It provides two values:

ENightDayFactor input - this tells you what brightness ENB has detected in the horizon as a value between 0 and 1
ENightDayFactor output - this is also a value between 0 and 1 but is the value ENB has determined based on your settings and feeds that back into enbeffect.fx code. Think of it as % of full day so when the value is 0 it is night and 1 it is day.

As to whether or not you need to modify enbeffect, I suspect not but is hard to say without looking at the code myself. Enbeffect receives the resulting ENightDayFactor (output) value which can then be used to mix night/day values in enbeffect accurately. It is highly likely that this code does not need to change, focus on enbseries.ini.

[BTJ]

Thanks for the detailed info. For once, I wish had even one of these bugs on my system to help pinpoint the cause.

By your description it sounds like the latest issues with 0.139 could be somehow tied to the new day-night detector and adaptation. I will do some testing later when I have time, but just in case I can't reproduce the issue, you can help yourself by doing some testing: first, open enbeffect.fx and comment out the line that says #define APPLYGAMECOLORCORRECTION by inserting // in front. Then, scroll down or use search to find two lines of code that read:

Code: Select all

	float toobright = max(0,tex2D(_s2, _v0).xyz - 0.4); // 0.5
	color.xyz *= 1-(1 * toobright); // 1.3

Comment them out as well, go back to the game, hit backspace and test. Don't care about the image going awry, that's to be expected, just check whether you can still reproduce the bug. If you still can, go to the beginning of enbeffect.fx and comment out every single line starting with #define, except #define POSTPROCESS 5. Do it one at a time, checking every time whether the bug persists. Good luck.

mindflux,

thank you for looking into this. Indeed the flickering disappears when removing this line as posted by sniplol:

r1.xyz = lerp( min( 0.28, r1.xyz ), 0.5, hnd ); // Ligthen if dark, but do not darken if too light, we do this elsewhere for extreme bright situations

As I am not a programmer, could you please explain what this line does? I removed it and did not observe a difference at first, but now I am not so sure anymore.

[mindflux]

Yes, I suspected the culprit is one of those lines. Good to hear you got it sorted out.

Well I'm not a programmer either, but that line I can decipher, it's supposed to be a sort of primitive adaptation that sets the minimum screen brightness at 0.5 during daytime and 0.28 at night-time (min function selects the lesser of x and y, and if I remember right r1.xyz is game color before bloom, tint, cinematics, etc.). To be honest it's a bit of hack, so I wouldn't worry too much about removing it, if you need adaptation use the proper one implemented by Boris.

[BTJ]

Yes, I suspected the culprit is one of those lines. Good to hear you got it sorted out.

Well I'm not a programmer either, but that line I can decipher, it's supposed to be a sort of primitive adaptation that sets the minimum screen brightness at 0.5 during daytime and 0.28 at night-time (min function selects the lesser of x and y, and if I remember right r1.xyz is game color before bloom, tint, cinematics, etc.). To be honest it's a bit of hack, so I wouldn't worry too much about removing it, if you need adaptation use the proper one implemented by Boris.

Thank you mindflux!

Okay, so I keep it removed for the time being. I thought its removal might be responsible for the strange effect I am observing: when I change from ego perspective to over the shoulder look while having the candlelight hovering above me, the lighting of the whole scene changes. In dark rooms, suddnely everything becomes brighter and illuminated and looks quite correct. When I go back to ego, everything becomes darker again, a bit too dark IMHO. Could this be a problem of the config I am using?