GUIDE ENBSeries INI Guide

[JawZ]

I was thinking more of like users who do want to start from the beginning, either ENB default or with a total vanilla look, could have an easier experience learning all the different settings if the guide would follow something they have been used to seeing in the game.

 

But if it is a vanilla enhancment preset you're looking for their are a bunch of viable presets out there, I have recently released one such preset as well - https://www.nexusmods.com/skyrim/mods/40729/?

 

But I still think that a preset with complete vanilla state look is the best approach, to take the guide pictures with.

Even if it has altered ENB shader coding or not. And I know TechAngel85 has something brewing on his side and he is working on the picture implementation to the guide. In the end it will be up to the STEP authors of this guide to decide the approach and formatting of this guide.

Edited October 22, 2014 by JawZ

[Aiyen]

I would still say that the default file would be the best for the basic comparisons of the enbseries.ini. It will always be the same for everyone and hence is a better platform to build on. 

 

And who knows perhaps the shots can be used later to show why it is not the optimal thing to use for most styles! Or rather the limitations of it. 

[JawZ]

The default files are what is accesible through the the officia ldownload, and it would make sense to use those files as you say. Using any other files are a just from a personal preference and would just add more trouble in the end.

 

In summation, doing the general approach as I did with my guide would be a good approach.

[TechAngel85]

@hishutip,

Thanks for the offer but I'll take care of the screens. It all needs to be done on the same system and in the exact same manner for consistency. For that, it's ideal for one person to handle them all. Once I pick my spots out, and if your system is set up in the exact same manner, then I can share the saves and have you help.

 

@All,

The shots will be taken from a STEP Core or Extended installation. That shouldn't matter in the end because no one is going to be playing on an unmodded Skyrim. I'm thinking STEP:Core would be better since it's closer to vanilla.

 

For the [EFFECTS] section, I'm planning on using an ENB Preset (probably Vividian Vanilla). Since the out-of-the-box preset from ENB Dev isn't set up for the best compare for actual effects by default, I think it would be best to use an author's Preset to get the biggest visual difference with them on and off in this section. For the rest of the sections, I was planning on using the default Preset from ENB Dev as JawZ and Aiyen mentioned. It's best to use the default preset because that is what most authors should be using as a base when they start editing to build their own preset. Anyone who starts from scratch will see the same thing on their monitors that will be in the shots on the Guide because vanilla is the foundation. The only acceptation to this would be if the author created and changed their shaders first. (I don't know which is the more common path to take...change enbseries.ini first or change your shaders first?) If it's more common to change shaders before editing the INI, then I wouldn't be against using an already made Preset like Vividian Vanilla.

 

@SkyRealism,

MTichenor is great at what he does. I used to use SkyRealism and was a heavy supporter of it in the past; however, his presets are fairly out-dated and he doesn't seem to have much interest in updating them because he doesn't see much use in the new effects or simply doesn't have the time. We would need a preset that is updated to the latest version of ENBSeries; v0.264, in order to properly finish the Guide with a preset rather than the out-of-the-box ENB.

 

I agree with JawZ and Aiyen on this one.

[hishutup]

I have an install that is STEP extended.

I completely understand if you want to do it.

Otherwise there will be that one set that doesn't match the rest

 

I guess, shoot a message if you need my assistance.

[TechAngel85]

I don't think he'll be joining us but I did want to share prod80's message with the group: 

Well pretty easy...Intensity does:new.rgb = original.rgb * intensity//basically multiplying the original intensity, values under 1 make darker, and over 1 make lighterPower or Curve (same function, different name) does:new.rgb = pow( original.rgb, power )//increase contrast between dark and light, high power values (>1.0) make image darker or light less focused on lower intensities. Low power values (

[Aiyen]

The most common way is to activate Post process method 2 in the default file and then start altering the enbseries.ini. Even to this day quite a few screenarchers still just use the default file and do tweaks rather then playing around with the actual files. Even though the files are so easy to use now compared to how it was.... but well it is understandable since once you got a style you like then it can be tricky to find the same on a new file! 

 

My main motivation to make my own stuff was because I was really tired of just seeing PP2 variations everywhere... it just got boring. These days ofc. then most of it is boring since I look at an image and more or less just see the code that could produce it... and in general I think high quality textures do more for shots these days then the actual tweaking. 

 

In general the main limitation these days is that every time one come up with a new idea you realize it cant be done without asking Boris to do something...And that is not an easy thing to do. 

 

And lol at prods comment! Typical prod hehe 

But he is right.. that is what each does... however with the small twist that not all power functions actually behave the same way.. some of them are inverted in their behavior by Boris. 

[z929669]

Thanks! Be sure you're adding and not changing though. This way I can go back and gather all information from all contributors in order to put together a concise and detailed definition of the parameters. This also helps with flow since we all have different writing styles.

 

I'll be PMing some authors later today.

This also ensures that we can keep track of the sources of information.

[crime_syndicate]

Thank you for making an up-to-date ENB guide because good, up-to-date resources are not exactly dime-a-dozen. I'm sure that will help quite a few people (myself included :p)

 

 

By the way, talking of SSAO, is there a way to enable that black and white mode / disable rendering of textures in game, like this on nvidia's HBAO+ propaganda :

https://international.download.nvidia.com/geforce-com/international/images/tom-clancys-splinter-cell-blacklist/tom-clancys-splinter-cell-blacklist-hbao+.jpg

I saw Boris post similar stuff once to show something, but maybe he didn't make it accessible from user side hence why I'm asking.

[Matso]

Hi,

I've been looking at the Depth of Field Wiki page and had some thoughts about it - do we want the page contain information about the in-code parameters (both GUI and non-GUI configurable)? If so, then of what source code version? As far as I remember there are at least three, including mine, versions of the effect. I can make entry for the SVI series (Project MATSO and stuff) code, but others would require their authors to take part in the process.

 

What do You think?

MK

[TechAngel85]

This also ensures that we can keep track of the sources of information.

Exactly! I'm also using it to know who is actually contributing to what so I can write a more proper Thank You section later.

 

Hi,

I've been looking at the Depth of Field Wiki page and had some thoughts about it - do we want the page contain information about the in-code parameters (both GUI and non-GUI configurable)? If so, then of what source code version? As far as I remember there are at least three, including mine, versions of the effect. I can make entry for the SVI series (Project MATSO and stuff) code, but others would require their authors to take part in the process.

 

What do You think?

MK

Not a bad idea! You can add any non-GUI configurable information at the bottom of that page for your code. Others can do the same if they wish. It can either stay on the page or we can make a sub-page that contains all this information at a later time.

[TechAngel85]

Thank you for making an up-to-date ENB guide because good, up-to-date resources are not exactly dime-a-dozen. I'm sure that will help quite a few people (myself included :p)

 

 

By the way, talking of SSAO, is there a way to enable that black and white mode / disable rendering of textures in game, like this on nvidia's HBAO+ propaganda :

https://international.download.nvidia.com/geforce-com/international/images/tom-clancys-splinter-cell-blacklist/tom-clancys-splinter-cell-blacklist-hbao+.jpg

I saw Boris post similar stuff once to show something, but maybe he didn't make it accessible from user side hence why I'm asking.

I've not seen anything like this before.

[Aiyen]

Every single specific .fx file have their own terminology so that is a can of whupbehind (yes I just made that word up!) that we will need to figure out how to deal with. 

 

Also some files are ... monsters of variables and permutations of various ways of doing the same thing. Documenting all of that would be a rather.... immense task. 

Considering that most authors did not write any detailed descriptions about what their codes are actually doing to begin with then it would be an even larger task. 

 

I think it would be more appropriate if we actually made a repository of functions instead... since there is no point in documenting how 10 different files went about doing a saturation control.. since at the end of the day the end result is always going to be the same. Everyone who viewed my files know that is the way I am doing it with my own files, and I think it would be healthy if more did it that way rather then.... mass it all up. 

 

 

Also as for the SSAO thingy... You could make it so that everything is drawed only of a specific color in just about all of the .fx files if you want too. That way it will look like that up to a certain point. I imagine the way Boris is doing it is to simply prevent any .dds draw calls to be forwarded and then simply view the game as meshes. 

[TechAngel85]

Every single specific .fx file have their own terminology so that is a can of whupbehind (yes I just made that word up!) that we will need to figure out how to deal with. 

 

Also some files are ... monsters of variables and permutations of various ways of doing the same thing. Documenting all of that would be a rather.... immense task. 

Considering that most authors did not write any detailed descriptions about what their codes are actually doing to begin with then it would be an even larger task. 

 

I think it would be more appropriate if we actually made a repository of functions instead... since there is no point in documenting how 10 different files went about doing a saturation control.. since at the end of the day the end result is always going to be the same. Everyone who viewed my files know that is the way I am doing it with my own files, and I think it would be healthy if more did it that way rather then.... mass it all up. 

This is what this thread is for. Authors are encouraged to discuss such things! If any "best practices" result from a group effort of authors/users then that's all the better! STEP is all about those "best practices". Please do, discuss and come up with the best solution! I shall be a spectator and pretend as if I know what you are all talking about...might even learn something in the process.

 

EDIT:

Also, keep in mind that if any best practices result from any discussion, the more users that use the Guide as a reference will be that many more users putting those best practices into...practice.

[Matso]

@Aiyen - True - the amount of variations is immense. And I really like the idea of repositiory of functions. That should also go with some kind of standarisation for ENB mods. You know - if one adds new functionality it should have a certain interface, naming conventions etc. All for better conveniace for both ENB users and modders, to simplify using the various functions, combining them and adding new. I actually started a discussion about such matter on the Nexus, but couldn't moderate it properly, thus no outcome on that matter yet...

 

Anyway - what do You guys think? To make a kind of ENB building blocks standard for new and already existing functionalities?

 

MK