This document was compiled by wolfgrimdark and is used here with his permission.


Memory Managemanet and ENB Information - Updated 2014-03-26

JawZ has a great guide for ENBs - check it out so you can learn to empower yourself in managing ENB settings and tweaks.

Updated note on Reserved Memory Size settings from Boris - 512 is recommended for x64 for smoother framerates when video memory size is relatively low compared to texture mods installed. For x86 os this value must be small to keep off the game from ctds.

VRAM Formula Updated by Boris

Recent chats at ENBDEV.COM have indicated a better formula for computing memory as suggested by Boris:

VRAM - small amount of memory = optimal setting. Somewhere between 128 and 256 is suggested. I use 128 myself. So if your video card has 1GB of memory then set this to 1024 - 128 = 896.

Set VideoMemorySizeMb to 0 if you want ENB to automatically adjust a value, however it may not necessarily have good impact on performance (depends on machine to machine). The max value for this parameter is 10 GB or 10240 MB (anything above has no meaning).

SLI/CrossFire's VRAM is dependant on the lower value of VRAM for the card setup: if you have a GTX 670 w/ 4 GM VRAM and another GTX 670 w/ 2 GB of VRAM, you have an effective 2 GB of VRAM to play with. Likewise, ENB will consider 2 GB as your VRAM.

A large collection of quotes from Boris at ENBDEV

Many of these found by doing a search on parameter names, much of the below came from this thread.

ExpandSystemMemoryX64=true - invalid description. As i don't have x64 OS and heard about 3.1 gb limit (which is 4 gb), couldn't test myself with VMMap, so thought it's bug in game engine when some buffer pointer used in math, so i did this variable to fix issue by using memory range of 3-4 gigabytes. At same time this greatly reduce memory fragmentation, but effective only for x64 systems as they give 4 gb of virtual address space for 32 bit applications (winxp allow to set 4 gb, but it's very buggy mode and not recommended). I don't know how to describe this to users, but seems this parameter always work for everybody, so let it be true always, some users report that even this enough against their problems.

DisableDriverMemoryManager=false - again wrong, this depends from drivers, os and videocard. Fewer chances to get CTD or low performance if driver is bad and if it have own memory manager. But if driver is good, on the contrary it can give stable work and better performance. Also when set to true, d3d will try to do everything to not show any errors, at cost of performance or long freezes, so it's kind of "do or die" parameter, while set to false it's like "you can't? okay, ctd". Replace management of drivers by ENB's. May help for stability, especially in Skyrim. If you used a memory tweak by Boris, it's absolutely needed for AMD config using his memory tweaks as he develops with NVidia GPU. So he made this hack to improve compatibility.

DisablePreloadToVRAM=false - wrong again. Faster loading times because textures and geometry not actually created when game loading, they are creating only when visible in camera. Side effect is stuttering when object not in memory, but very useful when saved game won't load because of too much data in cells (imho simpler just to set lower quality, go to other place to save). Cell transition take longer time only when new cell objects are visible immediately, so not always valid definition.

EnableUnsafeMemoryHacks=false - yes, again. This is for videocards with a lot of video memory, because this mode is if player don't want to have any stuttering, any side effects (except alt+tab issue) or by some reason this set to false not work (reason actually other software). This mode also perfect if user have disbalanced system like 32 bit OS and videocard with 4 gb video memory. This mode don't use dynamic memory reallocation, so no compression, no enbhost.exe. Also it work only when ReduceSystemMemoryUsage=true set.

ReservedMemorySizeMb - this depends too much from 32/64 bit system and vram size. Smaller - less ram usage of the game (fewer CTDs), but bigger in most cases means less stuttering in very heavy areas where many mods used (and ugrid too high). If user have 512 mb of vram, this value 512 is also nice, because entire video memory will be dynamic, it's already small for heavily modded game, so better to not block it by static data. As i understood from posts, lower value also helps to some users with infinite loading screens (perhaps they happen because i'm forcing in cycle to free old memory and try again to allocate for new resources). 2014-03-26: 512 is recommended for x64 for smoother framerates when video memory size is relatively low compared to texture mods installed. For x86 os this value must be small to keep off the game from ctds

VideoMemorySizeMb - this is very unique for each system. What you wrote is correct, but not for users like Goliatron. Other d3d9 mods, web browsers, many other software want to use vram too and bad drivers add more headache. Almost all systems have vram available greater than physical vram, but some users reporting driver errors when vram is completely filled up with data (above i wrote why). If system is clean and only game is running, this value can be very huge, for example 16384 should work for rig with gf660 2 gb + 16 gb ram. But! If you have 6144 for 4 gb of ram and 2 gb vram, don't even think about running something else while playing, because there is a huge chance that non local video memory (ram actually) size will reduce because of other application and you will get very low performance or CTD.

Update 2014-02-02 (more on autodetect memory):

EnableCompression=true // leave this at true or your game will eat more memory.

AutodetectVideoMemorySize=false // --> only exists for ENB 243 and up. Try setting to true and set ReduceSystemMemoryUsage=true. Will autodetect your memory needs.

AutodetectVideoMemorySize=true set size of VideoMemorySizeMb internally to size of shared VRAM, which is physical VRAM + RAM used by display driver. From Boris: VideoMemorySizeMb is ignored when AutodetectVideoMemorySize=true is set. In this case mod trying to preallocate as much video memory as possible to detect it size, i tried that in some previous versions also, but own d3d memory manager stop working properly after that, because it's not designed for memory above 4 gb, so in 0.243 i starting another device to read that information, then destroy it (how this will affect other software like browsers or Optimus, i'm curious).

Some tips for fixing the issue when loading a saved game crashes but you can load earlier save then load the one that crashes.

What happens is the system is running out of memory and hanging. Any save that has more memory will load better. Afterwards the other saves load as the system has already got a lot of basics loaded. The first load of any game is the worst as it is the most demanding. The memory issue can come from a corrupt game, improper settings in your ENBLOCAL.INI file, to many textures, or some other issue causing the game to take to long to load and creating a CTD or freeze.

When it comes to fixing it well there are a couple of things. The very first thing I would try is the safety load mod which helps a lot with this type of issue:

http://www.nexusmods.com/skyrim/mods/46465/?

Next, if you use SKSE, make sure you have the script clean up installed. This just means creating (or editing existing) SKSE.INI file. Go to your "SkyrimDataSKSE" folder (if you don't have an SKSE folder just make it). Then edit (or make with a simple text editor like notepad) the SKSE.ini file and add this line:

[General]
ClearInvalidRegistrations=1

Over time that helps keep scripts under control.

Next make sure whatever ENB you use that you always set the MEMORY settings correctly for your PC. In version 243 Boris added a new auto-detect flag for detecting the proper memory settings, however this won't work unless you are using the most current ENB *and* you have enabled the flag for it as it is disabled by default.

Here is a sample enblocal.ini section with the newest flag - if you have an older one then you won't see that line of code.

[PERFORMANCE]
SpeedHack=true
EnableOcclusionCulling=true // --> only exists for ENB 243 and will increase performance on your PC by 5-10fps in some cases

[MEMORY]
ExpandSystemMemoryX64=true
ReduceSystemMemoryUsage=true
DisableDriverMemoryManager=false // this flag determines whether the game memory manager is used
DisablePreloadToVRAM=false // if true will reduce stuttering but if false can help with loading large saves.
EnableUnsafeMemoryHacks=false //only really needed by AMD users or Titan users
ReservedMemorySizeMb=256 // 256 seems to be the optimal size unless you have very little video memory then try 128, see quote below.
VideoMemorySizeMb=0 // if 0 game will use default. Best formula is your Video Memory Size - 128 MB
EnableCompression=true // leave this at true or your game will eat more memory.
AutodetectVideoMemorySize=false // --> only exists for ENB 243. Try setting to true and set ReduceSystemMemoryUsage=true. Will try to autodetect your memory needs.

One thing that may help is the "DisablePreloadtoVRAM" flag, Boris says "but very useful when saved game won't load because of too much data in cells (imho simpler just to set lower quality, go to other place to save)." Setting to false can mean faster load times because objects are not created when game is loading - instead they are only made when the camera can see them. Downside is some possible stuttering as you are then loading the objects after the saved game has loaded and started. However it can help with loading saved games due to memory issues because the objects won't be loaded as part of the save and hence not as much memory needed.

ReservedMemorySizeMb - this depends too much from 32/64 bit system and vram size. Smaller - less ram usage of the game (fewer CTDs), but bigger in most cases means less stuttering in very heavy areas where many mods used (and ugrid too high). If user have 512 mb of vram, this value 512 is also nice, because entire video memory will be dynamic, it's already small for heavily modded game, so better to not block it by static data. As i understood from posts, lower value also helps to some users with infinite loading screens (perhaps they happen because i'm forcing in cycle to free old memory and try again to allocate for new resources).

SSS Settings

Parameters of sss now work like following:
Amount - amount of sss in general.
EpidermalAmount - it's how much light upper layer use, real life examples hard to enumerate, nothing came to mind except skin itself, because it have brighter semitransparent layer of skin and it differ from bloody meat under it. Defintely wax, milk and similar simple things don't need this variable to be used (but how to do this in skyrim without making special enb only code and changes in models accordingly?).
SubdermalAmount - this is kind of transclusency of material to the light, including back side lighting (i didn't separation to back lighting, it linked to this variable, because back lighting control only reduce realistic look of skin). The main idea to use this to simulate light passed through the bloody flesh, but it also proper for wax. I don't use distance based coloration now, but when will do, this parameter may require to have different value.
EpidermalDiffuseSaturation, SubdermalDiffuseSaturation - these both work the same, they get diffuse texture (albedo) of model and apply saturation to it. Normal skin color turn to red, that's the base idea behind this. Recommended to use SubdermalDiffuseSaturation only as it fit better to skin lighting.
EpidermalMix - this is NOT amount of epidermal sss lighting, it's how it's blended with vanilla skin and subdermal. Important, epidermal applied after subdermal lighting, so bigger values covers subdermal lighting (so bigger SubdermalAmount or SubdermalMix can be set).
SubdermalMix - this is NOT amount of subdermal sss lighting and it not work like EpidermalMix. If value is low, then light is almost completely go through and lit only back sides. When it's bigger, then more light return on to surface. Bigger values give less realistic look of skin (except balls), so better keep realtively low with higher SubdermalAmount as compensation.

Good article on how it works: Human Skin - the Mental Ray Subsurface Scattering Fast Skin shader