TES Skyrim 0.214

[KuroTenshi]

Still trying to fix bugs of fake antialiasing via geometry offsets, for some objects it work relatively good, at cost of performance
http://i.imgur.com/UEREvRP.jpg
http://i.imgur.com/82JVmyc.jpg

Wahoo ! Really cool (if the 1st screen is the one with the effect) ! But I see a bug on the rock with green moss. What's the loss in performances ? If it's 5fps, It worths it.

[ENBSeries]

Performance loss is huge, when disabled 44 fps, when enabled 23 or something like that, depends from objects in camera. Compared to native hardware transparency antialiasing, it performance about 32 fps, while 42 if just msaa enabled. Probably will do only 2 extra "samples" for this fake antialiasing instead of 4, then 29 fps performance. Also that bugs on rocks can't be fixed without additional performance cost, so better to apply for objects like grass, hairs and other with alpha test. Sad that wood objects like roofs will not be antialiased then, but one more important reason for that is deffered shadows, when character in shadow, but ground behind it not, then bright outline very visible (like bug on clouds mod).

[ENBSeries]

I'll crush the wall by head soon while seeking solutions against existing limitations of external shaders and compatibility with old presets. Don't like post processing color filters, but because everyone use sweetfx, i need to remove it by replacing functionality, the problem how to make this fast and less painful for preset makers and users. In effect.txt performance is lower at least because one extra pass compared to code in enbeffect.fx, also inside enbeffect.fx data have much higher precision. In most cases nobody notice difference as nobody see it with sweetfx or fxaainjector, but effect.txt used by other presets frequently. After effect.txt will even worse performance (not much actually, but i prefer not to spent this resourse for nothing). Before enbeffectprepass.fx can't do, because data is hdr and any standart understanding like contrast, gamma, saturation have different meaning there, even if i'll adopt math to look the same, customized enbeffect.fx files have tonemapping and it change look too much. Recompile enbeffect.fx and insert in the end of it color correction code automatically is risky method, preset maker can make tricks like using one pixel or line for extra data passed to effect.txt (adaptation for example), so i'll broke such info. Making color controls under #define similar to palette code is also not good solution, this is simple for me, but all preset makers must adopt their code or my parameters in editor will not be used at all. From other side, i can make any number of color control variables, but they can't achieve all features which some user may want, so at least wrong to make predefined variables in enbseries.ini.

[CorvoAttano77]

It's hard to tell what is wanted and what is considered useful/useless feedback...

[skysan4298]

I would have stopped playing skyrim 9 months ago if it weren't for ENB.. 214 has been better for me in general. I improved my ability to do x2 down-sampling and slightly smoother game play. I haven't had very many issues with TAA and overall works well for me on my system.

I agree completely about how ENB keeping Skyrim playable, and ENB is the main reason why keeping me playing Skyrim more than a year. The Skyrim thread manager is so screwed up, and it is now able to load a save that I couldn't with ReduceSystemMemoryUsage=true. I don't think we can effectively test when Skyim is too unstable. As you said, 0.214 appears to be the best memory enhancement iteration, so Boris should move on with the graphic enhancement.

[Fequois]

I'll crush the wall by head soon while seeking solutions against existing limitations of external shaders and compatibility with old presets. Don't like post processing color filters, but because everyone use sweetfx, i need to remove it by replacing functionality, the problem how to make this fast and less painful for preset makers and users. In effect.txt performance is lower at least because one extra pass compared to code in enbeffect.fx, also inside enbeffect.fx data have much higher precision. In most cases nobody notice difference as nobody see it with sweetfx or fxaainjector, but effect.txt used by other presets frequently. After effect.txt will even worse performance (not much actually, but i prefer not to spent this resourse for nothing). Before enbeffectprepass.fx can't do, because data is hdr and any standart understanding like contrast, gamma, saturation have different meaning there, even if i'll adopt math to look the same, customized enbeffect.fx files have tonemapping and it change look too much. Recompile enbeffect.fx and insert in the end of it color correction code automatically is risky method, preset maker can make tricks like using one pixel or line for extra data passed to effect.txt (adaptation for example), so i'll broke such info. Making color controls under #define similar to palette code is also not good solution, this is simple for me, but all preset makers must adopt their code or my parameters in editor will not be used at all. From other side, i can make any number of color control variables, but they can't achieve all features which some user may want, so at least wrong to make predefined variables in enbseries.ini.

Really, Boris, write the code in the direction you want it to go. ENB isn't going anywhere anytime soon (and I would personally find it exciting if your technology was licensed by third-party development studios), so refactor, change, add and remove after your own goals and ideals! I'm 100% sure we users and preset authors will support and adapt. /applaud

Also, .214 is excellent. I haven't had a problem yet, hence a remarkable lack of bug reports ...

[Euther]

Still loving the new memory management!!! This is the best addition to skyrim, I think! Thank you very much !!!
Just loaded this new version, and it seems like inside, it is to RED to me.
What settings can I adjust to lower RED tones a bit?

Thanks,
E

[KuroTenshi]

Boris

For this kind of Antialiasing, I think only objects with alpha channels like grass, plants, trees and barriers are needed. Indeed the impact is huge ! If you can reduce it to "only" 10 fps in hungriest situations (for example by using 2 samples instead of 4 (that is already good), it'll remains fine for me.



As you can see, no problem for me to test it Xd.

I saw too your new Subsurface Scattering. I love it. It's more detailed and natural. Thank you !

For shaders, what I can suggest is allowing includes for *.fxh files (or any extension for the shaders) in enbeffectprepass.fx. I think enbeffectprepass.fx is a good compromise between performance and user-friendliness. At the beginning we'll have effect to apply and then variable to declare with the good values. The usage is rather similar to SweetFX. But fxh files will have to be documented to tell users what variable have to be added and which kind of values they support.

[ENBSeries]

Enbeffectprepass.fx can have fxh or any other file type to be included, it's standart feature of hlsl and there is no need to change anything.
Your screenshot is that kind of place where transparency antialiasing for grass cost the most performance and i tested in similar conditions. Anyway, i did it as new variable and it is toggled internally between hardware method and mine, depending from msaa enabled or not (also it disabled when temporal aa enabled). I thought about making per object antialiasing, but it's too much cost to detect every time if it's from list of antialiased objects or not, on cpu.

[KuroTenshi]

Enbeffectprepass.fx can have fxh or any other file type to be included, it's standart feature of hlsl and there is no need to change anything.
Your screenshot is that kind of place where transparency antialiasing for grass cost the most performance and i tested in similar conditions. Anyway, i did it as new variable and it is toggled internally between hardware method and mine, depending from msaa enabled or not (also it disabled when temporal aa enabled). I thought about making per object antialiasing, but it's too much cost to detect every time if it's from list of antialiased objects or not, on cpu.

Don't know if it can help you, but maybe could you just scan the attribute of nif files that determine the behaviour of the mesh toward lighting (see Mindflux fixes). With chance, you can have only "plants" or so.
Nif files are a lot smaller so maybe It can help.