TES Skyrim 0.254

[Aiyen]

jonwd7:

Guess there are a few things I want to touch on in relation to your mother of all posts.

The _sk and _s map is more or less only used for body models and a few other actor models. Every other single model only have specular info contained in the normal maps alpha channel. So I would not say it is used for MANY objects overall in the game. (Actually I find it more surprising that they are there at all considering how little use have been made of them)
Overall I see where you are going with the issues, but just out of curiosity then what happens if you simply disable SSS ?

The few remodels I have done which use softlighting have worked like a charm, even one with rim lighting worked just nice. I have not made one that had to make use of both at the same time yet though.. so cant speak for that.


Finally to your skylighting issues... I believe I mentioned this to you earlier.. or perhaps it was someone else with the same kinda issues... have you tried to use an enbeffect.fx file with filmic tonemapping instead? It will allow you that extra pixel brightness fine control you just cant get using only the .ini tweaks.
Guess I will throw in my general ENB mantra... If you got good tonemapping it is easy to tweak... if you got bad tonemapping then you can get issues no amount of tweaking enbseries.ini will fix!
At least I would have to really go out of my way with wonky settings to be able to produce what you got on those screenshots. And even if I did I would only have to adjust.... two settings in my files to correct it again.

Also mountains do not cast shadows.. since they are an LOD object which cannot get the cast shadow shader on them... as I recall.

[jonwd7]

Finally to your skylighting issues... I believe I mentioned this to you earlier.. or perhaps it was someone else with the same kinda issues... have you tried to use an enbeffect.fx file with filmic tonemapping instead? It will allow you that extra pixel brightness fine control you just cant get using only the .ini tweaks.
Guess I will throw in my general ENB mantra... If you got good tonemapping it is easy to tweak... if you got bad tonemapping then you can get issues no amount of tweaking enbseries.ini will fix!

Tonemapping has absolutely nothing to do with the issue.

At least I would have to really go out of my way with wonky settings to be able to produce what you got on those screenshots. And even if I did I would only have to adjust.... two settings in my files to correct it again.

Those settings aren't "wonky". That is the standard appearance. Normal ambient values, no painstakingly edited weathers, no extremely high IBL values. That is what you get if you just switch Skylighting to on, with the vanilla weathers and the default INI. However, the screenshots were 6 months old, and as you may have been able to tell from my videos, after painstakingly editing all weather with extremely bright directional ambient, only then could I get somewhat acceptable results.

The point was that we could have further control over skylit shadows with some curves/multipliers.

Also mountains do not cast shadows.. since they are an LOD object which cannot get the cast shadow shader on them... as I recall.

Don't know why you think that.** The reason Ivarstead is pitch black in those old album images is because the entire town is shadowed by the mountain. What is extremely unnatural is that there are also shadows within shadows. Which you can also witness in the videos. This is because skylighting is still computed via the sun position, yet apparently does not take into account cloud shadows. So in that video, there is a group of trees which have pitch black skylighting, even though there is technically no light able to cast it (there are zero shadows). I also had fairly high AmbientMinLevel values, but cloud shadows + skylighting = pitch black. Another reason for curves/multipliers.

**: This is with bDrawLandShadows=1 in Skyrim prefs, which Boris actually says should be turned on for skylighting, and ShadowCastersFix=true.

[Jafin16]

jonwd7
So, this is all really interesting, but I've got a couple things to say... No one else seems to be reporting the same behavior you are, so I'd be curious if you just don't have some wonky settings. I know I don't have these problems. Secondly, the old SSS method is still available - use the object category instead of the SSS category. It's inferior, but should use _sk maps if I remember correctly. And finally, Boris said at the moment that all he can think about is clouds. He has 2 possible fixes for skylighting that he just hasn't implemented (and called himself a lazy ass) and has no interest in working on SSS. If there's one thing I think any of us have learned, especially who's gotten into conflict enought, is that trying to "make" Boris do something is futile. Your ideas and concerns have been expressed, Boris has replied, Aiyen tried to offer assistance and you push more. Seriously, just stop.

[jonwd7]

No one else seems to be reporting the same behavior you are

Clean INIs. No weather mods. bDrawLandShadows=1, ShadowCastersFix=true. Turn on skylighting. Go to Ivarstead and wait for the evening. I already explained this was the baseline behavior, and something worth looking into improving. But clearly a few IBL/ambient curves/multipliers for only skylighting and changing directional ambient from within ENB is not something you would want. I think maybe you are just too busy being defensive to take the time to admit it.

(Note: I'm also not reiterating this again because I'm "pushing" but because I'm pointing out how your response is a little bit ridiculous considering I took the time to write up some extremely well thought out and coherent suggestions, which, Boris said he saved and might look into. That was good enough for me.)

Seriously, just stop.

Luckily I don't need your permission to respond to someone. Should I just ignore Aiyen? I was defending my points, and some of his/her points were incorrect.

Frankly, I think my understanding of the issues (both technical, and due to time spent on them) is a little beyond yours and your input has absolutely no place, so I'll also ask you to stop. (Joking of course, I don't care what you do.) Your unwarranted dismissal of my points is offensive (mostly how inanely you try to rebut them) and you are just coming across as a lap dog, as if I'm somehow harming Boris.

I guess you probably deserve an apology from me. Jafin16 I'm sorry I took the time to try to improve ENB with my input. I'll be sure to ask you for permission in the future.

[Aiyen]

jonwd7:

My post was not intended to conflict with your points, since I sort of know of the issue you are having.. I am able to reproduce it myself, but also able to fix it rather easily. Also I found the SSS ones quite interesting.

I guess I can be a bit more indepth.

The default files, with default settings will be able to produce what you see... these settings are just meant to be a very very basic set of settings to start from that does not cause the entire screen to be entirely white or black they can however be a bit ... wonky as you clearly show. The reason I asked was because if you have not edited anything in enbeffect.fx or tried anything in relation to that then I would suggest that you try that instead.

Tonemapping would have everything to do with what you show.. if you had a tonemapping curve that would transform the darker pixels into a bit brighter ones then you would not have to go to extreme .ini settings to get brightness back up.
If you had some form of adaptation that actually worked then it would automatically adjust the pixel brightness when you look in that area... all of which require something in enbeffect.fx to be setup properly and not just use the standard default values for everything.

In general then the values in enbeffect.fx should be the very first you try to adjust when you have issues like this and then only use the .ini tweaks as fine tuning on top of that.

Also if you use a palette texture then you can adjust using that.. since if you are using a greyscale version of that then it is effectively the same as doing a specific form of tonemapping anyways. Adjusting that to a different one will also be able to help if you want to go that route.

In short again... I am not saying that you do not have a point in what you are saying... I am just offering suggestions on what you can do to get around it using the tools already available to you.


As for the mountain thing. If you notice during dawn and dusk then sun scattering and sunglare will sometime be visible even though the sun is behind a mountain. In ivarstad then because the village is so close to the mountain, the cells up the slope are actually loaded which means all objects are loaded in full detail and hence have all the right shader flags enabled to properly obscure the sun. As opposed to just being LOD objects which do not have the ability to have these flags enabled. At least that is how I understood the issue the last time it was brought up.

[Jafin16]

jonwd7
Maybe I'm at fault here and I don't want this to turn into some sort of flame war. I've seen way too much internet drama in the last couple of months and it puts me on the defensive (most I was not directly involved in). I can also think of at least 2 occasions, I can vaguely remember a possible third, where you got into a massive, pages long argument with Boris. One had something to do with decals/meshes and another had to do with SKSE 1.7 alpha. Boris stated his stance on the issues you brought up, Aiyen responded to give you some help, you got defensive, like you always do, and pushed again stating the problems. I was trying to avert a pages long flame war by simply stating this. I hope this was not in vain.

Aiyen has given you very good points. You said this is baseline behavior. If you're using the default files then, as I mentioned, you have wonky settings. Those are not configured to look good and work correctly out of the box. Those are just the tools. It's up to the user/preset author to balance all of those settings, develop shaders, etc. Grab a good preset, with good tonemapping, like Aiyen mentioned, and see if those issues persist or if they are noticeable enough. Grab Aiyen's Skylight ENB or prod80's Serenity, or Oyama's K's. All have properly configured files. We all know skylighting is glitchy and needs to be fixed. Also, have you ever lived in the shadow of a mountain(s)? When the sun drops behind the peaks, it gets dark pretty fast. That's because shadows.

To conclude, and before I bow out of this discussion, I will just say, I apologize, I did not mean to offend. I did not expect or even want an apology from you, not that I think yours was sincere. Perhaps it's simply your writing or conversational style but you come off very confrontational and it tends to rub people the wrong way. Please, as a courtesy, would you try to be less abrasive? You did bring up valid points. However, Boris acknowledged how he will address them. Aiyen gave you some workarounds. Try it before you throw it out.

Anyways, I'll bow out of this conversation unless I find have something useful to add. I have other things to keep me occupied. I wish you a good day.

[ENBSeries]

Oh crap, i thought only have issues with water and transparent objects when drawing clouds, but depth of field can't be fixed internally, because clouds are transparent object. I don't know what to do then, change standart of external shaders to allow transparency of depth?

[number6]

How would you change the standard? Do you mean how the depth buffer sampler is provided in the shaders? Could you provide a "deep" depth buffer with multiple slices in separate samplers? Or 3d sampler?

I was also thinking, is it really an issue with clouds? First, they are always far from the viewer and second, there is rarely something behind them at with a big depth difference. Maybe that is naive?

[ENBSeries]

Clouds are fully 3d in space (otherwise i don't see any reason to implement them, see screenshot below), you may enter them or be above of them, so depth of field will have bugs similar to computing in fog. I don't know how to implement transparency for depth, it's very complex, on practice simpler to draw jitter pattern of holes and blur them, but it's very low quality for bokeh, unless specially fixed by dof shader. I can't just call drawing of depth of field several times with different depth slices and mix them, this may be good to keep existing standart, but not to performance.

[number6]

Can you detect transparent objects and only do multipass/slices for those pixels? Maybe that is still to big of a performance hit.

In a non real time renderer, the problem would probably be solved with stochasic ray tracing.