sheson

The flicker normal engine behavior of static object LOD showing at the same time as full models until everything loaded before static LOD for the cell(s) is turned off. The general timings of loading full models and turning LOD4 off should not change by using hybrid trees in LOD8. If you updated DynDLOD/LODGen in between generations then this will account for improved quality of the hybrid trees matching the full models better. Using hybrid trees in LOD8 requires more memory usage. It probably would be better to increase fBlockLevel0Distance to slightly increase the distance of LOD4. Moving one cell can mean a whole area of LOD16 (that is 16x16 cells) in the distance gets replaced by 4 areas of LOD8 (8x8 cells). If the 4 LOD8 BTO are much larger than the 1 LOD16 BTO that got replaced, memory requirements increase. Same for LOD4/8 area switches. You could try to reduce the distance LOD8 shows by lowering fBlockLevel1Distance, LOD4 see above. Maybe purge cell buffer (pcb console) helps, but I doubt it changes what gets saved. You could compile your own SKSE to remove the 1024MB limit (it is just there to protect users from themselves) - or use SSME.

Good to hear. Looking forward to the edits.

This is incredible long even for old style disks I think - though having an SSD spoils ones perception quickly I guess. What were the load times before, though? Do you see disk activity the whole time?

I still have no idea what "long" means. 1 minute? 5 minutes? Have you tried performance monitor yet to plot a graph of memory usage and disk throughput - the question would be if it stalls or actually does something in all that time. Are you using any of the new ENB Thread settings? Is it already taking a long time to load into the prison cell of alternate start? There is something wrong with the setup or a complication with another mod - or this is just a slow machine. I doubt changing [TerrainManager] settings changes anything - though lowering the values will use less heap memory - it will still have to load the same files. You could try narrowing it down to static/tree/dynamic LOD frst: Rename the meshes folder that you copied from the output folder. This will disable both tree and static LOD. If this changed something you could try to rename/disable the different folder for the worlds - but only the one you are trying to load into (Tamriel) should actually have an affect. Only if this actually changed anything would there be any use changing the TerrainManager manager settings. Next disable DynDOLOD.esp but keep the meshes folder, then start and see if it changes anything. You could also try to disable the texture folder while keeping the meshes folder, to test if the atlas textures for tree and static are the cause.

This is the DynDOLOD support thread. You seem to have a problem with your xEdit installation. Most likely the subfolder 'Edit Scripts' is missing.

Even when starting a new game with alternate start? Is there a difference between Skyrim / Solstheim? Raising the ini setting didn't change anything? After saving for the first time and then loading the existing save it also takes long? Define "long" please.

Post the TES5Edit.log of the next generation to pastebin if problem persists

Reinstalling the same thing usually does not fix a problem in a setup. There was one user that had a similar problem, but it was only the first time, loading saves later everything was fine. Use Performance monitor to plot memory/cpu/disk graphs. Maybe it reveals something. Make sure with Memory Blocks Log that the Memory Patch build into SKSE is working correctly. Check that VRAM is plenty available and for example ReservedMemorySizeMb in enblocal is not too high. In Skyrim.ini you could try to raise [interace] uTicksToWait=32 This value influences the loadscreen fps among other things. Try 64, then 16 which most likely will make it take much longer.

As Zilav said, check the xEdit log for lines like TreePineForest02 [TREE:00018A02] using LOD Textures\Terrain\LODGen\Skyrim.esm\TreePineForest02_00018A02.dds Then make sure the billboard dds matches the look of the full model tree.

Great, I will include the updated trees in the next update. There was something weirdly wrong with a texture path.

Please download these updated hybrid LOD trees and replace them in ..Data\Meshes\DynDOLOD\lod\trees\*.nif Then update the static LOD. No need to generate, set Expert=1 in ini, select worldspace, click "Execute LODGen.exe" button Please let me know if this fixes the problem.

Use console tfc to fly really close to such a tree and get a screenshot of what is going on up close. All those trees use the same texture you found - so it is not missing. Maybe try unpacking both dyndolodtreelod.dds and dyndolodtreelod_n.dds from the archive again to make sure they didn't get corrupted somehow.

DynDOLOD uses the billboards you installed. As far as I can tell the STEP texture download includes those billboards with those rocks intentionally. Install different billboards without rocks if you do not like them. Then generate tree LOD again.

There usually is no technical requirement to update existing DynDOLOD.esp or generate LOD from scratch because mods were added afterwards.

working on that since 3 years

You need to stay more on top of things, seriously

Zilav made me. I counted 86k LOD trees. You are like 1 month too late on the issue. You will find more posts from me in the LL thread.

1. You should ask the author of the tree mod. I believe it to be an updated tree atlas for the included tree LOD of the mod. See the manual about splitting the existing tree LOD atlas if billboards are not available for download. 2. DynDOLOD and the tools require no mod manager - they all work with the game. See the manual for manual/nmm instructions/video. 3. See the manual for DynDOLOD TexGen to generate certain LOD textures based on the load order. Beyond those texture you should ask the author of the texture replacer mod.

It would fall back to vanilla BSA or at least report the resource (the texture) missing / not found. So there is something up with that BSA and xEdit, that it can see the texture exists but not extract it for some reason. Probably should try to re-download and re-install the BSA.

Notice that it now goes past the dds that you extracted manually and now is in another segment of the script. Something seems to have an effect on xEdit ability to extract files from the BSAs. Maybe you can find out if those files are all in the same BSA. There maybe something wrong with it. Just insert another MyMessage in line #256 and #262 s := ... MyMessage(slItems[4] + ' to ' + s); if ResourceExists... So you continue to get a list of files

Just change the -o:"c:\... paramater to point to -o:"e:\... Click the gears icon in MO again and change the arguments for xEdit

DynDOLOD TexGen.pas uses the ResoureCopy function from xEdit. xEdit can either not read the source file or can not write to the destination. I am not sure which. The source file should exist, since that is checked right beforehand. It seems odd that it could not write that file while it could write the ones before that. If the file is in a BSA try to extract it so it is available as loose file. Otherwise I am out of ideas. This has to be file system problem one way the other.

The exception should not happen, because just before it tries to ResourceCopy a texture it checks if ResourceExists in the currently loaded resources list (BSA + game folder) So it may be a problem with the destination path - which is the 'output path' + something... Make sure that 'output path' exists, that it is not inside MOs virtual file structure and not inside the game data folder. If you uncomment the MyMessage in line #231 you can see what it is trying to copy to where just before the error.

If you already closed xEdit check TES5Edit_log.txt