sheson

Read the entire document. In "Generate 3D Tree Static LOD" step #7 it explains how to set the tree mesh rule in order to generate 3D tree LOD. Notice how LOD 16 is set to Billboard. Choose only one of the 2 different options. Changing the tree mesh rule or wanting BTOs for object LOD level 32 requires to generate object LOD again so the changes take effect.

RTFM ..DynDOLOD\Docs\trees.ultra\DynDOLOD-Trees.html "Trees on the Map"

I have not had any have such experiences with Skyrm SE, but my time with it and lots of mods is limited anyways. It is still the first time I ever hear the term ILS mentioned with Skyrim SE or about FPS issues after saving, but that might only mean I have just not seen any such discussions yet. Make sure you have default / BethINIs. You could test if the 3D LOD and its increased resource usage plays a role. Generate a second LOD mod with standard tree LOD and leave texture sizes in TexGen/DynDOLOD default, See if you have similar issues or not. If the results are any different, do not use fallback to full model trees when generating 3D tree LOD - though you might now not have such a case anymore now that you use EVT Skyrim version. Terrain LOD Redone is updated terrain LOD meshes and textures. They do not affect standard tree LOD at all, but the meshes are used to optimize object LOD when object is generated, however that should not cause any visual problems either. If stuff disappears when enabling the mod, but is visible when the mod is disabled, my initial idea would be some kind of resource problem. Maybe in conjunction with INI settings. You can either donate to STEP for hosting this forum or to Michael from Gamerpoets for the instructional videos.

You may be expecting LOD for things that have no LOD models or no mesh rules while the existing LOD is working fine, actually. Most if not all mushrooms in Blackreach have no vanilla LOD as far as I can tell. You could add a mesh rule for them Mesh mask = blackreachgiantmush LOD4/LOD8/LOD16 = empty VWD not checked Grid = Near Full Reference = Unchanged Some of those mushrooms have swing animation, if the transition is noticeable, consider adding a slightly different rule for them above the first rule Mesh mask = blackreachgiantmushanim LOD4/LOD8/LOD16 = empty VWD not checked Grid = Near Full Reference = Replace

Here is that updated LODObject script with more debug messages I was mentioning earlier. Just replace the existing SHESON_DynDOLOD_LODObject.pex in scripts. Set "debug":"true" in ..skse\plugins\StorageUtilData\DynDOLOD_Worlds.json and the updated script will also print messages when it disables dynamic LOD objects, which - among other things - is one thing that happens when you enter an interior. Same as before, after a crash check papyrus log if Disable messages are the last line printed to log. If not when can at least rule that out.

I'd rather find the source of the problem and fix it. The best chance to do this is by removing everything else that does not cause a problem and keep only what is causing the problem with a 100% reproducible test case. LOD Meshes/texture is the first thing to hide. I am pretty sure we did that already. They are pre-computed and independent files that just get loaded. There is no extra info for them in any plugins. I mentioned this earlier, you can not "Generate DynDOLOD" (for certain worldspaces) to see if this is about dynamic LOD or not. You can generate a bunch of worldspaces at once, then install output, then run DynDOLOD with different settings for the remaining worldspaces and install that output over the existing one. If you find that not generating a specific worldspace is making a difference, I would test if removing the mod adding that worldspace makes all problems go away at once. Then put that mod back and start removing everything else to see if it is that mod alone or not. However it would be best to only generate one worldspaces and find a 100% reproducible test case in it to test on.

You only need to open a worldspace once in xEdit. You do this by unfolding Skyrim.esm, unfold worldspaces and then unfold BreakReach 0001EE62. It will show you the list of plugins overwriting that worldspace left to right. The most right plugins is the last overwrite. See if any value is different compared to unofficial patch. If possible maybe change load order so that some other plugin is last. Since this is affecting vanilla LOD a well, you might want to search for related discussion about the last plugin.

Keep in mind what I mentioned about only keep what results in the problem 100% repeatably and remove everything else. So keep removing worldspaces, mods, data from esp what doesn't change the problem so in the end you have a hopefully small test case that either reveals what we are dealing with here or that you can maybe send to me.

DynDOLOD generates the LOD just fine as you verified by checking the BTO. There is something preventing it or vanilla LOD from being shown. Check in xEdit if a mod overwrites the BlackReach / DimFrost worldspaces and not properly forwards all data and that their form versions are 44. Compare flags and stuff between the vanilla records and the overwrites. If that doesn't reveal anything, this might also happen if the lodsettings\blackreach.lod is missing or maybe overwritten by another version in a a mod. Load the entire load order into xEdit and open the assets browser with CTRL+F3, the type lodsettings into the filter field, it should show a list of all *.lod files and the containers they are in. For blackreach.lod there should only be the one in Skyrim - Meshes0.bsa, I suppose it should be similar for dimfrost, its lod file should only exist once in a BSA or as a loose file for Wyrmstooth.

What happens if you enter some other interior? This got me thinking, maybe something happens when LODObjects are turned off after you enter an interior. It seems illogical, but you never know with this game. If this keeps happening I would update the debug script to write a line to the log when it disables stuff (while now it only writes a line when it enables). Yeah that seems silly again. If anything The Keep is connected to Tamriel, none of the other worldspace AFAIK. That smells like resource problem again. This is properly weird.

White textures are probably fine in game. If you want to the correct textures in nifskope you would have tell it where to find them, or if they are int the load order start nifskope through MO for example. Despite the textures, it seems the generated LOD is fine and complete. If it doesn't show something else is causing problems. The next test would be to hide the meshes\terrain\Blackreach\Objects\ folder from the DynDOLOD output and keep everything else the same and test if the LOD shows with the vanilla BTO.

Blackreach has not tree and as a result no tree LOD. (unless someone creates billboards for the small bushes) BTR / Terrain LOD is in ..meshes\terrain\[Worldspace]\*.btr BTO / Object LOD is in ..meshes\terrain\[Worldspace]\Objects\*.bto BTT / Tree LOD is in ..meshes\terrain\[Worldspace]\Trees\*.btt We are only interested in Object LOD, as that is what you reported to be missing. My suggestion was to compare the BTO files generated by DynDOLOD to the vanilla BTO files. What I mean by that, compare the object LOD folders and see if you have about the same amount of files. Then open one generated by DynDOLOD in nifskope and compare it to same file name from the vanilla folder. It should be obvious if one is having more or less LOD objects than the other. The 3D LOD trees included in DynDOLOD Resources are for the vanilla trees. If you use a mod like SFO/EVT to change trees they each need their own matching versions of 3D LOD trees or depending on what you set in the DynDOLOD ini billboards or full models will be used for LOD level 4. Last time I checked, Enhanced Vanilla Trees SSE did not yet rename all 3D LOD tree files to the new CRC32 filenames that are used to match full to LOD models (all explained in DynDOLOD_CreateStaticTree.html), which maybe the reason why DynDOLOD uses the full models instead. The CRC32 of the full models changed when the nifs were converted to the new Skyrim SE format. In your case it may be better to use the Skyrim version of EVT that has all 3D LOD trees correctly matched to the full models and the old nifs work just the same in Skyrim SE anyways. That is probably easier than trying to fix the filenames of Skyrim SE EVT without indepth knowledge about that mod.

This makes no sense whatsoever. DynDOLOD does not modify any interior cells. That a some random object base record has a flag set by DynDOLOD is just coincidence. Even if there would be something going with that base record of that torch, that should not affect the base record of cabbages or the references placing a cabbage. Considering that there are 10,000s other users with the same modifications to the base records and who still have cabbages showing, something else must be happening. Random nonsense like this if often the result of something hitting a limit. There once was this iLargeIntRefCount INI setting, to address issues with lot of things in interiors, but I am not sure if it still applies. What happens if you remove the torch overwrite? What is the form id of the torch? OK, we can rule out that those meshes listed there are causing problems, as there are 4 seconds between the last LODObject script entry and the last line of the log. Mesh problems are causing immediate CTD so that there is usually no time for other things to be printed to the log after a mesh was enabled. Darn. That message can happen when you introduce a DynDOLOD to a save game in an exterior. Is that what you did? It is inconsequential. Use save game in interior or new game/coc from main menu for tests. Since this is still all over the place and still seems very random, I would try to remove batches of plugins and their patches/merges. If possible I would start with flora/fauna/alchemy mods that affect all worldspaces, or if easier remove single large new land/quest mods for generally reducing resource usage. However, it maybe be easier to just enable group of mods/plugins from low to high priority. E.g. start with vanilla and all meshes/textures mod that have not plugins. Since the problem is even with low, just generate low for Tamriel and do your usual test. Maybe that reveals something more logical and repeatable. If you somehow manage to make a small load order with the error still present that you could zip (just DynDOLOD.esp and maybe merged.esp if needed) and send to me for further testing. Those patches update the scripts of those mods. If I remember correctly, the Lanterns scripts runs twice a day and the Caranthir Tower scripts only run when the show/hide spells are casted.

Then do that "debug":"true" in ..skse\plugins\StorageUtilData\DynDOLOD_Worlds.json and check papyrus log.

LOD trees "look like this" because of the LOD models/textures or billboards you have installed for those trees. From the log I can see the Aspen trees fall back to the full model for LOD4. The textures appear thinner because full models can set the alpha threshold for alpha channel of the textures, while it is hardcoded to 128 for LOD. The solution is to create specific (hybrid) 3D LOD trees with adjusted LOD textures that use transparency as explained in ..DynDOLOD/Docs/trees.ultra/tools/DynDOLOD_CreateStaticTree.html I see no problem in the log for for Blackreach or Dimfrost either, though I am not sure what you mean by "no LOD in either direction". Check BTO files in meshes\terrain\blackreach\objects\*.bto and compare them to vanilla *.bto files in the BSA files. You could just hide/remove the meshes folders for those two worldspaces and it will fall back to vanilla LOD. I am unaware of ILS being a thing with Skyrim SE and the 64bit engine now handling main memory without problems. If anything I would suspect an incompatibility with certain full models trees being used for LOD, however if you can get to the areas without problems by other means you can rule that out. If you like you could test if smaller LOD atlas textures sizes reduce memory and make a difference. I would just use an appropriate program to shrink the dds files in ..Textures\DynDOLOD\LOD\*.dds and ..Textures\Terrain\Tamriel\Trees\*.dds to really small versions. Other than that, use optimized/decimated 3D LOD trees instead of full models for LOD to reduce size of LOD meshes. But again I have never seen a report yet that memory usage is a problem with Skyrim SE.

TESV.exe can not use more than ~3.1 GB RAM. We all the ENBoost and tools, updates that is still true, those just moved as much stuff possible out of that process. The problem could be from a single record or mesh. Start by comparing base records in Activator, Container, Door, Furniture, Movable Static, Static and Tree Start with new ones only in the esp that end with *_DynDOLOD_LOD. I would start by looking for records that only exist in medium that point to meshes NOT in ..dyndolod/lod/ or ..lod/ If you find such a base record (and you let xEdit build the reference info to show which reference use it), remove all associated references from the worldspaces to see if there is a difference. That depends on your desire to spend more time troubleshooting or more time playing, I wont mind either way :)

2./8. When exactly is that loading crash, when loading starts before some 3D model/trivia is shown, in the middle while the model/trivia still shows or at the end after model/trivia faded away but before you hear any sounds of the world? What happens when you coc whiterun from main menu instead of loading and existing game. 3. Skyrim.esm-related = green overwrites of records form Skryim.esm? 5. tree-related from Skyrim.esm = the overwrite base records in TREE? 7. We should be able to figure it out eventually. Whenever you have a crash while running around in the world, set "debug":"true" in ..skse\plugins\StorageUtilData\DynDOLOD_Worlds.json and see if the very last message(s) in the papyrus log are from SHESON_LODObject(s). While the game is loading the scripts are just setup but not executed and no models are enabled/disabled yet. The crash may be the same cause, but the papyrus messages won't help us at that stage yet. When the last message(s) in papyrus log are not about a LODObject, check with Skyrim Performance monitor if the exe hits over ~3.1GB RAM limit or if VRAM usage is exceeding/near real memory of the graphics card. Here is what to try next: I am assuming you generate Medium on the advanced screen with maybe additional options checked. Next time generate just Low from the main screen. If that doesn't change anything, generate Low from the advanced screen with "Generate DynDOLOD" unchecked. Let me know if that changed something.

This is how the engine works. It has to wait for all objects to load before unloading object LOD, otherwise some objects would briefly disappear. This engine mechanic has nothing to do with DynDOLOD.

If the plugin of a mod is loaded when DynDOLOD starts, its base records and whatnot are still part of the process, regardless if you generate for its world spaces or not. Find a 100% reproducible case and concentrate on it and narrow it down. The goal is to end up with data causing crashes that has everything else removed. What do you mean records are not carried over? When DynDOLOD creates an overwrite record, it uses the data from the last overwrite before it at the time. FAQ: Checking for errors for DynDOLOD.esp with xEdit A: .. \ Record Flags -> are intentional and can be ignored. Now it seems your tests and crash reports are all over the place. Does it crash before, while or after loading the game? Does it crash once you are in the world? If it is all of the above, focus on one of the crashes. Again. If you removed something that eliminated the crash, go back one step and remove something else that does not eliminate the crash until nothing else is left. The log ..DynDOLOD\Logs\DynDOLOD_TES5_log.txt just upload to paste bin or something. Don't wonder, stick to that one crash you can reprodue 100%. If you there more areas, chances are high they are related and if we find the cause of one they all will be fixed. Again then go back one step and remove something else that doesnt remove the crash. It will be quicker that way. If you can load into the world and run around and it then crashes, check the papyrus log after setting "debug":"true" in DynDOLOD_Worlds.json Upload the papyrus log as well if you like.

Yes that is the option to have fewer persistent references that we figured out in the related discussion seem to play a role in some kind of limit. If that is not your issue, you should go back at looking closer at the Solstheim worldspace more thoroughly. Is the opposite true? Are there any problems when you keep only Solstheim in the esp, but remove the other worldspaces? You could also try to remove one big mod and then generate everything again. Does it work then? If all you have to do is remove "some" data somewhere, it would indicate hitting some kind of limit - something else than the persistent references then. Maybe check memory usage with Skyrim Performance monitor. If it is clear cut just a specific worldspace in the esp, then it is more likely some kind of copied data record or resource asset is the problem. Check the load order for errors with xEdit, remove bashed patch when generating LOD. If you like you could upload the log, on the small chance I spot something - despite all the merge patches. Problematic assets like meshes/texture usually only cause problems when they start to show / come into view once the worldspace is loaded, that is usually very reproducible.

This starts to sound like you have just too many mods adding to much stuff https://forums.nexusmods.com/index.php?/topic/4795065-ctd-on-any-save-load-or-new-game-when-over-modding-skyrim-aka-are-you-a-member-of-the-67e-bait-modders-club/ See if changing Temporary=1 in DynDOLOD_TES5.ini helps. Our discussion about this starts around here https://forum.step-project.com/topic/11446-dynamic-distant-objects-lod-dyndolod-218/?p=182733

I suggest to do some simple but effective trouble shooting. Remove as much data as possible so in the end the only thing left is the cause of the error. Start by hiding meshes/texture folder from output. If it still crashes, hide the skse folder. At this point only the esp should be left. See if you can narrow down an area by using "coc" from main menu command prompt. For example, coc whiterun, coc solitudeexterior01, coc windhelmexterior01 etc. The next steps you need to always need to keep at least the last two versions of the esp, the one that still crashes and the new modified one you are testing if it still crashes. If the new one doesn't crash, go back to the one that still crash and remove other data instead: Use xEdit to remove all worldspaces other then Tamriel from the esp and see what happens. If it still crashes remove all temporary cells. If it doesn't crash then go back to the one that crashes and start removing large chunks of temporary cells nowhere near the area first. Then try narrow it down to a single cell. Then remove 50% of the references in the last remaining cell. Test if it works. If it doesn't crash go back one copy and remove the other 50% so that you always have a esp that still crashes until you have the least amount of refereces/data as possible. There is good chance you will able to remove all temporary cells and still have the problem. Then the problem is with a reference in the persistent cell. Always keep the Tamriel_ShesonObject, Tamriel_Minion_* and Tamriel_FirstBorn_* references. Remove chunks of the *_DynDOLOD_LOD and *_DynDOLOD_GLOWLOD references. Just remove 50%. Test if it works. If it doesn't crash go back one copy and remove the other 50% so that you always have a esp that still crashes until you have the least amount of refereces/data as possible. This may sound complicated, but if just remove large chunks of data *not* causing the crash you should be able to narrow it down pretty quick to a single cell or even to a single record. Let me know what you find, or upload the "tiny" esp still having CTD for me to investigate if the cause is not apparent. If you need more details how to use xEdit to remove records let me know.

Any CTD is either memory or nif related. With crash fixes UseOSAllocators=1 working you can usually rule out memory problems causing silent crashes. If crash fixes is not reporting a corrupt nif andall missing nifs have been installed or ruled out, enable extra debug message in papyrus as explained in the DynDOLOD-README.txt. Have a good look at any and all nifs reported in the last same second. You could remove the mentioned references one by from DynDOLOD.esp until CTD stops to narrow down the culprit. Also read this thread, which is a good example how to further troubleshoot CTD in a specific area by removing chunks of references in case all other methods fail (In hindsight the extra debug messages to papyrus log should have pointed us to the full model museum earlier) Sometimes there can be otherwise valid nifs that cause problems when used with the IsFulLOD (neverfade flag) Once you have found a model / mod I can try to verify myself and provide a general fix.

You googled correctly. The included manual also explains such terms. When the loader of xEdit throws this error it means the required master EnhancedLightsandFX.esp is either missing or sorted after ELFXEnhancer.esp. Enable the plugin or sort the load order manually in MO right window or with LOOT. Once the load order is corrected, xEdit, DynDOLOD and TexGen should load all plugins without problem.

Test and fix the load order in xEdit on which TexGen and DynDOLOD are based upon. LODGen does not load any plugins and can not have the same error message.