xLODGen, DynDOLOD and LODGen
xLODGen is a Creation Kit replacement LOD generator, meant for mod authors to generate vanilla style LOD for their mods and new worldspaces. xLODGen offers a few advantages over Creation Kit. For example, Creation Kit static object LOD has to use a texture atlas for all textures but one (the HD LOD texture), which not only limits visual quality but also means a great deal of extra work is required to produce LOD models. xLODGen allows the free use of textures like any other full model.
DynDOLOD expands the object LOD and tree LOD generation of xLODGen by automating many processes related to setting up LOD for mods and entire load order, automatic patching, including thousands of new LOD models, new LOD textures and adding new types of LOD and features for drastically improved visuals.
To create static object and tree LOD with the default LOD models and currently installed billboards, xLODGen scans the world for applicable references, builds the required texture atlases and then directly creates the tree LOD "meshes" and builds a static object LOD list that LODGen.exe uses to create the static object LOD meshes *.BTO files for the game to render the LOD.
DynDOLOD builds upon this process by automatically adding static object LOD for objects which didn't have any LOD before without the need to update base records in Creation Kit or xEdit with LOD model information. DynDOLOD improves the texture atlas creation. In addition DynDOLOD scans the world for objects that can also be so called animated or dynamic objects.
The major steps of DynDOLOD:
(1) Scan the ..data\meshes folder for '*_lod*.nif' files
Scanning is done in a way so that models with the same name found later take precedence. This way it is easy to 'overwrite' meshes by making sure they are found later in the scanning process depending on the folder structure. The scan order of folder is set in the DynDOLOD_[GAMEMODE].ini with Folder1=, Folder2=, etc.
Since the whole data/meshes folder is scanned - BSA loaded by xEdit, then loose files - mod authors that use new assets can provide lod.nifs with their mod and they are automatically discovered and used.
Skyrim LOD uses 3 object LOD levels. Only the largest objects like mountains and huge buildings need LOD in the highest level, large structures should be in the first two levels and obviously the closest level should have LOD from "everything".
A simple file naming convention decides the LOD levels a nif is meant for. See the Mod Authors for more detail. The system is based on the best compromise to match the default game settings.
(2) Apply patches
A simple patching system is used to modify or add new records based on patch files found in ..DynDOLOD\Edit Scripts\DynDOLOD\Rules\*.patch and ..data\DynDOLOD\*.patch
(3) Scan base records
Build a list of ACTI, CONT, DOOR, FURN, MSTT, STAT, TREE, GRAS base records suitable for LOD. Matching is done based on the full model name and filtered by the mesh mask rules. By default the distant LOD meshes settings on the STAT base records are ignored, unless the checkbox 'Prefer base record LOD assignments over rules' is checked or in case the full model file name matching didn't match anything.
CK and xLODGen generate static object LOD based on the Has Distant LOD flag and the distant LOD models defined on the STAT base records. For more coherent visuals DynDOLOD also adds static object and dynamic LOD for the additional base records mentioned above.
For example, statues can be an activator (ACTI) and thus have no vanilla object LOD even if a LOD model exists because distant LOD models can not be defined on ACTI base records.
In case of doors or gates are being done as static object LOD will not reflect open or closed states, but this will still be better than simply a gap in a stockade fence.
Trees have their own LOD system. However, it has one crucial limit amongst other limitations: such LOD trees can only be upright billboards. Trees growing at angles or lying flat on the ground can not be done by this system. Prominently a whole group of trees have no LOD. Any of the vanilla billboard resources together with DynDOLOD Resources adds billboards for more trees than the vanilla game.
In addition, since trees are objects too, their LOD can be done as object LOD with no limit on orientation or other engine limits inherent to the tree LOD system. The advanced option of DynDOLOD have a checkbox 'Ultra' that allows to add LOD for trees to object LOD instead of using the limited tree LOD system. This also allow to use 3D tree LOD models instead of billboards. Having LOD for trees in object LOD works well visually and performance wise, but static object LOD takes longer to turn off when full models load into view so the two models may flicker briefly.
External grass data files in the /data/grass folder can be used to add billboard type LOD to static object LOD. So GRAS base records are checked to see if billboards are installed for them.
(4) Apply rules
Apply rules that disable or make other direct modifications to references.
(5) Scan worldspace
If the selected worldspace is Tamriel the process also scans the 5 walled cities (which are so called child worldspaces) for references that now have LOD. These reference require a LOD representations in the parent worldspace Tamriel so they can be seen from the outside. DynDOLOD automatically creates carbon copies, unless the base record or references matches specific rules that exist to prevent it - for compatibility or performance reasons.
In case the existing parent worldspace reference does niot have XEMI record but the matching reference in the child worldspace does, it is copied, so high glow LOD windows have the correct lighting.
(6) Disable neverfades
(7) Add town references
(8) Generate object LOD
(10) Generate tree LOD
(11) Generate dynamic LOD
Add new base records with LOD model and new references with Is Full LOD (neverfade) flag for dynamic LOD. While the original reference is an object that is loaded in the active exterior cells area, the new reference typically is enabled when it is outside the area and disabled when in the area.
Working with a new reference means that the original reference is not modified by DynDOLOD. By using a copy, DynDOLOD can freely enable or disable objects based on distance to the player and enable parents at the same time. DynDOLOD checks either the original enable parent or the reference directly for its current enable status. So this system also works when quest scripts manipulate the original object directly without the use of enable parents.
Create JSON and TXT data files. The data files help the DynDOLOD Mod papyrus scripts to do as little work as possible when switching on or off dynamic LOD objects.
(12) Copy reference that have LOD from parent to child word
(13) Update portal boxes
Change PortalBoxes in processed worldspaces to just Boxes. Helps with performance in Skyrim/Enderal. Not enabled for Skyrim Special Edition, Enderal SE and Skyrim VR as they do not seem to cause performance issues in the new engine.
(14) Generate Terrain Underside
(15) Save worldspaces JSON and TXT data.
Steps 4 to 12 are repeated for every selected worldspace. Once all worldspace have been processed, write the data file containing information about all worldspaces for the DynDOLOD Mod papyrus scripts is created.
(16) Update base records
(17) Convert enabled references
If references are enabled that have the Visible When Distant flag set or use base records with the Has Distant LOD flag, static object LOD shows briefly for the cell while the full model fades in. References with enable parents are updated to use a base records without the Has Distant LOD flag and their Visible When Distant flag unset.
(18) Add x-markers
Some CELL records need to be present in the DynDOLOD plugin so that resetting original references that had their Is Full LOD (neverfade) flag removed keep working in existing saves. Adding x-markers ensures the copied CELL records are not reported as ITMs.
(19) Fix causes that trigger large reference bugs in third party plugins
MSTT base records require a flag to be set. Converted third party plugins often do no set the flag. Creating an overwrite in the DynDOLOD plugin with the flag set fixes this.
Overwritten references with the Initially Disabled flag and an XESP Enable Parent can trigger large reference bugs, even if the third party plugin has the master flag set. In case the reference is an UDR (XESP opposite player, z = -30000), creating an overwrite in the DynDOLOD master plugin which unsets the Initially Disabled flag and removes the enable parent opposite to player fixes this.
(20) Generate RNAM data
(21) Generate TVDT occlusion data
Generate TVDT occlusion data if the feature has been enabled by the user.
(22) Remove empty cells, sort and clean masters
Remove ITM cell records in the DynDOLOD plugins that might be left over after above processes completed.
Only keep masters in the DynDOLOD which are a hard requirement, because many users do not understand what a soft master requirement is.