sheson

Could you compress and upload all the btos? I like to have a look. That may be quicker. Also include ..\xEdit\Edit Scripts\LODGen_Tamriel.txt. Any file service is fine as long as I do not need a login :) Open ENB overlay with shift+enter, unfold the "profiler" section by clicking on the +. ENB overlay has its own mouse pointer, so you need to use that one instead of the games arrow. Draw Calls is in the section on the screenshot I posted.

Check ..\xEdit\LODGen_log.txt for the LODGEN.exe version number. If it is anyting other than "Skyrim Object LOD Generator v1.0.0" (without any beta) download the latest xEdit and update the static LOD to see if it makes any difference. Do you know if there are any mods in that viewing direction that may add full models to the static LOD? What is the overall file size of all BTOs in that worldspace... which I assume is Tamriel. What is the largest file? Seems to be a good starting point as any - but file size may be deceiving. You could try to use the DynDOLOD MCM "You are here" page to identify certain BTO file names for that area. Open those BTO files in nifskope. See if you can find any with lots of BSMultiBoundNode - more than 10 would be noteworthy already under normal circumstances but look for ones with more than 25. If you use ultra trees it might hit that number but normal LOD shouldn't be anywhere near it. If you unfold any of these and open up the BSLighthingShader and then the BSShaderTextureSet you should mostly only find these textures textures\landscape\mountains\mountainslab02.dds textures\dyndolod\lod\dyndolod_atlas_tamriel.dds textures\dyndolod\lod\dyndolodtreelod.dds Consider resizing textures\dyndolod\lod\dyndolod_atlas_tamriel.dds by half for testing VRAM usage - but I don't believe that to be your problem. There is obviously the chance that the current locations full model objects and stuff puts you one the edge of acceptable draw calls, and the LOD just puts it over the edge. Check how much the number changes in ENB profiler when using tll. I never really checked it in-depth but LOD should probably not add more than 1000, maybe 2000 - if you give me a location and direction / screenshot I could check vanilla / high settings on my end for comparison.

Check draw calls in ENB under "Profiler". Like in the image below you can see that LOD can have millions of triangles but still not cause any FPS drops because LOD is large merged super meshes with only a few draw calls - if static LOD generation went without problems. It is very easy to test if LOD is the straw that breaks the camels back. Turn off all static/tree LOD with tll in console. If this fixed the problem maybe something went wrong with static object LOD generation - typically atlas generation. To test if dynamic neverfades (the objects you still in the distance after toggling static/tree LOD) are a problem, deactivate dynamic LOD in DynDOLODs MCM. Could be a mod adding full model neverfades that needs attention on my part. Check texture memory use while you at it. Check for mods adding a high number of fulll models without any regard for draw calls - gets worse if combined with lighting mods that break appart meshes because of 4 light source limit. Also could be mods with custom resources where meshes are not properly merged/optimized - like a bucket full of coins and each coin being a single mesh. Also could be mods with custom resources where the collision mesh is a 1:1 copy of the full mesh. Reduce shadow distance.

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