sheson

3D LOD trees, especially full models with high-res terrain LOD mod will always take a much longer time than generating "normal" LOD.

Great to know. I will push a new version with the update from the test version soon.

Make sure all files in the DynDOLOD standalone installation are from the latest version 2.32, these error indicate older versions of some files are still around. Maybe delete entire folder and just copy everything new form archive.

Are you sure you are using the latest version 2.32? We troubleshooted similar errors here https://forum.step-project.com/topic/12460-dyndolod-error-load-order-messed-up/ and the fixes went into that version. Test if x86 TexGen.exe starts with same problem or works. See if the latest test version from this post changes anything. Simply rename DynDOLOD.exe to TexGen.exe or DynDOLODx64.exe to TexGenx64.exe. Post the log ..DynDOLOD\Logs\TexGen_SSE_log.txt

If a program stops without having any CPU load it is usually because it is waiting for something. That could be either user input or some thread just died internally. Just bring the command prompt windows to the foreground and check what it is doing or what the last message(s) are / check the the log, however if it has problems not all error messages printed to the command prompt window will also make it the log. DynDOLOD will eventually stop waiting for LODGen.exe processes if they take a long time to run, regardless of their state. To generate LOD for the load order, you do not have to check all worlds to start all this work at the same time. Just select one big or a couple small worlds then after everything completed successfully, save and install output like normal. Then with that DynDOLOD.esp in the load order start DynDOLOD.exe and select the next group if worldspaces. Then install the new output overwriting the old output including the old DynDOLOD.esp with the new DynDOLOD.esp. That way you can work around resource problems if there are any.

LODGen.exe closes once it completed. Bring its command prompt window to the front and watch write line after line to the log while they still work. If you are using MO, do not exit DynDOLOD until all spawned LODGen.exe completed, otherwise they may not be able to access files in the virtual data folder anymore and stop prematurely because of file not found errors. Check the log for error messages when "something doesn't work".

Since version 2.xx the DynDOLOD *.pas scripts in the Edit Scripts folder require DynDOLOD.exe (a modified xEdit.exe) to run.

DynDOLOD will span a new LODGen.exe for each worldspace. Eventually they should all complete. Depending on worldspace size a LOD complexity (3D tree LOD with full models especially) can take quite a long time, like half an hour for example. Donate to STEP (for forum) or GamerPoets (video)

Oh crap that link is supposed to go to https://forum.step-project.com/topic/11462-dyndolod-2xx-full-update-post/ Thanks for letting me know

Check the last lines of the DynDOLOD log: [00:21:35.569] Checking D:\SkyWork\DynDOLOD\Logs\LODGen_SSE_Tamriel_log.txt [00:21:35.586] LODGenx64.exe check the logfile for errors D:\SkyWork\DynDOLOD\Logs\LODGen_SSE_Tamriel_log.txt Something went wrong generating object LOD for the worldspaces. That means object LOD is incomplete, thus the missing trees and the vanilla LOD in the distance. Check the mentioned logfiles(s) for error messages. The logs are supposed to end with someting like LOD level 4 total triangles 13214158 reduced to 8745703 Log ended at 16:13:59 Code: 0 In your case there maybe an error message or the log just stops after a Finished LOD level ... line. In that case you need to bring the command prompt window to the front while it is running and see what it says, try to get a screenshot. It is normal that no one created a billboard for TreeAspen04. That is usually because there is no vanilla tree LOD for that particular tree either, it is too small. Currently billboards never have _n.dds textures, because traditional tree LOD does not support/require them. When the billboards are used in object LOD - which requires _n.dds textures - the default normal texture will be used. This just affects lighting behavior of billboards in object LOD. It actually makes them behave identical to traditional tree LOD.

The 2 files are needed by TexGen to create LOD textures for the mod as is intended by mod creator. Failure to install the mod according to its instructions would result in missing LOD textures. The files either need to be in the ..\Skyrim\Data\DynDOLOD\ folder or you can copy them to ..\DynDOLOD\Edit Scripts\DynDOLOD\ folder If they exist in both the ones in ..\Skyrim\Data\DynDOLOD\ are used.

SSELODGen generates traditional tree LOD. If you use DynDOLOD to generate traditional tree LOD (Generate tree LOD checkbox checked), it is the same as SSELODGen. If you followed a 3rd party video to generate ultra tree LOD, then you most likely generated LOD trees in object LOD. As explained above, that is a different type of LOD. Then the fTreeLoadDistance setting has no effect. I suggest to read ..Docs\trees.ultra\DynDOLOD-Trees.html to learn about ultra tree LOD. Also check How LOD works in Skyrim in the manual

Skyrims tree LOD engine, which we sometimes call 2D tree LOD. I use that term to differentiate a LOD tree either using the vanilla tree LOD engine, static object LOD or dynamic LOD. In default DynDOLOD LOD generation all 3 LODs are used for trees as they need it. When the ultra tree LOD options is used, then there is no traditional tree LOD and all LOD trees either use static object LOD or dynamic LOD. Something in the load order could be different. Compare the log entries about the found / not found billboards dds files. See below though. Read the manual section Custom Settings For Specific Mods - Mods that add trees to the same area as child worlds, it explains all that in detail. This looks like the tree LOD distance (fTreeLoadDistance in SkyrimPrefs.ini) is different. You can also set it from DynDOLODs MCM Settings Page. Again, see the manual for information about how to deal with trees in Whiterun. Regarding the mods I can only make general statements: * If a mod just adds more trees, then those tree will get LOD as long as billboards are installed for those type of trees. * If a mod changes trees meshes/textures it requires updated matching billboards for tree LOD to match. Install order of different tree mods require billboards to be in the same order so they keep matching. As explained in the earlier post the log helps with checking each tree / billboard directly in case there is mismatch of files.

This is not an error message, but merely a report for each base records that references a nif file which was not found in the load order. Either nif files exist as loose files in the data folder or in BSA archives. A loose file with the correct path can always be found, but BSA archives need to be loaded by DynDOLOD in order to find assets. So either the nif is missing for real or the BSA archive that contains it was not loaded. xEdit/DynDOLOD load BSAs listed in Skyrim.ini sArchive lines and by their matching plugin filename. LOD was generated successfully despite the report.

SSELODGen traditional tree LOD generation and DynDOLOD traditional tree LOD generation are the same. The only difference is that DynDOLOD can be used to apply rules/changes to tree references or base records before generating traditional tree LOD in order to set XESP Enable Parent or is Full LOD for example. If a set of billboards works for SSELODGen, it also works for DynDOLOD. When traditional tree LOD is generated, a line for each "tree" (TREE base records and other base records with Has Tree LOD flag set) is written to the log. If a billboard for the "tree" does not exist (it is normal that there are no billboards for small flora): If a billlboard was found for a "tree" was found: TreeAspen01 [TREE:0006A9E6] using billboard textures\terrain\lodgen\skyrim.esm\treeaspen01_0006a9e6.dds So if entire types of trees have no LOD or the wrong LOD, check for the billboard message to find out which billboard is missing or needs to be updated.

If you ever have the time, add mods back, one or a couple at a time to see if if you can narrow it down to the culprit.

It would help to know what happens before this error starts. FAQ: Errors while running DynDOLOD.exe/TexGen.exe A: Check the load order for errors with xEdit.exe before generating LOD. Fix all errors. See this for help. Should probably start with the plugin at load order 80 hex, though I am not sure the number is a Form ID. The 'FAILED' messages is probably not from any code in xEdit, DynDOLOD/TexGen. Make sure none of the tools or the game are installed into special windows like Program Files and that UAC and antivirus are not preventing read/write access.

When you tfc everything else still works like the camera is still at the position where you started, especially the pre-computed occlusion. Such graphical artifacts are normal in that state. If you use tcl and walk upwards you get the correct views.

If you run ultra tree LODs with full model fall back it can take an extra long time for LODGen.exe to complete the worldspace because of all the data to process. DynDOLOD just gives up waiting after a while. If you are using MO, do not close DynDOLOD.exe until all LODGen.exe finished. If you bring the LODGen.exe command prompt(s) to the front you can watch it doing its thing. Once it finished, the last couple log lines should be Log ended at ... Code: 0

See this post. That test version seems to fix the error. So there may be no need to even set debug=1 as instructed.

Install DynDOLOD Resources SE. Its installation seems incomplete.

Copy ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5_TexGen_copy_folksteadesp.txt to DynDOLOD_SSE_TexGen_copy_folksteadesp.txt - somehow that file is missing from the last standalone. Will be fixed. Then TexGen should run through without problem. DynDOLOD uses the last overwrite of a record when creating its own overwrite. If data wasn't carried over then it is because when the LOD patch was created, another plugin was the last overwrite in that moment.

Just use the fixed test version if you have this exception. There is not necessarily a problem with any plugin.

It is still the same test version from the other post. If it works for you, then just set debug=0 and everything is working as it supposed to. @Shad0wlife - you are most likely looking at a worldspace reported by another unrelated thread at the end of the log long past where the error actually happened. For this particular case you need to scroll up and find "Update static LOD data for ..." and check the line right above it "Reading Large Reference Data for ..." to find out which worldspace needs to be tested again. In case of the logs uploaded by uncleseano, the exception happens when it is doing "Reading Large Reference Data for DLC2SolstheimWorld "Solstheim" [WRLD:04000800]" and "Update static LOD data for 3083 large references" If the next few lines are empty and then show "Checking for esp overwriting large references causing LOD flicker", it means it did not complete the "Update static LOD data for ..." thread and the exception reported happened right there. In normal operation it should be followed by "Saving objects LOD data to ..."

Make sure none of the plugins has errors in xEdit. Download the test version and simply replace the exe ..DynDOLOD\DynDOLODx64.exe Set Debug=1 in ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini Then run the problematic worldspace - DLC2SolstheimWorld "Solstheim" - only again. The test version should produce a somewhat better error message at the critical point just above the "Checking for esp overwriting large references causing LOD flicker" log entries. If it manages to print a form id check that record for anomalies and/or check the plugin for errors in xEdit, etc. If it is a plugin from a mod available for download let me know. Post the log.