sheson

I guess then you will have to create a new version of the vanilla LOD meshes before generating LOD with TES5LODGen or DynDOLOD ..\Data\meshes\lod\mountains\unique\hhmountainridge01_lod_0.nif ..\Data\meshes\lod\mountains\unique\hhmountainridge01_lod_1.nif ..\Data\meshes\lod\mountains\unique\hhmountainridge01_lod_2.nif or you could set it to use the full model for LOD4 by creating a mesh rule in DynDOLOD Worlds.pas advanced options.

This is the same how it looks with vanilla LOD. If you get close you will see that this is more or less the correct LOD.

Just a hunch, check for stray DynDOLOD related files in MOs overwrite folder and remove them. Make sure to use the latest papyrus scripts . "DynDOLOD can not find master data in None.json" this typically means you are in an interior, or the worldspace you are in is not listed in the DynDOLOD_Worlds.json file that the game loaded. "No data in DynDOLOD.esp for this location" means there is no "Activator" for the current cell in the DynDOLOD.esp that the game loaded.

Yes it works. Based on its changelog "Many fixes for various CTD and performance issues" it is probably a good idea to use the newer version.

That problem would be CTD? You may need to generate from scratch and check load order with LOOT. Double check heap memory usage, if that is OK then check for invalid nif.

I suggest to RTFM about Dark Fantasy Overhaul and the FAQ about the CTD. Yes, if you install mods that add objects or change the landscape you most likely want to update the LOD.

Creating LOD textures with DynDOLOD TexGen.pas is optional and depends on the setup. "If a texture replacer is used, the vanilla LOD textures may not match the looks very well. With DynDOLOD TexGen.pas most but not all LOD textures can be generated from the full textures in the current load order." Since it doesn't take a long time to run you may just want to do it regardless beforehand. ..\Docs\DynDOLOD_TexGen.html contains instructions how to update the LOD atlas texture after DynDOLOD Worlds.pas already generated LOD. You should always copy files into MO mod folders - if the manuals/instructions say data folder it is just because to be valid for any setup. You can physically overwrite all original DynDOLOD files or create a separate new mod folder that virtually overwrites the DynDOLOD files - whatever your preference.

It is occlusion culling being badly programmed. It gets worse when doing anti z-fighting changes to the INIs it seems. There maybe be ways that LOD can be generated that covers this up but it is not on top of my list of things to look into atm.

If DynDOLOD is mod load order ED = 237, then the last entry about the object with load order BA = 186 is a different mod - which was probably removed. In either case such data errors written to papyrus log have no direct connection to CTDs. It did load the save without crashing, did it not? Make sure the DynDOLOD papyrus scripts are all up to date and accessible by the game. Read the DynDOLOD FAQ about real reasons for ILS and CTD. Such data error typically mean either the update procedure for a save game went wrong, or for some reason it did not properly clean all old data. If you save the game the second time without DynDOLOD.esp loaded, check that save game with a save game cleaner for DynDOLOD script instances and remove them. Though I have never seen such a thing happen and it should clear such old data out by itself eventually.

I have not tested, but it should be enabled for both steps and be fine. I suggest to not check "Fake lights child world" (unless you already tested "Fake lights selected world" and are OK with the result) for both runs. If you have time and are willing you could test "Fake lights child world" though and see if it even picks up any - it shouldn't because of ini change.

So the root cause is probably a mod with a record that has the flag set but is in the temporary cell. DynDOLOD tries to update something on the record and the error shows up when creating the overwrite? A record in temporary cells with the flag set works in the game like it is in the persistent cell when I did a quick test once. But CK throws warnings too, so it probably be safer not to do it.

Are you trying to generate LOD with Claralux in the load order? Remove it for now. If not please post/upload ..\TES5Edit\TES5Edit_log.txt

All LOD source textures from the HiRes DLC are included in the DynDOLOD archive since a good while now, so the HiRes DLC BSAs do not matter. If generateing LOD textures from full textures with DynDOLOD TexGen I doubt the resulting shrunk LOD textures would have better quality if HiRes is used over vanilla - unless someone goes for 512x512 LOD textures instead of the default 256x256.

That is what my Memory Blocks Log SKSE plugin is for: to find the max number for the heap setting. There is no not need to reserve much more heap memory than the game needs - reserved memory can not be used for other things in the game.

Some areas are more busy than others and needs more memory. Very vague report. No animated/dynamic LOD at all or just waterfalls and windmills?Did you copy the files from the output folder to the correct game/mod folder? Is the esp and mod activated and not overwritten by anything? What did the DynDOLOD message top left say after loading the game? Check the DynDOLOD MCM pages. Use the updated scripts as they have more information.

Not a word about heap setting and memory blocks log...? Random troubles with saves are often caused by SKSE dll plugins.

I have not yet seen any other cause of ILS other than heap memory being filled. Have you checked with memory blocks log? When I test with just a dozen (mostly house and town) mods and LAL I have no troubles using the camping start option per se. There are about 400 objects around Helgen that get disabled for the intro scene, which are enabled when coming out of the cave when using the normal game start. The camping start option is right in this area and those objects enable right then with all the other things in the game and all mods starting at the same time. It might be a bit too much. You could start the game without DynDOLOD.esp, use camping start option, save, and reload with DynDOLOD.esp enabled see if it makes a difference. In the next version the patcher will ignore the disabled start scene objects and simply assume their LOD to be always active. That will free up some resources in this area and might help the situation.

Thanks, fixed the SKSE link. See this post

If heap memory is not the problem the additional triangles and draw calls from LOD just affect FPS. The CTD probably happens because one/more of those new tree meshes are used for dyanmic LOD / neverfades and there maybe still something awkward about them after copy/paste. I will have a look at the files, but it may be a few days/week. In the meantime for a quick test just don't load the DynDOLOD.esp. If it doesn't CTD then you could set the Grid column for 'trees' to nothing or 'Far Full', so it doesn't use the hybrids for dynamic LOD.

From the manual: "While the switch from FXGlow LOD to a real light is quite noticeable since the two are complete different things, the FXGlow LOD adds a nice simulation of lights lighting up the air and objects behind it. This works well when looking into cities with a load door. Check [x] Fake lights selected world to add FXGlow LOD in place of lights in the world that LOD is generated for. Again, this might not work very well and look off when approaching the light source. Typically, leave this unchecked." Uncheck the option "Fake lights selected world" when generating LOD. To apply different options to select worldspaces, only select the worldspaces you want certain settings for and generate LOD. Then change the settins and select the other worldspaces and generate LOD again. Yes, upload somehwere, or send them to me I might do something with them, but no promises. You could copy paste the 2D trunks from the vanilla 3D LOD trees I did, the textures may be close enough. It is more about the draw calls than triangles. If the texture used needs to be tiled then it can't be atlassed. Typically this is the case with the trunks while the leafs are usually fine.

Correct, I can reproduce broken index nifs here. It should not crash just because it has a bit more LOD to load as long as heap memory is not used up. A next step would be to reduce optimize the meshes by replacing the 3D trunks by 2D flats. May be you want to share the new working static 3D trees?

No correlation. Since you created a LOD version of the full model tree, you need to set LOD4 to static LOD 4. If there is an index error in nifs created with nifskope it most likely has to do with invalid index numbers for strings. When unfolding a NiTriShape its first entry in the block details is usually Name with a Value of TXT .... [x] [x] is a number after the text and needs to a be valid string index defined in the nif header. If you used empty_lod.nif it only has 2 string with the index 0 and 1, so if you see a higher number you need to update the entry to a valid index or add strings to the header list. If you double click TXT you can select/add a string from/to the list. If you double click the string text (it will just show the last entry if the index number is too high) you can enter a new valid index number. Send me one of those nifs and I can double check the cause and also make LODGen.exe more robust versus the error. No correlation. Pop-in is objects appearing from nothing when cells attach. So, it already has been done in the most optimized way possible. The high setting increases the number of static LOD objects shown outside the attached cells from 14k to over 75k in Tamriel. In addition a few thousand dynamic/animated objects are added to dynamic object LOD. Landscape is terrain and large bodies of water, DynDOLOD does tree and object LOD only. The setting "Full model even if LOD is available" is a setting for dynamic LOD to change a LOD model which is displayed outside the attached cells to a full model. Since there is a LOD model shown already there is no pop-in from nothing. The equivalent setting for static LOD is setting LOD4 to "Full model". Using full models for LOD can have a significant performance impact mostly depending on number of textures used and if these textures can be atlassed. Using full models for LOD can lessen the transition effect from LOD to full model. Test for certain large mountains.

That is a file that ships with DynDOLOD. However, you should not install the 'options' folder into Skyrims data folder like this. You need to move the contents and all subfolders of c:\program files (x86)\steam\steamapps\common\skyrim\data\meshes\options\highhrothgarwindowglow\*.* to c:\program files (x86)\steam\steamapps\common\skyrim\data\*.* Repeat for any other files/folders in c:\program files (x86)\steam\steamapps\common\skyrim\data\meshes\options\ if there are any, until \options\ is empty and then remove it. Then generate Tamriel. The error happens because there is 2 /meshes/ folder in the path, which confuses the tools.

LODGen.exe (command prompt window that is started in the background once the texture atlas has been generated) will either report an error or crash for some reason while trying to generate *.bto for Tamriel. See if TES5Edit\LODGen_log.txt shows something like file not found or other errors. If it crashes there should be a "stopped working" pop-up I think so it should not go unnoticed - but I am not sure if that happens on all platforms.

Once DynDOLOD.esp contains masters, LOOT will sort it to be loaded after them. *.esm/*.esp files contain game data but not meshes or textures. However LOD may use meshes, textures from *.bsa files and their load order can change because the matching *.esm,*.esp order changed, LOD may be affected. Since there is no DynDOLOD.bsa and all meshes and textures shipping with DynDOLOD are loose files, the load order priority of DynDOLO.esp does not affect the load order of its resources like meshes or textures. Loose files always win. If you use MO the order of *.esm/*.esp or MOs mod priority may or may not affect load order of *.bsa resources in unconventional ways depending on the use of the managed archive feature. This is probably what you are seeing. Note MO managed archive feature is famously incompatible with tools like TES5Edit, so when generating LOD meshes/textures may be different files compared to when the game loads. Not all textures are baked into the LOD texture atlas and dynamic LOD always uses single files. In any case, if you think there is a problem with LOOT you should post in an official LOOT support thread.