Skip to main content
DynDOLOD - Dynamic Distant Objects LOD
Finally I can see my house from here!
Support me on Ko-fi

Mod Authors

For Creation Kit or LODGen object LOD generation, object LOD models need to be defined on the STAT base record and the Has Distant LOD flag should be checked.

This is a cumbersome and not very versatile method. DynDOLOD works with mesh mask rules to automatically match object LOD models to full models, without having to edit any plugins or records. It also allows to add object LOD for other types of base records. In the Create Mod mode, DynDOLOD creates a plugin with updated STAT base records to be merged in the another plugin so either LOD generation method works.

How to add your own object LOD models

DynDOLOD scans the whole ..\Meshes folder for *_lod*.nif files and internally reassigns them to the distant LOD meshes levels 0 to 3 based on the filename. All base records with a matching full model filename will be considered for LOD. The Has Distant LOD / VWD - Visible When Distant flag will be updated on the base records only if needed.

Using this matching method allows to create object LOD for base records of other types than STAT - which is the only type that allows adding distant LOD meshes on the record themselves. Adding object LOD to the *.BTO files for example for references using MSTT or ACTI base records works just as well in the game.

If no matching *_lod*.nif file exist, the default LOD assignments of the base record will be used. Check Prefer base record LOD assignments over rules to prefer the base record LOD assignments over the automatic mesh mask rules.

For example, to match an object LOD model to a full model with the filename house.nif, the object LOD model needs to have the filename house_lod_[0|1|2|3].nif.

It is important to understand - by Bethesda's own basic file naming conventions - that each filename is unique and there never exist two different versions of an asset with the same filename more than one time in different folders. If variants - even if only changing textures - of the same model are created, they need to have different filenames. It is not enough to keep files in separate folders. Again, this is based on the principles how Bethesda names files and helps greatly with compatibility with other mods and tools.

In case of filename collisions or in case of popular full models being replaced by many different mods - waterfalls or trees for example - the CRC32 of the full model should be added to LOD model filename in the form house_[CRC32]_lod_[0|1|2|3].nif. With the CRC32 in the LOD model filename there is no more ambiguity and users do not have worry about overwrite order of LOD assets. Also see the CRC32 explanations for 3D Tree LOD Model and ultra tree LOD. The file ..\DynDOLOD\Logs\DynDOLOD_[GAME MODE]_Object_Report.txt helps with checking which LOD assets were found and also what the expected CRC32 is.

When adding new object LOD models, it obviously makes sense to keep adhering to existing file and folder conventions and sort LOD meshes under meshes\lod\[MOD NAME|OBJECT TYPE] or meshes\[NEW WORLD MOD NAME]\lod\[OBJECT TYPE]. Similar for object LOD textures. Just try to avoid scattering object LOD models and textures across many different folders or worse together with their full models or full textures and instead stick to already existing conventions for better compatibility with other mods and to make things easier for other mod authors or users.

Consequently if the scanning for files finds a file with the same name again in a different folder, that file will be used instead of the file found before it. The folders are scanned in a specific order defined in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini:


For further control, certain subfolders can be ignored from the automatic scanning process by adding them to the IgnoreLODMesh= list in ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini. This is mainly done for mods that use conflicting filenames because they do not adhere to Bethesda naming conventions explained above.

The automatic matching assigns the different distant LOD meshes levels based on _[0|1|2|3] part of the filename . An object LOD model with the filename house_lod.nif will have distant LOD meshes in level 0, 1 and 2. To assign models to specific distant LOD meshes levels, use house_lod_0.nif for level 0, house_lod_1.nif for level 1 and house_lod_2.nif for level 2.

If filenames with a lower number are not present, filenames with higher numbers are automatically be used for lower levels. So if only house_lod_1.nif is found, it will be used for distant LOD meshes level 0 and 1.

LODGen supports using full models for object LOD, however do not copy full models directly to *_lod*.nif. Object LOD models are expected to be optimized and dedicated for LOD. If no such optimized or dedicated object LOD model exists, use mesh mask rules to instruct to actually use the full model for the desired LOD levels. This ensures better compatibility and future proofing as making any updates to the full model - also by other mods - will automatically be used for LOD generation. Include the mesh mask rules with the mod as explained below.

Using full models for object LOD works for many simply and static models. When LOD is generated with DynDOLOD, texture sets are applied accordingly for full models and object LOD models that use stitched object LOD textures. Newly required stitched object LOD textures are created on the fly based on the existing TexGen config files.

LOD does not support alpha blending of textures. It can either be transparent or not and the threshold is typically 128. In case a full model texture uses alpha or a different threshold, consider creating a dedicated object LOD texture with the threshold in mind.

Animated or models using specific shader options which are not available in static object LOD, should either use a mesh mask rule to use the full model or have an optimized and dedicated *_dyndolod_lod.nif created.

In case of questions or feedback, use the official DynDOLOD support forum for qualified answers and discussions. Mod authors are also welcome to contact me directly as well.

How to add a rule file for a plugin

Rules are applied when clicking the low, medium or high buttons. Check the debug log for a line for each rule file being loaded.

Rules shipping with DynDOLOD are in ..\DynDOLOD\Edit Scripts\DynDOLOD\rules\. In addition DynDOLOD first searches for matching rule files in the game data folder ..\DynDOLOD\. This way a mod author can package rule files directly with a mod. Rules found in the game data folder ..\DynDOLOD\ supersede rule files found in ..\DynDOLOD\Edit Scripts\DynDOLOD\rules\ with the same filename.

DynDOLOD reads rules from ini files that adhere to a simple file naming convention. Any non alpha numeric character is stripped from the mods filename and then changed to DynDOLOD_[GAME MODE]_[modfilenameesp].ini. To supply different rules for low, medium or high presets use DynDOLOD_[GAME MODE]_[modfilenameesp]_[LOW|MEDIUM|HIGH].ini.

See the mesh mask rules explanations about the rules themselves. Open any *.ini rule file in ..\DynDOLOD\Edit Scripts\DynDOLOD\Rules\ to see examples. Consider adding/editing mesh mask rules in the DynDOLOD interface and saving the preset to a file, open it in notepad and copy/paste the lines that need to be in the rule file for a plugin. Make sure the numbering of each line starting with LODGenXX= begins at 1 at the top and is continuous without any gaps or repeating numbers to the bottom. Reference rules start with modname.esp;00ABCDEF - the plugin filename is not changed. The first two digits of the form ID for the plugin load order file ID are ignored. Set them to 00 for easier reading.

Each rule file should have a standard section called [Skyrim LODGen] and all its rules apply automatically when the rule file is loaded. In addition sections that only apply if another mod is present can be created by using a section identifier like [Skyrim secondmodfilenameesp], again the mod filename is stripped of any non alpha numeric characters. Each section has its own numbering of each line starting with LODGen1= at the top of the section and is continuous without any gaps or repeating numbers to the bottom of the section. This can be used for simple compatibility patching.

These rules will only apply if the original mod the rule file belongs to and the mod in the section are both present in the load order.

How to ignore all references of a child worldspace for copying to parent worldspace and LOD

DynDOLOD automatically scans the walled Skyrim worldspaces MarkarthWorld, RiftenWorld, SolitudeWorld, WhiterunWorld, WindhelmWorld for new references that should have LOD representation in the Tamriel parent worldspace. The list of child worldspaces is controlled via the ChildWorlds= setting in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini under the [Skyrim Tamriel] section.

If a match is found and a similar reference is not found at the same position, rotation in the parent worldspace, a copy is made. The copy typically uses the LOD model - just like there are manually placed LOD copies for the vanilla buildings and objects. The scan ignores most trees by default. The list of ignored base record Editor IDs is controlled by the Ignore= setting in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini under the [Skyrim Tamriel] section.

To disable this scan for a specific plugin and worldspace, create a rule file for the plugin in the ..Data\DynDOLOD\ folder as explained above. Add a new section [Skyrim Settings] and a new line line IgnoreWorlds=[List of worldspace Editor IDs]. For example:

[Skyrim Settings]

Create Mod Mode - How to create LOD to include in your own mod

Create Mod mode

Mod authors can use DynDOLOD to generate tree and static object LOD to include in their new lands mod. Mod authors should not generate or include the papyrus scripted dynamic LOD.

There are a few technical reasons to not include the scripted dynamic LOD in a mod. For example it relies on fixed plugin filenames like DynDOLOD.esp. The patching process is intended to be used by users for their load orders and the current DynDOLOD does not work with dynamic LOD data existing in a different plugins. Future updates will create problems having to deal with different versions of the papyrus scripts or accompanying data files.

However, the Create Mod mode will automatically convert mesh rules intended for dynamic LOD into traditional neverfades (Persistent references with the Is Full LOD flag set). This works without scripts and is fully compatible when a user generates DynDOLOD for their load order.

In order for DynDOLOD to list a worldspace, a valid ..\LODSettings\*.lod file for the worldspace is required. Create it with LodFileGenerator. In addition the worldspace needs to not have a parent worldspace defined and its persistent cell needs to exist.

Set Expert=1 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini and then start DynDOLOD and click the Create Mod button. Alternatively set CreateMod=1 in the *.INI.

Instead of creating DynDOLOD plugins, this mode will prompt for a new mod filename which then later can be merged with the plugin of the mod. Select your new lands worldspace only and adjust settings as described below.

Base records for objects that now have LOD are updated: their distant LOD meshes levels and the Has Distant LOD flag are set. If Prefer base record LOD assignments over rules is set, existing distant LOD meshes levels are used over mesh mask rules and won't be updated. It is recommended to use this setting. Only base records for objects that are used in the selected worldspace are updated.

If Generate Neverfades is checked, all references matching rules which define Far or Near LOD will have the neverfade flag set instead. Note that the last '/' rule which contains the setting Far LOD defines that any object that usually has static LOD but has an enable parent or is initially disabled will be done as neverfade. Adjust other rules as well to balance the use of neverfades. Use the save/load preset buttons to keep the changes. Remember, clicking default, low, medium or high buttons will reset all rules.

Set BaseSignatures=STAT,TREE in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini if no static LOD for other base record types is desired - which would be more true to vanilla object LOD.

Once the process is finished, save the new esp which now only contains the minimum data needed for LOD to work properly. Merge the updated data with the new land mod.

Typically there is no need to include the source LOD meshes or textures in the mod, as they are all merged into the object LOD and tree LOD meshes and atlas textures. However, check the ..\DynDOLOD\Logs\LODGen_[worldspace]_log.txt for messages like 'Out of range ...' and make sure the mentioned textures are included with the mod as well.

Include any new or updated LOD assets so users can generate with TES5LODGen/DynDOLOD themselves.

Crediting TexGen/DynDOLOD or Sheson is the right thing to do and appreciated.

How to add LOD textures creation rules to TexGen

Mod Authors can use TexGen to generate mini-atlas LOD or single LOD textures for their mod. Also read TexGen Configuration for more explanations.

TexGen uses simple text files to build LOD textures from existing full resolution single textures. Text files shipping with DynDOLOD are in ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_[GAME MODE]_TexGen_*.txt. In addition TexGen first searches for matching text files in the game data folder ..\DynDOLOD\. This way a mod author can package text files directly with a mod. Files found in the game data folder ..\DynDOLOD\ supersede rules found in ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\ with the same filename.

TexGen reads from text files that adhere to a simple file naming convention. Any non alpha numeric character is stripped from the mods filename and then changed to DynDOLOD_[GAME MODE]_TexGen_[copy|alpha|noalpha]_[modfilenameesp].txt. The contents of a file is only read and executed if the mod is in the current load order.

copy - is a list of, per line. This is needed because the process expects the normal map * to have the same filename as the diffuse map *.dds. Have a look at an existing file like ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_[GAME MODE]_TexGen_copy_skyrimesm.txt as an example.

alpha files create textures keeping any source alpha channel intact, while noalpha files strip alpha from source files. LOD can only use transparency (binary alpha) and the threshold is typically 128.

Have a look at an existing file like ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_[GAME MODE]_TexGen_noalpha_skyrimesm.txt as an example. the table below deciphers the data for each column.

0brightnesssigned integer: like for tree LOD, negative darker, positive brighter
1red-gamma-multiplierfloat, red|green|blue = Power(red|green|blue-gamma-multiplier, 1.0 / Gamma)
4path\to\source\texture.ddsneeds to be in game data path, loaded BSA or current output path
5tilewidth-multiplierx|y * base size of tile on mini atlas
7x-pos-multiplierx|y * base size for position of tile on mini atlas
9path\to\destination\texture.ddswrites to output path
10x-atlaswidth-multiplierx|y * base size, defines final texture resolution of mini atlas

As already explained above, adhere to existing folder structures and file naming conventions to avoid having LOD texture scattered in full texture folders for better compatibility with other mods and to make things easier for other mod authors, users and yourself.

If any TexGen output including LOD billboards is included in a mod, set CreateMod=1 in the ..\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_[GAME MODE].ini so that textures with the same source and destination file path are being skipped and there won't be a prompt to uninstall TexGen later. Rules with the same source and destination file path are typically for updating mipmaps of full glow textures and not updating them will not affect LOD or LOD generation.

Crediting TexGen/DynDOLOD or Sheson is the right thing to do and appreciated.