sheson

LOD meshes and textures do not affect INI settings. The version of the LOD generators does not matter for the INI setting. See above about the INI setting. You need to actually check all the used INI files. The last one the game loads is the one that is being used. Read the first post: "Do not waste time using older versions or reporting problems with older versions."

So it only happens in combination with one or more other mods. It should be easy now to find out which via binary search. E.g. Disable/Enable groups of mods until you only have the one(s) left that contribute to the problem. A screenshot of the map would be nice. If it also doesn't show object LOD, then the INI [MapMenu] uLockedObjectMapLOD settings mentioned by DoubleYou might be related. However, INI settings starting with "u" can not be "get" via the game console, only "set". Check the game INIs and custom INIs and also if mods that have their own INI files in the data folder first.

LOD4 starts beyond the active cells. The screenshot seems to shows that there is no object LOD whatsoever of any LOD level. It will be more obvious when you disable large references. Post a screenshot of the SkyUI MCM Settings - which means only for that to enable the DynDOLOD plugins again. Do any other tests without them again. Only the meshes/textures form the output. Does the object LOD Level 16 show on the map? Do you use any mods changing INI settings on the fly, like FPS stabilizer?

Test what happens using LODGenx64.exe instead. Move LODGenx64Win.exe or renaming it. Use expert mode and execute LODGen for the worldspace.

Read the first post which log and debug log to upload when making posts. Also upload the LODGen log(s) for the worldspace(s)

As explained on the first post, "do not waste time using older versions or reporting problems with older versions." Since xLODGen seems irrelavent for this issues, you do not need to redo any terrain LOD or mention it at all. If you have questions or problems regarding xLODGen or terrain LOD generation use the xLODGen thread https://stepmodifications.org/forum/topic/13451-xlodgen-terrain-lod-beta-95-for-fnv-fo3-fo4-fo4vr-tes5-sse-tes5vr-enderal-enderalse/ As explained at https://dyndolod.info/Help/Grass-LOD, grass cache needs to be generated for the current load order. The grass cache contains grass model and grass placement information. Changing only the grass textures typically does not require updating the grass cache. See https://dyndolod.info/Help/Grass-LOD#Error-reading-grass-worldspace-x-y-Error-processing-grass-data-CGID-Unable-to-read-beyond-the-end-of-the-stream-System-IO-EndOfStreamException DynDOLOD does not affect grass cache generation. While the log reports issue in plugins that should be fixed, the object LOD generation seems to have worked fine. Does the object LOD Level 16 show on the map? Do you use any mods changing INI settings on the fly, like FPS stabilizer? Doublecheck the object LOD distances in the DynDOLOD SkyUI MCM Settings page. https://dyndolod.info/Help/Mod-Configuration-Menu#Settings https://dyndolod.info/Help/Object-LOD#Settings Make sure the nearest level uses lower distance value compared to the setting for the higher object LOD Levels. Test with the vanilla game and INIs and only the object LOD meshes and textures from the DynDOLOD output. Use the coc or cow console commands from main menu to test with a new game.

Do not install any third party billboards. https://dyndolod.info/Help/Tree-Grass-LOD-Billboards#3rd-Party-LOD-Billboards Use TexGen to generate all billboards. https://dyndolod.info/Help/TexGen#Tree-Grass-LOD-Billboards Make sure all desired billboards are generated. https://dyndolod.info/Help/TexGen-Configuration#Tree-Grass-LOD-Billboards For 3D tree LOD models, make sure they are actually somewhat optimized and just not copies of the full model. See answers for "Object LOD model and full model show at the same time causing texture flicker" at https://dyndolod.info/FAQ

Read the log uploaded. It tells you the DynDOLOD version is 2.97 (from the 2.98 download archive most likely) You can not use the DynDOLOD Resources SE 3 Alpha with DynDOLOD 2.x. https://dyndolod.info/Installation-Instructions Use 7-Zip to unpack the DynDOLOD Standalone archive into a new and empty 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game, Data or any mod manager folders. For example C:\Modding\DynDOLOD\. Make sure to start the DynDOLODx64.exe from the DynDOLOD 3 Alpha installation folder. Thanks for the plugin. Still need to make sure that DynDOLOD does not itself create bugs. The fewer there are the better, also with the workarounds.

The debug log shows OcclusionMaxThreads=2. Set OcclusionMaxThreads=1 However, it should be apparent that something is very wrong when LODGen takes several hours to generate LOD for worldspace. You probably have too hi-res tree 3D LOD models and/or there is just too much grass. I am not entirely sure what the main tree mod is, but make sure to use one that has optimized 3D tree LOD models or just use Billboards instead. In addition, you instructed to generate 3D tree LOD for all 3 object LOD Levels. Use Billboards for the higher LOD levels instead. Regarding grass see https://dyndolod.info/Help/Grass-LOD. Do not use SuperDenseGrass when generating the grass cache and also make sure to "LODGen takes a long time or uses a lot of memory" If the object LOD meshes are getting too huge because of the settings and LOD models, then you need to cut down on that. Also see https://dyndolod.info/FAQ "Long running time or output several GB in file size". If you are worried about problematic plugins/records, pay attention to the log message about deleted reference, HITMEs etc. https://dyndolod.info/Messages Clean every plugin that LOOT tells you to clean, clean every plugin that has deleted references. Quick autoclean is safe when following the instruction. Follow proper modding guide if necessary. Ignoring errors and hoping for the best is never the right option.

I am interested in the papyrus log if there is ever some kind of error/warning messages from the SHESON_DynDOLOD_* scripts. If there are no such messages like in this case it is enough to report that. Typically when the game starts/loads there should only be a couple normal status messages about loading data files etc. but nothing more beyond that.

This mod overwrites large references in its default state. So it triggers the bugs. To counter this, the plugin initially disables every large reference (via an enable parent marker) that has visual flicker (but for example not the large mountainrocks, since their full model and LOD model do not share same 3D space as obviously, you can use the spire 00106C9E to test if the full model and its LOD are both loaded) and adds the bridge as new non large references. It comes with its own object LOD BTO file which has the LOD for bridge added as normal references as well. So by itself the mod appears visually fine and continues to look fine when LOD is generated with DynDOLOD. Flagging the plugin ESM does not help or change that. The bugs caused by the via enable parent initially disabled large refs are visually still not obvious. Once you make the new references large refs, the bugs will become obvious again. If you have the time you could test this: With the plugin flagged as ESM but not large refs generated yet, bring up the marker xx4E43C3 and check its referenced by tab. Remove the enable parent from all listed large references. Set their deleted flag. Clean the plugin afterwards to make proper UDRs out of them. Then generate LOD with DynDOLOD and test if bugs are still triggered by checking the spire 00106C9E. If bugs do not happen anymore, generate large refs and LOD and see if things still work as they should. If bugs still happen, send me the edited plugin for further reviews. It is always possible there is more than one cause. Ignore the entrance 00106e5f of the bridge in the next cell over for now and remember that cell has vanilla bugs or add these two lines back to ..\DynDOLOD\Edit Scripts\DynDOLOD\Rules\DynDOLOD_SSE_skyrimesm_tamriel.patch which add a new non large ref and then "deletes" the large ref. copy2esp=skyrim.esm;00106e5f delete=skyrim.esm;00106e5f It is OK if you decide not to do that test and just see if the large ref workarounds do their job sufficiently without problems.

I did not ask for screenshots, information from or to troubleshoot older versions. Read the first post.

Read the first post which log and debug log to upload when making posts. You did not post an in-game screenshot, so it is unclear if tree/grass LOD is not part of the object LOD meshes or if the entire object LOD is missing. Test with a new game. Test new game without the terrain LOD meshes from xLODGen enabled. They should be irrelevant. (Unrelated: there is no need to check mipmaps for normals, the game only makes use of mipmaps for LOD level 4 diffuse terrain textures), 2k for the map textures seems high, default size can be really low to conserve video memory) Test new game without the DynDOLOD, Occlusion plugins active, just the meshes/textures output. AFAIK no posts are removed, there seems to be a problem with search, though. Older posts seem not to be indexed right now. I suggested to test without the plugins already, never heard back about the result. I also reported that the LOD files you uploaded work perfectly fine here.

Correct, since that downgrading is necessary when not using the workarounds it is not an available option but always enforced. The checkbox is hidden while the workarounds are experimental. If we determine the workarounds are working and safe to use (especially for large load orders) they will become the default option.

Read the first post which log and debug log to upload when making posts. This has most likely nothing to do with Beyond Skyrim - Bruma SE but to do with using an older version of Beyond Reach.

As reported before, the latest optional drivers from AMD still seem to have problems regarding OpenGL. Use Adrenalin 22.5.1 Recommended (WHQL)

There are no different object LOD textures or LOD billboard textures for the different object LOD levels. LOD models/billboards always use the same textures regardless of the object LOD level the model/billboard ends up being used for. All object LOD levels use the same object LOD texture atlas or direct textures.

This may actually be happening because I (somewhat accidentally/intentionally) removed the manual large ref fix patch (delete large ref, add a normal ref instead) for the vanilla winterhold bridge entrance to test the large reference workarounds. See https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds and let me know if doing the WorkaroundLargeReferencesBugs=1 together with the updated scripts gets rid of the flicker without doing anything else. I will still look at the logs and into the case some time tomorrow to determine the actual cause of what triggers the large ref bugs.

Read the first post which debug log to upload when making posts. Explain what you mean by "looks like this" and what we are supposed to look for in the screenshots. Do you mean the LOD snow shader cover? Does it seem too dark or too bright or just too much more? What is important is that the LOD matches the full models as good as possible (which is nearly impossible with snow shaders anyways), so LOD looking a bit different than before is not necessarily bad. The difference is most likely because of ..\textures\landscape\mountains\mountainslabhqlod_n.dds being now updated from the full textures by TexGen. Before it used the texture that I included in the DynDOLOD 3 LOD pack for MM which seems "flatter". Try this: Edit ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_SSE_TexGen_noalpha_majesticmountains_landscapeesm.txt in notepad. Change the 8 lines containing mountainslab02.dds to mountainslab01.dds, then run TexGen sitched object LOD textures generation, install the output, test in game. See if you like that better. No need to run DynDOLOD. The LOD uses the texture directly. Maybe other people using MM (also with other texture mods) can make suggestion which one should be the default.

Read the first post which entire log from the LOD generation session, which entire debug log and bugreport.txt to upload when making posts. Do screenshots in broad day light. Read the answers for "High memory usage / Out of memory" at https://dyndolod.info/FAQ and/or https://dyndolod.info/Help/Occlusion-Data#Out-of-Memory-while-Generating-Occlusion-Data Do not use DynDOLOD output unless the process "completed successfully" as explained at https://dyndolod.info/Generation-Instructions#2-Generate-The-LOD-Mod-with-DynDOLOD Read the already linked explanations of the DynDOLOD documentation which explain how to use the tools, how everything works and how to troubleshoot certain things. For example, the screenshot shows the base form ID of the tree, which you can look up in the TexGen log to if a billboard has been generated and the already mentioned DynDOLOD_SSE_Tree_Report.txt to see which log assets were found and used. Ask specific questions if further help is needed in addition to the linked explanations.

Moved to the DynDOLOD 3 Alpha thread since you mentioned following a third party guide for DynDOLOD 3 Alpha. If you have problems with a third party guide ask its author. Refer to the always up-to-date and comprehensive DynDOLOD documentation https://dyndolod.info Read the first post of the DynDOLOD 3 Alpha thread which log and debug log to upload. When taking videos or screenshots, make them at broad daylight. For things to have LOD they require LOD assets (LOD models and/or billboards for trees) to be installed. Do not install 3rd pary billboard. Use TexGen automatically generates required billboards. See https://dyndolod.info/Help/TexGen-Configuration#Tree-Grass-LOD-Billboards#3rd-Party-LOD-Billboards See https://dyndolod.info/Help/TexGen#Tree-Grass-LOD-Billboards and in particular https://dyndolod.info/Help/TexGen-Configuration#Tree-Grass-LOD-Billboards in case billboards for new trees added by mods are not generated automatically. Also pay attention to the log messages of TexGen. Make sure a tree LOD billboard has been generated for the tree base record. In addition, check if a 3D tree LOD model is shipping/available for the new tree. Look up the base record form id (zero the first two bytes of the plugin load order id) in ..\DynDOLOD3\Logs\DynDOLOD_SSE_Tree_Report.txt Make sure LOD was generated for the current load order. If none of this helps, make a screenshot of the tree with more informative console information. https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots

That looks similar to the first crash log, so refer to what I said in this post: https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-98/?do=findComment&comment=264175. No log and no debug log of the DynDOLOD generation for the current load order. No information if CTD stop with DynDOLOD output is not active. No papyrus logs with debug enabled. DynDOLOD plugin is still being overwritten by other plugins. Together with the quest crash, it seems there might be different causes of CTD and reportedly something more severe happening when enabling papyrus logging. Do all those issues stop when deactivating the DynDOLOD output?

Enabling the papyrus log should not cause CTD. This might indicate a larger issue. if you have issue with a mod list you probably should refer to its author for support. If you have not generated DynDOLOD properly for the current load order, then any troubleshooting here is pretty pointless. It saves the log and debug log when the program is closed. If any records in the DynDOLOD/Occlusion plugin or any of the output files are being overwritten, then something is not right or done correctly/as intended. Regarding that crash log, you can see from first entry of the possible relevant objects and the probable callstack that the CTD seems worldspace and quest related. My first reaction would be to check SVMiscMCMMerged.esp for errors, in particular the mentioned record and test the game without it.

https://dyndolod.info Regardless of which runtime version is used for Skyrim Special Edition, if the Skyrim Anniversary Edition or Anniversary DLC is installed, the game mode is always SSE. https://dyndolod.info/Mods/Skyrim-Special-Edition-Skyrim-Anniversary-Edition#Runtime-Versions Regardless of which runtime version is used for Skyrim Special Edition, if the Skyrim Anniversary Edition or Anniversary DLC is installed, the game mode is always SSE. If you have questions about a third party guide you need ask its authors.

Read the first post which log and debug log to upload when making posts. Since setting to use 3D tree LOD models for object LOD Level 32 obviously means the LOD meshes will have more files and larger file size than using no object LOD Level 32 or billboards in them, I am not what you are really asking. What is happening is what you instruct the LOD generation to do. Also, typically there is only one level 3D tree LOD model available, so Level0|1|2|3 all means the same LOD model is used. If you have problems or questions with instructions from a third party guide, you should ask its authors.