Mod Authors

Read the DynDOLOD documentation and make use of the official DynDOLOD support forum in case of questions, problems or for feedback. Mod authors are always welcome to message me directly.

Whenever there are any kind of compatibility issues or problems with the tools or the LOD patch in the game, they should be reported on the official DynDOLOD support forum. Especially when users report visual issues in the comment section for a mod and the issue seems to be some kind of compatibility problem or issue with DynDOLOD or the patching process. Users should be directed to the official DynDOLOD support forum for support or to report the problem. The purpose of the DynDOLOD patcher is to create a working LOD patch automatically without users having to worry (much) about patches etc. In particular, try to avoid modding or making mods like things were done before 2014, like overwriting full models or LOD assets just by their path and filename. Mod authors are not supposed to provide DynDOLOD support or troubleshoot related problems. Things are supposed to be automatic for the user as much as possible.

Whenever coming across a problem and the initial reaction is to disable something - which is only a troubleshooting step - or to make elaborate workarounds to get something to work, it could mean the way LOD generation and DynDOLOD in particular works is not fully understood or that there is a bug or an unexpected situation that is not yet addressed - either in 3rd party mods or the tools or whatever else. Remember, DynDOLOD is a patcher to automatically generate a LOD patch. The LOD patch it generates is not supposed to require patching itself. In particular, making plugins that use the generated DynDOLOD plugins or Occlusion.esp as a master is aclear sign of doing something completely wrong and opposite to how automatic patchers work. Instead report the problem or issue on the official DynDOLOD support forum, so that a qualified and properly working solution can be found.

Reach out and describe the problem or issue with as much information as possible in order to discuss and to address it one way or the other. There should never be a case where users have to do elaborate workarounds or do things that are contradicting the official DynDOLOD documentation. This does not mean that the documentation or the way LOD is generated is always right. It means that there is a case that needs looking at and that needs to be discussed and solved whatever the source and reason of the problem. Simply reporting the problem wastes less time then trying to create unneeded workarounds for bugs that should not happen in the first place. Especially when dealing with alpha or beta versions that are specifically made to find, report and fix these bugs.

LOD generation and all tools - just like creating mods - is a perpetual cycle of reporting and solving problems, in particular with the tools, their configuration files and their assets. Feedback in particular is the payment that every user of the tools is asked to give in order to improve the tools and processes.

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.

DynDOLOD has a lot of additional features that not only make LOD generation easier, but it also makes mod creation easier. For example, many LOD models support automatic texture replacements just like the full models, so there is no need to copy LOD models to new filenames only to manually change texture paths.

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 TREE, MSTT or ACTI base records works just as well in the game.

If no matching *_lod*.nif file exists, 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 established by Bethesda 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. In addition, the tools use pattern matching to determine certain aspects of models and textures automatically based on filenames and paths. The processes are not guaranteed to work for assets that do not adhere to the filename and patch conventions established by Bethesda and as required by the tools.

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. 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 and house_lod_3.nif for level 3.

If filenames with a lower number are not present, filenames with higher numbers are automatically 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 etc. In case there is a house_lod_4.nif, it will be assigned to level 3 only and not fill any of the lower levels.

If there is only one object LOD model with the filename house_lod.nif, it will be assigned to level 0, 1 and 2. Otherwise it will be used to fill the lower levels in case there are also numbered LOD models.

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.

For best results there typically should be LOD models created. This does not necessarily mean less triangle count or using LOD textures (which are often created automatically from full textures anyways), but also applies to adjusting UV coordinates, convert ordered nodes, changing shader settings and removing collision, dynamic parts, particles etc.

In case of some waterfalls, it is also necessary to create a static LOD model in addition to the dynamic LOD model.

Make sure you understand the LOD levels. There is often no need to create LOD models for the higher LOD levels because they are too small or insignificant. Mind their complexity and performance impact of adding insignificant objects to the higher LOD levels and the map. Do not mindlessly add *lod_1.nf and *lod_2.nif. Consider adding mesh mask rules for the different low, medium and high presets to control which LOD models (or none) are used for a specific LOD level to support performance requirements.

Make sure you understand that UV should be able to be atlassed (e.g. use textures from the object LOD texture atlas) by making sure the source UV is inside 0.0 and 1.0 coordinates for rendered object LOD textures and their scaled equivalent for stitched object LOD textures.

Make sure you understand how TexGen and DynDOLOD work and are used to replace full textures in LOD models on the fly to create and achieve object LOD textures being atlassed and for automatic texture set replacements.

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. Rule files for a preset only need to be created if they are different from the rule file without a preset identifier. There is no need to create 3 rules files all with the same content, obviously.

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

See Child/Parent Worldspace Copies.

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. For each such worldspace there is a dedicated config file ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_[GAME MODE]_childworld_[WORLDSPACE].ini with a Scan=1 setting under the [PARENT WORLDSPACE] 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\Configs\DynDOLOD_[GAME MODE]_childworld_[WORLDSPACE].ini under the [PARENT WORLDSPACE] 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]
IgnoreWorlds=WhiterunWorld,SolitudeWorld

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

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 different plugins. Future updates will create problems having to deal with different versions of the papyrus scripts or accompanying data files.

Do not include any DynDOLOD scripts, DynDOLOD DLLs, DynDOLOD or Occlusion plugins or data files from the the output SKSE folder in a mod.

Do not generate the LOD patch the usual way and then remove the generated plugins. This will obviously result in visual issues and generate unneeded and potentially conflicting files. Instead use the "Create Mod" mode to generate a patch plugin that then can be merged with the plugin of the mod or just kept as the sole plugin. This will ensure that object and tree LOD works properly for that worldspace and particular load order. Remember, LOD only works and looks correctly for the load order is was generated for. Generating LOD - in particular for the Tamriel worldspace - outside of mod lists or guides is typically a waste of time, also for users.

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 xLODGen. In addition the worldspace needs to not have a parent worldspace defined to be used for LOD and its persistent cell needs to exist.

To enable the "Create Mod" mode, set CreateMod=1 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini and then start DynDOLOD.

Instead of creating DynDOLOD plugins, the "Create Mod" 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 xLODGen/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 source.dds, destination.dds per line. This is needed because the process expects the normal map *_n.dds 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.

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.

How to generate LOD for a new worldspace

For a worldspace to be discovered by xLODGen or DynDOLOD for LOD generation, it requires a *.lod settings file in the ..\Data\LODSettings\ folder.

The file can be generated with LODFileGenerator.

Note that loose *.lod files do not overwrite *.lod files in BSA files. The *.lod file from the last BSA file wins.

It is recommended to center a worldspace around the cell 0, 0. For example because of floating point precision and because LOD occlusion data uses fixed coordinates from -128, -128 to 127, 127.

It is recommended to use a multiple of 32 for the South West (lower left) cell origin coordinates. For example -32 -32, -64 -64 or -96, -96.

If the worldspace has a parent worldspace defined, do not check Use LOD Data in order for the worldspace to eligible for LOD generation and for it to use its LOD meshes and textures.

Use xLODGen to generate terrain LOD. Use TexGen and DynDOLOD as explained above to include object LOD and tree LOD with a mod.