sheson

It seems there are several issues with the load order and I am still not sure what testing you did that makes you believe why all or some of the issues have to do with the LOD mod? FAQ: Game: ILS or CTD A: More LOD uses more memory and this can cause infinite loading screen (ILS) or crash to desktop (CTD) if the game is not setup correctly. This should generally not be a problem with Skyrim Special Edition or Skyrim VR, but for Skyrim double check heap memory usage (block 1) with Memory Blocks Log from https://www.nexusmods.com/skyrim/mods/50471/ and adjust SKSE or SSME memory settings. Or use the alternative OSAllocator from crash fixes with pre-loader. Remove satefy-load if it is used. Setup ENBoost correctly. Set ExpandSystemMemoryX64=false in enblocal.ini. A: Do not use the experimental TreeFullFallBack setting without understanding what it does and what it is for. A: If heap memory is not the cause of CTD see ..DynDOLOD\Docs\DynDOLOD-README.txt for checking if a missing or invalid nif model used for dynamic LOD is the cause. A: Large load orders with many plugins might surpass the reference handle cap. SSE Engine fixes prints a warning. See https://www.reddit.com/r/skyrimmods/comments/ag4wm7/psa_the_reference_handle_cap_or_diagnosing_one_of/ Setting Temporary=1 in ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GameMode].ini may help in these situations, however converting large new land plugins to ESM is the preferred solution. A: If there are problems saving in Skyrim Special Edition, install SSE Engine Fixes 4.8 or newer and set SaveGameMaxSize = true in the EngineFixes.ini. Alternatively add/set [saveGame] uiCompression=1 in Skyrim.INI to change from the default 2 for LZ4 to 1 for zlib compression. 0 means no compression like games are saved in Skyrim. Follow the instructions in the DynDOLOD readme. Post the crash log from .NetFramework.

Is this supposed to be some meaningful report or help request? No information. No question. No effort. What did you do to troubleshoot? How do you know the issue is caused by the LOD mod generated by DynDOLOD? What game? What is the load order, INIs etc.? FAQ: Game: ILS or CTD A: If there are problems saving in Skyrim Special Edition, install SSE Engine Fixes 4.8 or newer and set SaveGameMaxSize = true in the EngineFixes.ini. Alternatively add/set [saveGame] uiCompression=1 in Skyrim.INI to change from the default 2 for LZ4 to 1 for zlib compression. 0 means no compression like games are saved in Skyrim.

xLODGen/DynDOLOD use the models and textures installed in the load order to generate LOD. Obviously you have mods that change the mountain LOD models or the snow LOD shaders. Whatever mods have models in meshes\lod\mountains\*.nif are responsible for how mountain rocks look in the distance. Whatever plugins modify 00050372 SnowLODMaterial or 0006AE38 SnowLODMaterialHD are responsible for how snow covered mountain rocks look in the distance Typically the nearest LOD mountains use the full mountain slab texture, which seems fine.

If the flickering goes away by setting uLargeRefLODGridSize=5 then the video shows the large reference bugs. As explained, large reference bugs are triggered by plugins overwriting large references. More information can be found in Docs/DynDOLOD_Manual_SSE.html and Docs\SkyrimSELargeRefGrid\SkyrimSE-LargeRefGrid.html Since DynDOLOD does not directly modify the load order it can be run at any time. Docs\trees.ultra\DynDOLOD-Trees.html explains how to generate 2D and 3D tree LOD in static object LOD.

As you already know, if the large reference system is set to off, then there is no flicker. In that case there is no need for a DynDOLOD.esm. The DynDOLOD.esm is needed so DynDOLOD itself does not trigger large reference bugs if it overwrites large references and to make sure dynamic LOD for large references works correctly. The large references bugs are triggered by plugins listed in the end of the DynDOLOD log. If you want to use the large reference system either remove the listed plugins or convert them to ESM - if possible.

As the included documentation and the DynDOLOD log ("Checking for plugins causing texture z-fighting flicker because of large references bugs") clearly states, the bugs are caused by third party ESP plugins overwriting large references. Those plugins would need to be removed or converted to ESM - if possible. Let me highlight the explanation about the IgnoreLargeReferences: If it is clear that the large reference system will not be used at all - uLargeRefLODGridSize = uGridsToLoad - a single DynDOLOD plugin can be generated without having to upgrade or downgrade large references to NearGrid/FarGrid. Set IgnoreLargeReferences=1 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini before generating LOD from scratch. Obviously this means the resulting DynDOLOD.esp might trigger large reference bugs if used with large references enabled. Obviously the default setting IgnoreLargeReferences=0 uses the DynDOLOD.esm to not trigger the bugs.

Form the DynDOLOD_Manual_SSE.html: DynDOLOD.exe will scan the selected world spaces for overwritten large references and compile a list to the log for user reference. Currently, the only option to mitigate all bugs is to turn large references off as the system is pretty much fubar - like most of the new and "improved" features in Skyrim Special Edition. Some bugs can be mitigated by converting plugins from ESP (plugin) to ESM (masterfile), but in reality it requires discipline and testing by mod authors to stay clear of making certain type of changes to certain existing large references to not cause texture flicker.

I am just scratching my head how it could be possible affected if there is no records in DynDOLOD plugins modifying it. Just wondering, don't worry about it.

Check the DynDOLOD.esm for errors with xEdit. If nothing shows up, do the same removal of worldspaces and records in worldspaces as already explained. However, no need to worry about keeping any records. Do all tests with DynDOLOD.esp disabled.

Odd. Verify which plugin causes it by disabling DynDOLOD.esp only and test if it starts just with DynDOLOD.esm. I expect the game to start with just DynDOLOD.esm. If not let me know. Once you verified that the issue is probably in DynDOLOD.esp, narrow it down by selectively removing records with xEdit. Make a copy each iteration before removing records. If removing records allows the game to start, restore the copy and remove other records so that the problematic data always remains in the plugin. Repeat until only problematic data remains. Typically one record. Typically only remove records from worldspaces. Often you can start by completely removing all worldspaces but Tamriel. Then continue by removing roughly half of the records each iteration. Do not remove *_ShesonObject, *_Minion_*, *_Firstborn_* - they should only exist in DynDOLOD.esp in the Persistent cell. Once the problem is solved and everything works, remove Plocktons Culling Glitch Fix.esp and generate occlusion with xLODGen or DynDOLOD.

Check/post the crash log from NetScriptFramework. Post the DynDOLOD log.

I am still interested why a reference that DynDOLOD does not overwrite would be influenced. If you check in xEdit, what other plugins in your load order other than Unofficial Path and Landscape and Water fixes overwrite the reference 000383C9?

Test with a new game. If that works make sure to follow the update instructions with a clean save correctly. If it still doesn't work, check in xEdit if the gate reference is overwritten in one of the DynDOLOD plugins. Take note of the last plugin to modify the gate. Is it really Landscape and Water fixes?

By default DynDOLOD ignores everything from the mod. The worldspaces are not supposed to be listed in the drop downs. Typically an assertions errors from xEdit mean that there is some kind of error in one of the plugins. Check the load order for errors with xEdit.exe before generating LOD. Fix all errors. Temporarily disabling plugins is a troubleshooting step and not a fix. If problem persists, post error report with entire contents (not just the last couple lines) of ..\DynDOLOD\bugreport.txt and ..\DynDOLOD\logs\DynDOLOD_SSE_log.txt to official forum

This is how the vanilla game works. The HD LOD models typically used for first LOD level use the full model mountainslab texture defined on the world record as HD LOD Texture. The full texture is already loaded because it used everywhere. It does not matter what type of model uses the texture. It is only loaded into VRAM once. Mipmapping takes care of the rest.

DynDOLOD_Manual.html "Fake Lights": The intensity of the fake light glow mesh can be controlled by setting FakeLightsIntensity in '..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAMEMODE].ini' from 1 = low to 9 = high. This value decides which Meshes\DynDOLOD\lod\effects\fxglowdefault*_dyndolod_lod.nif from DynDOLOD Resources they use. By default it is fxglowdefault6_dyndolod_lod.nif. If you do not want to generate again, you could either edit the base record that defines the NIF and change it to use any of the other files, rename any of the other files to replace fxglowdefault6_dyndolod_lod.nif, or edit the NIF in nifskope and change the intensity in the shader settings.

It seems you have issues wit the mod manager you are using. I suggest to read the manual of the mod manager and ask on the appropriate forum. Installing TexGen/DynDOLOD outside the game and mod manager folders according to its instructions can not modify the load order. Executing TexGen/DynDOLOD generates meshes, textures and plugins to the dedicated folder which is outside of the game and mod manager folders can not modify the load order. Zipping and installing the output as a new mod can not modify any other mods if you use a properly working mod manager. Nobody should be using Vortex to mod Skyrim. Use a proper mod manager like MO2.

Remove any older DynDOLOD Resources SE and install DynDOLOD Resources SE 2.81

Yes. There are no resources available to render them automatically. If a mod changes full textures that are used by objects with object LOD models which use pre-rendered object LOD textures, the mod should also update the pre-rendered object LOD textures. Only a few good mods do. https://forum.step-project.com/topic/14565-help-me-to-understand/?do=findComment&comment=238653 https://forum.step-project.com/topic/14238-riften-in-hd-by-md/?do=findComment&comment=237149 https://forum.step-project.com/topic/13984-unable-to-change-the-dyndolod-lod-textures/?do=findComment&comment=234304

Please, use a screen capture next time. The video shows how the engine works. When a new row of cells attached the full models load and then the LOD models unload. DynDOLOD does not change how the engine works. DynDOLOD uses the LOD models it finds in the load order to generate LOD. Many vanilla LOD models could use an update to be more detailed or match the full models more closely. As the manual of TexGen (and many posts about this subject) explains, TexGen updates a select list of object LOD textures. It can not update pre-rendered object LOD textures which are often used by the walled city LOD models. If you check a LOD model that is used for the Whiterun wall like meshes\lod\whiterun\wrwallcurve30up128_lod.nif you will see it uses the pre-rendered (it bakes coloring and features from 3D models) object LOD texture textures\lod\WRWallsLOD01.dds - which is not at all like the tile-able full texture wrcitywall01

The advantage of having a support forum with a search function is that users can often easily and quickly help themselves. Also I can move their posts to the appropriate thread, so just look above at second post for solutions.

From Skyrim-Occlusion-Readme.txt Quality - samples per cell. The more samples are used the more distant cells are potentially disabled. Generally use 2 for a quick update. Use 3 if time permits - it typically results in a few more areas that are disabled. Total time depends on selected mode (number of cells that need to be updated) and hardware. Quality 2 is reasonable quick with a large worldspace may be taking a minute or two. Quality 3 can easily be a couple magnitudes slower than quality 2. It may have to compare up to 256 (16 x 16) samples between two cells instead of 16 (4 x 4). Each cell gets its own thread and the calculations are a tight loop perfect for multi threading

Add these lines to DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE_childworldlod_Tamriel.txt then generate LOD again. JKs Skyrim.esp;00023840;MrkCWextTowerPlatform01 JKs Skyrim.esp;00001FA9;MrkCWextTowerPlatform01 JKs Skyrim.esp;00002033;MrkCWextTowerPlatform01 JKs Skyrim.esp;00001FE3;MrkCWextTowerPlatform01That will take care of the of the LOD models. Whatever happens in the second image I don't know. Open console and click the model/texture to find out its source. All I have there is the vanilla full model of the entrance structure.

Read the "Installation" section in the DynDOLOD_QuickStart.html which explains which command line argument to add for which game version. By default the tools start in Skyrim mode, which is the same as adding the -tes5 command line parameter. Add -sse as a command line parameter to DynDOLOD.exe/DynDOLODx64.exe or TexGen.exe/TexGenx64.exe to start the tools in Skyrim Special Edition mode. Add -tes5vr as a command line parameter to DynDOLOD.exe/DynDOLODx64.exe or TexGen.exe/TexGenx64.exe to start the tools in Skyrim VR mode. Add -enderal as a command line parameter to DynDOLOD.exe/DynDOLODx64.exe or TexGen.exe/TexGenx64.exe to start the tools in Enderal mode in case the Steam version is used. See DynDOLOD-Shortcut.txt for help.

Make sure the trees with the two billboard textures use external Billboard2.