FAQ

DynDOLOD is a set of tools that generates a LOD mod based on the load order and the options/settings made by the user. The visual results and the performance impact are what the user chooses it to be. Based on the settings and user choices, the resource requirements and performance impact can be less, same or more than the LOD of the vanilla game while the visual result is always vastly superior.

Certain INI settings can affect performance much worse then LOD ever could.

There are 3 presets: Low - almost none. Medium - like SkyFalls + SDO but 1000x better visuals. High - certainly yes. RTFM to adjust every detail yourself.

The generated object LOD is typically better optimized than vanilla LOD. If the game can show vanilla LOD, it can also show updated and better optimized LOD. Be wary about 3rd party LOD models. Especially 3D tree LOD models or simply renamed full models.

Performance is improved by converting specific neverfades to static object LOD or to dynamic LOD.

Generating properly working occlusion data for all suitable worldspaces with LOD reduces the performance requirements.

Drastically improved distance views with optional 3D tree LOD and grass LOD of course require more performance.

Be wary about non or poorly optimized 3rd party models being used for LOD because of assets or mesh mask rules included in mods. They can also cause long generation times.

Make sure performance is as desired before generating LOD and use a sensical load order and preset and settings, also in the game. Done correctly, the LOD patch can even require less performance.

3rd party download services like Nexus automatically scan every upload. Look for the green/blue circle checkmark for each file on the files tab.

Check the individual executable files in the download archive with https://www.virustotal.com to rule out false positives. A false positive is when the majority of tests do not find anything wrong.

Report the problem to the developers of the anti virus software. Add an exception for the false positive. Use better antivirus software.

Older versions are outdated, gone and should not be used anymore. Especially when they are several months old.

Wanting to use older versions for any reason defies common sense - especially when voluntarily participating in an alpha or beta test with the requirement to provide feedback and to report problems for the current version - and the cathedral modding concept - which works both ways. Insisting to use older versions means proper modding practice and how to use and support free tools that are under constant development to fix bugs and to support new and updated mods is not understood.

Always use the latest version available. Do not use or bother to ask for outdated versions. See Updating how to update to the latest version, keeping settings etc.

Newer versions fix bugs, contain updated/new assets and configuration files for the vanilla game and for existing, new or updated mods. See the Changelog.

Tools, configurations, resources and the documentation are regularly updated to address bugs, issues and better support the vanilla game and existing, new or updated mods and based on user feedback.

If a third party tool or guide requires an older version, the tool or guide is outdated. Contact its author for help or a fix for the issues with the tools/guides.

Troubleshoot or research errors and fix their cause if possible. In case of questions, problems or bugs ask or report them to the official DynDOLOD support forum so any issues can be solved or fixed for the current version and for all users regardless of their source.

The sane and proper modding and development method is to report bugs or problems, have them fixed in a new version or solved in the official DynDOLOD support forum.

BSOD, the PC crashing or turning off is a hardware, BIOS setting, OS or driver problem.

For example, problems with overclocking, memory timings, cooling, unstable power supply etc.

Searching the Internet for the BSOD code should help troubleshooting. Check the Windows event log for hints.

Tools like xEdit, xLODGen, TexGen, DynDOLOD etc. do not require a mod manager or a specific mod manager in order to work.

This documentation is mod manager agnostic as much as possible. Users are expected to have rudimentary modding knowledge and know how the mod manager they are using works. Refer to the documentation of the used mod manager, for example MO2, Vortex and modding guides.

Using an easy and versatile mod manager like Mod Organizer makes modding and troubleshooting infinitely easier.

Billboard tree LOD only looks and works correctly for the load order it was generated for. Generate tree LOD billboards with TexGen, make sure the TexGen output is not being overwritten and generate tree LOD with DynDOLOD for the current load order and make sure the DynDOLOD output is not being overwritten.

If the billboard tree LOD seems overly dark or bright, use the billboard brightness setting of the advanced mode to account for lighting changes made by ENBs or weather mods.

Do not install any third party tree LOD billboards. Remove all 3rd party billboards from the load order. Use TexGen to generate all the required and desired tree LOD billboards. Make sure that the TexGen output overwrites everything and is not overwritten by other mods.

Lookup the base record form id of a tree reference in ..\DynDOLOD\Logs\DynDOLOD_[GAME MODE]_Billboards_Used_[WORLDSPACE].txt and visually check and compare the texture with the full model.

Consider using HD tree LOD billboards or 3D tree LOD with ultra tree LOD.

Billboard tree LOD only looks and works correctly for the load order it was generated for. Generate tree LOD billboards with TexGen, make sure the TexGen output is not being overwritten and generate tree LOD with DynDOLOD for the current load order and make sure the DynDOLOD output is not being overwritten.

The tree texture atlas like ..\Textures\Terrain\[WORLDSPACE]\Trees\[WORLDSPACE]TreeLod.dds does not belong to the generated tree LOD in ..\Meshes\Terrain\[WORLDSPACE]\Trees\*.*

Verify that the tree texture atlas ..\Textures\Terrain\[WORLDSPACE]\Trees\[WORLDSPACE]TreeLod.dds and the tree LOD in ..\Meshes\Terrain\[WORLDSPACE]\Trees\*.* are the ones from the DynDOLOD output folder and from the same LOD generation process and none of the files are overwritten.

Billboard tree LOD only looks and works correctly for the load order it was generated for. Generate tree LOD billboards with TexGen, make sure the TexGen output is not being overwritten and generate tree LOD with DynDOLOD for the current load order and make sure the DynDOLOD output is not being overwritten.

Check plugins for errors and clean them from ITMs or deleted references. See xEdit Cleaning and Error Checking. The Batch Plugin Cleaner for Mod Organizer or the xEdit Cleaning Extension for Vortex help to automate some of that.

If the load order of plugins adding or changing tree references was changed, generate billboard tree LOD again so it matches the new load order. Consider using ultra tree LOD (also possible with only tree LOD billboards) to avoid such game engine limitations.

Tree LOD billboard showing in a child world like the walled cities, is caused by a game engine limitation. A plugin added a tree reference into the same area in the parent world. Tree references added to the Tamriel worldspace with positions that fall into the known vanilla areas of Markarth, Riften, Solitude, Whiterun and Windhelm should automatically be done as object LOD when LOD is generated by DynDOLOD 3 to avoid this engine limitation. For other child worldspaces or if the child worlds have been expanded, either disable that mod when generating tree LOD, or create a reference rule that targets the plugin and form ID of the full model tree and sets the Reference option to Enable - set all the other options the same as the tree mesh mask rule. Tree LOD generation skips all trees with enable parents leaving them to be done as static object or dynamic LOD which don't have the limitation.

Consider using ultra tree LOD (also possible with billboards only) to entirely avoid all these issues caused by engine limitations.

New references added to child worlds (cities) do not show in the parent world. If an object or tree is supposed to be seen in the parent world an identical reference should be be added to the parent world. Typically it would be best if the plugin that adds a new reference to a child worldspace that is worthy to be seen from the parent worldspace, also adds the corresponding references to the parent worldspace itself.

See Child/Parent Worldspace Copies for how references that are only added to child worldspace can have copies and LOD for them added to the parent worldspace automatically in case they are missing.

This is an engine problem that also happens with vanilla LOD and regardless of what tool was used to generate the LOD files.

Known as stuck object LOD after fast travel engine bug that can happen after fast travel especially to/in Whiterun. Consider using the dynamic LOD option of DynDOLOD which should fix that bug. If dynamic LOD is not used, use the LOD Unloading Bug Fix.

Can be caused by [MapMenu] uLockedObjectMapLOD=32 in Skyrim.ini (or SkyrimCustom.INI or a mod INI), especially if there are no object LOD level 32 meshes (which is the vanilla/default). See Trees on the Map for further explanations. Also see Maps And Map Mods and Seasons if relevant.

If this happen with Seasons, test with an older version of Seasons Of Skyrim, like 1.7.5.2.

Revert all INIs to default settings. Also be aware of [pluginname].INI in the data folder changing settings. Be aware of so called "secret" INI settings to "improve" performance or multithreading having unwanted side effects.

Known as large reference engine bug in Skyrim Special Edition and Skyrim VR that happens just outside the active exterior cells in the uLargeRefLODGridSize area. Pay attention to log message and read their explanations.

To fix all flickering caused by large reference bugs, use the large reference bugs workarounds.

Move the slider Large Object Distance on the View Distance tab of the Advanced options of the game launcher to the very left. Alternatively set [General] uLargeRefLODGridSize=5 in SkyrimPrefs.ini. If this does not affect the issue see the answers for Out of place or floating objects below.

Large reference bugs will cause full grass being rendered outside the active cells with the help of No Grass In Objects and DynDOLODGrassMode=2 and grass LOD being generated with Mode 2 to flicker in affected cells.

DynDOLOD does not change how engine and how LOD works. When new cells attach, first it loads the full models, then unloads object LOD. For that brief time both models show and there can be texture flicker. The more things the game has to load when new cells attach and the more system resources are strained the longer it takes to load full models and to unload object LOD.

LOD only looks and works correctly for the load order it was generated for. Generate object LOD textures and tree LOD billboards with TexGen, make sure the TexGen output is not being overwritten. Generate LOD with DynDOLOD for the current load order and make sure the DynDOLOD output is not being overwritten.

Some mods are made with disregard to generating LOD or require updated rules and configs for best compatibility. This is especially true for mods modifying the walled cities. Users are asked and welcome to provide feedback to the official DynDOLOD support forum in order to get everything working with as much compatibility as possible. Include a link to the mod and screenshots (with open console / form id) to show the issues if possible. If the reference is added by a DynDOLOD plugin, follow the "pluginname_formid" information found in the Editor ID of the reference to find the plugin from which this reference originates. Also see Child/Parent Worldspace Copies and How to ignore all references of a child worldspace for copying to parent worldspace and LOD.

Sometimes objects that have LOD are placed above other objects without LOD and thus appear to float in the distance. Use mesh rules so that the object has no LOD or that the other object also has LOD.

Test with new game, wait in the exterior for the DynDOLOD initialized message before moving. If the problem goes away, the updating of an existing save game with old DynDOLOD plugins went wrong. Follow the clean save instructions when updating DynDOLOD .

Wild edit added by a plugin. Get the plugin and reference form ID via the console in the game (use tcl in console to get close to object). If the object can not be clicked in console, it may be a deleted reference or a wild edit added in the child world, so for example try again while being in Whiterun). Check the DynDOLOD log messages for Potentially wild edit reference with z = 0.0. Look up the form id in xEdit and remove the reference with right click remove, error check and clean the plugin afterwards. Notify the mod author. If the reference is added by a DynDOLOD plugin, follow the "pluginname_formid" information found in the Editor ID of the reference to find the plugin from which this reference originates.

Check the log messages for deleted references. Check plugins for errors and clean them from ITMs or deleted references. See xEdit Cleaning and Error Checking.

In case large references are enabled in the game, make sure to generate both the DynDOLOD.esm and DynDOLOD.esp and to enable the Large Reference Fix in the DynDOLOD SkyUI MCM.

If the load order had script lag and deactivating/activating from the DynDOLOD SkyUI MCM main page does not reset out of place objects, do the clean save routine where "old" and "new" plugin are the same. Check the papyrus log if scripts from other mods cause errors or problems. Make sure that FPS is not too low to hinder script execution. Consider generating less demanding LOD. See Performance.

Sometimes referred to as the culling glitch. Caused by vanilla pre-computed TVDT - Occlusion Data. Has nothing to do with the generated LOD itself. Update the TVDT - Occlusion Data.

See answers for "Out of place or floating objects" above.

For something to have LOD, a LOD model or a LOD Billboard is required to be installed in the load order. Check the ..\DynDOLOD\Logs\DynDOLOD_[GAME MODE]_Object_Report.txt to find which LOD models have been found and which models are used for LOD representation.

If a LOD model does not exist, mesh mask / reference rules can be used to use the full model for LOD.

If a LOD billboard does not exist, use TexGen to generate it. Also see TexGen Configuration.

The Low and Medium presets purposefully do not make use of all available LOD models. Test with the High preset and compare mesh mask rules.

Do not hesitate to make a post to the official support forum to ask for LOD assets or mesh mask / reference rules to be added for a specific mod. Include information like form IDs, filename of the full model, mod etc.

See MOD Authors for how to create and name LOD models or how to add mesh mask / reference rules for specific mods.

Increase terrain LOD, object LOD or tree LOD distances in the DynDOLOD SkyUI MCM Settings.

Can be caused by [MapMenu] uLockedObjectMapLOD=32 in Skyrim.ini (or SkyrimCustom.INI or a mod INI), especially if there are no object LOD level 32 meshes (which is the vanilla/default). See Trees on the Map for further explanations.

If Seasons of Skyrim SKSE is used, make sure to generate LOD - including terrain LOD with xLODGen - for all enabled seasons or disable LOD switching for a season in ..\Seasons of Skyrim\SKSE\Plugins\po3_SeasonsOfSkyrim.ini.

A plugin might be changing the Editor ID of the worldspace. See Worldspace Editor ID Changed.

There might be a problem with the lodsettings file ..\LODSettings\[WORLDSPACE].LOD. Unlikely to happen for vanilla worldspaces. Note that in this case lodsettings files in *.BSA files win over loose files.

Has nothing to do with LOD or Occlusion data and also happens if no DynDOLOD output is active.

Caused by placed occlusion planes or boxes. Typically a patch is missing for a mod.

If the problem happens in Solitude and the Solitude Occlusion Planes patch from DynDOLOD Resources was installed, try generating a LOD patch without it.

Has nothing to do with LOD and also happens if no DynDOLOD output is active.

Caused by plugins erroneously modifying the XCLW - Water Height on cell records.

Remember, the cell records in the DynDOLOD and Occlusion plugins are being copied from the winning plugins at generation time.

Use xEdit to fix the wrong height values in the affected plugins. Either generate LOD generate again or also forward the changes to the DynDOLOD and Occlusion plugins.

Some worlds added by plugins are filtered out by default, because generating LOD for them might not be useful or requires special attention. Remove the worldspace name from the filter file ..DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_[GAME MODE]_worldspace_ignore.txt. Search for the mod, plugin or the worldspace name on the official DynDOLOD support forum for more information.

Only worldspaces that have an existing lodsettings file in ..\Data\LODSettings\[WORLDSPACE].lod are shown. Use xLODGen to create it for new custom worldspaces. Refer to the LODSettings-File-Readme.txt in its download archive.

Child worldspaces like Riften, Solitude, Whiterun and Windhelm use the Tamriel parent worldspace for LOD. Only Markarth has its own worldspace - a very reduced copy of the Tamriel worldspace.

Only worldspaces that have a persistent cell are shown. The persistent cell must be added by the same plugin that add he worldspace.

Check the log that all the required BSA files are loaded.

Make sure the [Skyrim|SkyrimVR|Enderal].INI contains the correct entries in its [Archive] section so the vanilla BSA files are loaded. Proper INIs with the correct settings are usually created when the game launcher is started the first time and no INI files exist. Note that the location / content of the INI files depends on the mod manager and currently used profile.

The OS, UAC, anti virus or another third party program is denying access to a file. Use the appropriate OS, UAC, anti virus settings etc. to allow access, including the TexConv.exe/LODGen.exe executables in the ..DynDOLOD\Edit Scripts folder.

Make sure only one copy of TexGen/DynDOLOD is running at a time. Use the Windows task manager to kill any hidden processes that didn't shutdown cleanly - or reboot.

Generating LOD assets or the LOD mod with all available options can be very demanding since many parts of the tools are multi-threaded and can spawn long running processes that run in parallel for different worldspaces and seasons. Creating GBs of optimized output files means several times as much of data is being read and processed.

Use the x64 versions of the tools. Let the OS handle virtual memory/page file settings. Close other programs and background processes.

If the system has more than 8 GB main memory, add the -memory command line argument when starting TexGen or DynDOLOD see if it makes a difference.

Do not use full model trees for LOD. Do not use the experimental TreeFullFallBack=0 setting without understanding what it does and what it is for. Be wary of mods using lots or complex full models for object LOD.

If TexGen runs out of memory, add a line TextureCache=10 to ..\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_[GAME MODE].INI. Try lower settings. Make sure as much video memory as possible is available by closing other programs.

If DynDOLOD runs out of memory while generating atlas textures, add a line TextureCache=10 to ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].INI. If there are still problems, set MaxTextureSize=8192 in the same INI file.

If DynDOLOD runs out of memory while generating occlusion, see Out of Memory while Generating Occlusion Data.

If too many concurrent LODGen processes running at the same time consume all available memory while generating seasons, limit their number per worldspace by changing the MaxLODGenPerWorldspace setting in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].INI.

If too many concurrent LODGen processes running at the same time consume all available memory, limit their total number by changing the MaxLODGen setting in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].INI.

If a single LODGen process uses a lot of memory, set LODGenThreadSplit in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].INI to a higher number. Set to the number of virtual cores for lowest possible memory usage. Since terrain LOD meshes are used to optimize object LOD, consider not enabling high resolution terrain LOD meshes (so it uses vanilla terrain meshes) while generating object LOD.

Use lower settings if required. For example, do not define to use 3D tree LOD models in higher LOD levels, use billboards instead. For example, reduce grass LOD density. Generate a large worldspace in one session, install output, then start DynDOLOD with the existing plugins active to update with the smaller worldspaces. Merge output. See Updating.

If Texconv runs out of memory, reduce memory usage of TexGen, DynDOLOD and LODGen first as explained above. Then test if instructing Texconv to not use the GPU by adding TexconvAdapterIndex=-1 under [TexGen|DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\[TexGen|DynDOLOD]_[GAME MODE].INI changes anything.

In case a error message window pops up, carefully read the entire error message and use Click on this link for additional explanations and help for this message to open the specific Help page for it.

See the list of Log Messages for their explanations, their severity and hints how to fix them.

Always use the the latest version of DynDOLOD/TexGen.

Follow the installation instructions and do not install tools or game into special Windows folders like Program Files, Game, Data or mod manager folders to avoid issues with files access etc.

Finalize the load order. Install mods, sort and resolve conflicts. Clean and error check the load order with xEdit. Clean every plugin that LOOT suggests to clean - ignore misinformation that cleaning any plugins is not needed or causes problems. The Batch Plugin Cleaner for Mod Organizer or the xEdit Cleaning Extension for Vortex help to automate some of that. Check the load order for errors with xEdit before generating LOD. Fix all errors. See this video for help (ignore the old cleaning instructions as that was already done).

All checks and resulting messages are related to the LOD patch generation. Ignore unqualified statements that claim otherwise as they are an indicator that the LOD generation and patching processes are not properly understood. This also means that DynDOLOD does not do a comprehensive check of the entire load order or all assets. It only checks records and assets that are potentially eligible for LOD or which are used by records or assets eligible for LOD.

Search the official DynDOLOD support forum for the message to find discussions about the same topic.

If the problem persists, post an error report to the official DynDOLOD support forum.

The selected configuration options together with the installed mods and assets can require a lot of work. Use sensible settings. Manually closing DynDOLOD or LODGen while they are still running results in incomplete output that can not be used in the game. Delete it.

If there are more objects with LOD, it takes longer and creates larger files. If there are more triangles in the models used for LOD, it takes longer and creates larger files. If there are more triangles in the terrain meshes, it takes longer to optimize object LOD. The higher the texture resolution, the longer it will take, the larger the generated output might be.

Do not use the experimental TreeFullFallBack setting without understanding what it does and what it is for.

Beware of mods adding or defining full models or not really well optimized LOD models for LOD.

It is normal for ultra tree LOD with 3D tree LOD models to take longer. Especially if the 3D tree LOD models are complex (large file size). Use or create optimized 3D tree LOD models or use tree LOD billboards instead. Do not use complex models for ultra tree LOD.

Check ..\DynDOLOD\Logs\DynDOLOD_[GAME MODE]_ModelsUsed_[WORLDSPACE].txt for a list of meshes and their total contribution to the object LOD meshes file sizes. If the total file size for an object exceeds hundreds of MBs, consider creating an optimized LOD model.

It is normal that Grass LOD generation takes considerable longer. The more grass placements (mods, game INI, data in the grass cache) and the higher the density setting the longer it will take and the larger the output will be. Grass LOD for complex grass may take even longer. The larger the grass cache, the larger the generated object LOD and the longer it takes.

In case Level32=1 is being set ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini to generate object LOD level 32 files for the map, it is normal that LOD generation takes longer and more files require more space. Especially in conjunction with LOD models made for LOD level 4 or full models being used for the map.

It is normal that generating LOD for seasons takes considerable longer and will produce large output. Four seasons in addition to the default means up to five times more work.

Anti Virus with real time scanning/protection can cause longer running times if they scan every accessed or created file. Consider adding exclusions for the typical assets file types like example *.BSA, *.NIF, *.DDS, *.CGID, *.BTR, *.BTO, *.BTT etc. or the data, temp and output folders.

The higher the Quality setting for occlusion generation, the longer it takes.

Crapware installed with graphics drivers is known to prolong running times. Do a clean install of the latest recommended or official driver only. Do not install crapware shipping with the drivers or terminate it before running the tools.

See answers for high memory usage above.

No. It is not supported.

Asking if it is save to pack things into BSA probably means that not all aspects are fully understood. That is a strong hint not to do it.

See the Load/Overwrite Orders.

PapyrusUtil or DynDOLOD DLL can not read *.[json|txt] data files from BSA, so they need to say loose files.

.. \ Record Flags -> <Unknown: 6> are intentional and can be ignored.

.. \ Record Flags -> <Unknown: 2> for MSTT terrain underside base records are intentional and can be ignored.

.. \ Record Flags -> <Unknown: 14> update to a recent xEdit version which knows the Partial Form ID flag.

Any other error indicates a problem that should be reported in the official DynDOLOD support forum.