sheson

I would like to know which ENB preset you are using, as I can not replicate. Maybe custom ENB effects or other INI settings play into it. Maybe also upload a modwatch or the Skyrim/Prefs INI settings. If the exact circumstance can be identified (and can not be fixed with useful INI settings etc.) it should be reported to Boris so he can look into it.

But 90000 is not 60000, so it should be fine. Didn't you already determine that disabling the large reference system by setting uLargeRefLODGridSize=5 fixed it? The stuck object LOD after fast travel happens either way.

Are you saying the bEnableLandFade setting changes how the ENB effect behaves? "It should always be loaded when generating terrain LOD." No idea how to say it any more clear. There are no mods that add back missing terrain, especially if all they do is change landscapes textures.

If there is an issue with ENB settings/effects then you should ask on the ENB forum or maybe the author of the ENB you are using. The Terrain ESM plugins adds back terrain for Skyrim (Tamriel worldspace) at the outer edges so there is no missing terrain meshes/textures when generating terrain LOD for Skyrim. It should always be loaded when generating terrain LOD. Use the chunk option to limit the number of textures that need to be generated. For example, check [x] Specific chunk, leave the drop down empty and set WS to the lower left cell coordinate of an 32x32 area, like 0, 0. It will then generate all textures up to 31,31. Not all worldspaces have their origin at 0,0 so you will have to check already generated meshes/texture filenames for their lower left coordinates. Then you can check the result in the game by checking the updated area for the result. Once the settings are satisfactory generate for the whole worldspace.

No, obviously. From DynDOLOD_Manual_SSE.html The user needs to enable or disable the Large Reference Fix toggle, since it is not possible to determine the current setting through normal papyrus scripting. The GetINI/SetINI functions do not work with unsigned integers. If the large reference system is used (uLargeRefLODGridSize > uGridsToLoad), the Large Reference Fix checkbox should be checked, so that dynamic LOD objects for large references in the FarGrid switch correctly. If uLargeRefLODGridSize is turned off (uLargeRefLODGridSize The setting can be changed at any time, however it is suggested to do the switching in an interior (or go into inside after the change), so the new setting can be applied correctly to all affected dynamic LOD objects once going outside again. I do not know anything about that script. Technically, any plugin that modifies large references (or bad LE ports that do not update the data flag on MSTT base records) is (visually) incompatible with Skyrim Special Edition. One would expect mod authors to know about such a long explained and famous issues and create plugins that do not trigger bugs. Some have. In case there is a reason a plugin has to be an ESP (converting seems risky), I would move only the large reference overwrites to a new plugin with ESL/ESM flags - typically they are visual edits . It's very rare that a large reference is used by a script or has an enable parent (and in that case the bugs are often triggered regardless of plugin type, so I wouldn't bother with them). The bugs are not always very prominent, so I would try to single out the cells and were they are the most obvious.

The DynDOLOD log lists all modified large references and the plugin do the changes. Only ESM flagged files supports adding/modifying large references without triggering the bugs the way non flagged plugins do. Use the Skyrim SE - Generate Large References.pas script in case an ESM adds new references in existing or new worlds and you want them to be large references (if they meet the criteria). In case large reference bugs are triggered by an ESM modifying a large reference, using the script to update the overwriting ESM might help.

LOD testing with a "new" game can be done with coc Riverwood or coc Whiterun etc. from main menu. Texture resolution does not matter. Running out of VRAM does not causes z-fighting - which typically is two models occupying the same 3D space. Also in case of the tower, low, medium, high settings should all generate the exact same LOD for it.

Q: Game: Out of place objects / floating objects / flickering full models A: If LOD was generated for a different load order generate LOD for the current load order. A: Test with new game, wait in the exterior for the DynDOLOD initialized message before moving. If problem goes away, the updating of an existing save game with old DynDOLOD.esp went wrong. Follow instructions how to update save game with a new DynDOLOD.esp. RTFM, watch the video or check DynDOLOD SkyUI MCM. The clean save routine can also be redone with the same plugin to reset everything. A: 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. Consider generating less demanding dynamic LOD, see 'Performance' section in ..DynDOLOD\Docs\DynDOLOD_Manual.html A: Wild edit added by a plugin. Check the DynDOLOD log for messages about wild edits. Use console in the game and click on object to retrieve the form id. Look up the form id in xEdit and remove the reference, clean plugin afterwards. Notify mod author. If object is added by DynDOLOD.esp, follow the "pluginname_formid" information found in the Editor ID of the reference to find the plugin from which this object originates. A: Deleted record by a dirty plugin. Check the log for messages about deleted references by dirty plugins. Clean all UDRs and ITMs from dirty plugins. A: Sometimes LOD objects are placed on top of 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. A: Game engine limitation. If the game enables objects that have static object LOD, the entire static object LOD for a cell may briefly show with the full models at the same time. Since now more objects have LOD this might be more obvious than before, especially while playing the intro. Consider installing the generated LOD mod after completing the intro. A: If the problems is stuck object LOD in Whiterun after fast travel, change Distant Object Detail on the View Distance tab of the Advanced options of the games launcher from Ultra to High. Alternatively try just slightly changing the value fBlockLevel0Distance=60000 in SkyrimPrefs.ini to 57000. A: Some mods are made with disregard to generating LOD or require updated rules and configs for best compatibility. This is especially true with mods modifying the walled cities. Users are asked and welcome to provide feedback to https://forum.step-project.com/forum/101-shesons-dyndolod-support in order to get everything working with as much compatibility as possible. Include a link to the mod and screenshots (with console / form id) about issues if possible. A: Flickering textures (full and LOD model showing at the same time) in the LOD area outside the active cells in Skyrim Special Edition and Skyrim VR are caused by plugins triggering the large reference bugs as explained in ..DynDOLOD\Docs\DynDOLOD_Manual_SSE.html. Verify if the problem goes away by setting uLargeRefLODGridSize=5 in SkyrimPrefs.ini. A: If the problem is stuck object LOD in loaded cells, it can be caused by uLockedObjectMapLOD=32 in Skyrim.ini. Sounds a lot like large reference bugs to me.

A couple month ago we discussed flickering while new terrain is loading in Skyrim Special Edition. After some testing, we realized this is caused by a new land fade feature added to Skyrim Special Edition (and Skyrim VR) - which thankfully can be disabled: Skyrim.INI [Display] bEnableLandFade=0 By default this setting is missing from the Skyrim.INI and thus defaults to 1 = enabled. Add the setting to the INI to disable the stipple fade so that terrain fades like it does in Skyrim. I did several tests back when we discussed the issue, but it seemed prudent trying to explain this issue and its simple fix properly with videos and images since more people seem to notice the issue. Top left shows vanilla Skyrim Special Edition meshes. Top right meshes were generated with Oscape and are from the mod Terrain LOD Redone. Lower left shows high quality = 0 xLODGen meshes with protect cell border which are z-shifted (lowered) by 25 units - an idea suggested by users. Lower right show high quality = 0 xLODGen meshes with protect cell border. For the video the terrain LOD textures have been made way too bright to better show the artifacts. If the terrain LOD textures (together with noise.dds) match the full textures well, the artifacts are barely visible if at all. Here are some stills from the video to point out what to look for. The left image shows the artifacts that happen because of the new fade mode. Terrain LOD meshes and full terrain meshes now briefly show at same time while the full terrain is faded it. If the terrain LOD mesh is slightly higher, then the fading of the full terrain can not be seen because it is underneath the terrain LOD. In case of the high resolution xLODGen the terrain LOD more or less matches the full terrain exactly, so z-fighting happens. Lowering the terrain LOD seems to eliminate the issue, but pay attention to the video, as a straight line can be seen the currently active cell and the loading cell while the fade happens. The right image shows the same scene again, not with the fade disabled. No artifacts for all 4 types of terrain LOD meshes. Watch out for the very obvious rise of the z-shifted terrain LOD meshes. Flipping back and fourth the first and second images shows why z-shifting terrain LOD is not a useful workaround (in case the straight line artifact of the first scene seemed bearable). Because the full water immediately loads and does not fade, the LOD coastline and shallow islands simply disappear for a second until the full terrain is faded in. As always, it is generally better trying to find the cause of an issue and fix that if possible, instead of using band aids / workarounds for the symptoms. The red circled areas point out a common visual bug of vanilla/Oscape meshes, which are terrain drops at the edge between active cells and terrain LOD. This is fixed by using the protect cell borders setting in xLODGen. The visual issue with the mountain range of the Oscape meshes is a well known bug of Oscape, where cells have bottomless terrain LOD. It happens if other plugins - including DLC - overwrite landscape data of Skryim.esm.

Did you add the mod after generating LOD? Did you use the latest DynDOLOD version to generate LOD?

Every tool has its own documentation. They are not modding guides.

Run a chkdsk on the drive. Delete the output folder and start from scratch. The TexGen log has two generations. The first one had no errors, so we know it works. Something must have happened with the drive or system in the meantime. Is it a USB drive maybe that was unplugged without waiting for all data to be written?

Make sure none of the generate files from the output folder are being overwritten by other mods/Overwrite folder. Check that the DynDOLOD Resources SE installation contains meshes\lod\imperialice\impexticelighthouse01_lod_2.nif Open Meshes\Terrain\Tamriel\Objects\Tamriel.4.8.24.bto in NifSkope and check if it shows the impexticelighthouse01_lod_2.nif model on top of the rectangular base structure. Open DynDOLOD\Edit Scripts\Export\LODGen_SSE_Tamriel.txt in a text editor and search for 000D5365. You should find a line that looks like this: 000D5365 00010400 34483.082031 111326.125000 -11418.441406 0.0000 0.0000 5.7296 1.0 ImpExtIceLighthouse01 00010800 Snow meshes\dungeons\imperial\exteriorice\impexticelighthouse01.nif meshes\lod\imperialice\impexticelighthouse01_lod_2.nif meshes\lod\imperialice\impexticelighthouse01_lod_2.nif meshes\lod\imperialice\impexticelighthouse01_lod_2.nif

"Cannot create file "F:\Games\SSE DynDOLOD\DynDOLOD\DynDOLOD_Output\skse\plugins\StorageUtilData\DynDOLOD_DLC2SolstheimWorld_Objects.json". The file or directory is corrupted and unreadable" Looks like the OS, antivir or some other crapware is preventing file access or interfering somehow. Could also be hardware/BIOS instabiities because overclocking, memory timings... etc. I bet the TexGen errors have the same reason. Upload bugreport.txt

Read https://forum.step-project.com/topic/14250-skyrim-tvdt-occlusion-culling-data/ which explains what to generate in which order. https://forum.step-project.com/topic/15235-clarification-on-using-lodgen-and-dyndolod-on-sse/

Don't worry about it. We all learn from these types of problems for the future.

Really, no problem. It seems that important detail is missing from the guide, unfortunately.

Yes there is. There will be visual issues like really low quality textures and stuff. Make sure to compress the meshes and texture into two different BA2 files. When doing the textures archive, make sure the format is set to DDS instead of General.

Well, for a test, check what happens if you just install the loose output only. Double check in MO2 right window data tab that the loose files are not being overwritten.

The screenshot shows NAME - Base is empty / Null Reference. This typically only happens when DynDOLOD stopped prematurely with an error and an incomplete plugin is saved. Generating from scratch and making sure there are no errors should solve the problem.

You packed the output into BA2 files? Their contents might be overwritten by loose files or something happened to it when creating the archives.

FAQ: LODGen.exe: Runs a long time / The LOD files generated are several GB in size A: The selected configuration options require a lot of work. Do not manually close LODGen.exe. Wait for all processes to complete before closing DynDOLOD. A: 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. A: Do not use the experimental TreeFullFallBack setting without understanding what it does and what it is for. If you didn't change anything in the load order, game or LOD generation settings between generations and yet experience difference in the execution times it seems obvious that there is something going on with the OS or hardware/BIOS settings maybe. Make sure antivir or similar crapware does not block anything or interferes somehow.Install/Update/Repair latest Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019 Let Windows handle the page file / virtual memory.Do not change the load order in the mod manager while processes are running. There should be no need to reinstall Windows in order to use programs. Maybe Windows or something is updating between runs that causes problems.

The crash log shows that there is a reference with form id 13002419 in DynDOLOD.esm that has no base record (BaseForm: null). Look up this reference in xEdit. Does it show an unresolved error for its base record? It might be because the log for each generation shows that you tried to update existing DynDOLOD plugins. "Update an existing DynDOLOD.esm and DynDOLOD.esp? If this is not successful start from scratch." The initial generation probably stopped with an error, but you installed the output anyways. Do not install or use incomplete output that has errors. Try generating from scratch without any old DynDOLOD plugins being loaded. Also, the game is installed to Program Files x86. To avoid issues with UAC, antivir etc. the game should be installed outside of such special Windows folders.

Good to know. DynDOLOD and xLODGen terrain LOD beta always contain the latest version of LODGen.exe with all its updates I made between releases.

Was it a corrupt NIF that you could fix by reinstalling it from the download archive?