sheson

We really don't care what DynDOLOD.exe is doing (creating textures or just waiting for LODgen.exe to finish), since we are discussing a crash of LODGen.exe. If the crash is not 100% reproducible with the exact same settings, then the problem is caused by something else. If you are sure the system is stable, make sure the game is not installed to special windows folders. Make sure DynDOLOD is not installed to special windows folders, game folders or folder under control of MO. If the Execute LODGen.exe button does not become available after changing the world drop down, then the export files in DynDOLOD\Edit Scripts\Export\ from earlier generations are missing. In that case, just hit OK to generate LOD and leave those files for later. Next time the Execute LODgen.exe button will becomes available and you can just run LODGen.exe without anything else. The important part is to generate only one worldspace at a time and find the smallest one that consistently causes a problem with the same settings.

If the problem only happens sometimes for the same setup, then it is likely a hardware problem like CPU overclocking / heat problem, unstable memory timings. Windows UAC or antivius maybe. Only if you can reproduce the same the error every time for the same setup and about the same time in LODGen.exe is there a problem with data processing that I could fix. It can happen that it reads nif data wrong which can cause an out of memory error without it actually being really out of memory. For now I would assume the same thing to happen with the 64 bit version. You either need to start DynDOLOD64 directly without MO (but then it will miss all the mods of course) or use MO2 64 bit (not sure how well that works with Skyrim). Leave that idea for later if we exhausted other the options without a solution. To test if this a reproducible programming problem, use DynDOLOD expert mode by setting Expert=1 in \DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5.ini Then change the world drop down top left to a worldspace to test. Then the "Execute LODGen.exe" button becomes available. Click it to start LODGen.exe directly with the already existing LOD data gathered earlier. For troubleshooting it would be best to find the smallest (least amount of objects) worldspace that can causes this. Keep load order and other INI the same as when the error happened.

When it stopped with the exception and you closed it afterwards it wrote a DynDOLOD log. If it freezes, make a screenshot. Edit DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini with notepad and change FasterBase=0 (maybe also FasterCreate=0 but that shouldn't make a difference) then do the same generation without tree LOD again, see if it goes through. Try this test version

Check all plugins for errors in xEdit and fix them. Post/upload log.

You need to bring the LODGen.exe command prompt window to the front right after it is spawned so you can watch it do its thing before anything happens. See if this LODGen version works better, just replace the files with the same name in DynDOLOD\Edit Script folder. You can ignore the DynDOLOD error, it is meaningless.

Post the DynDOLOD\Logs\DynDOLOD_[TES5|SEE]_log.txt to paste bin or upload somewhere. If no log because of crash, make a screenshot.

See if updating the couple files from the test version from this post works better. Otherwise check that thread from top.

The thing is, a 32 bit application can only use about 3.1GB of memory on consumer versions of Windows. So you will run into trouble sooner than later. I still think LODGen crashed because it encounters a tree nif it doesn't know how to read. It is supposed to produce a nice error message and skip over it, but you never know.

Check the load order for errors in xEdit.exe before generating LOD. Fix all errors. See this for help. DynDOLOD does not work with load orders that have broken plugins.

FAQ: Exception in unit xxx line xxx: FormID [xxx] references a master which is not available in file [xx] xxx.esp Answer: Check the load order for errors in xEdit.exe before generating LOD. Fix all errors. See this video for help. There is also a good chance that involved mods are mentioned right before this error. This type of error came up in the threads quite a few times, search should bring those posts up.

That is correct. Performance you need to test yourself and decide for yourself. However, it will increase the need for heap memory even further. It depends on other mods, but the game will probably be close to the maximum memory limits. Even with maximizing memory patch it has a good chance of ILS/CTD or in case of crash fixes, stop with out of memory messages. Personally, I would just use vanilla trees and tree mods that have optimized 3D LOD trees. That requires a chunk of memory already, but can be handled with some careful tweaking of LOD distances. Full model trees are a magnitude beyond that.

LODGen.exe (LodgeneratorCMD stopped working) probably trips over a full model tree nif it can not read properly. If you bring the LODGen.exe cmd prompt window to the front (it will have an icon is the taskbar) you might see a more meaningful message telling us the problematic nif filename. Screenshot that. Otherwise see if it runs through with TreeFullFallBack=0 as a start to narrow down on possible causes.

Start the game with its launcher once to create the required registry key. As explained in the manual, add -sse as a command line parameter to DynDOLOD.exe/DynDOLODx64.exe or TexGen.exe/TexGenx64.exe to start the tools in Skyrim SE mode.

Install these camp fire meshes (based on the ENB particle patch ones) without particle LOD. That should fix it. Please let me know. The cause is not too many particles but the need to set a flag to prevent objects from "bleeding" into the LOD area. Not setting the flag would prevent this, but then loaded full model fires and LOD fires to show at the same time, causing too bright fires for the time they are both active. There *should* be a INI setting for this just like for decals or envmap fade, but I haven't figured out which one it might be - could be there is none. In any case your any modern graphics card like your 1070 should have no problem with this either way.

If you set "Full Model" then it will use the full models instead of the performance friendlier hybrids. The one thing about grass is that it is a random shader that can be controlled via various INI settings to change its density and variety. However it only works in loaded cells and it follow the fully load terrain height.. So converting grass meshes/textures for the load order with current mods/settings into something performance friendly for LOD requires testing a few different approaches in the LOD area to see if/how they could work. We will have to see if something usable comes out of those tests.

If you installed the EVTs "BillBoards Generator for Enhanced Vanilla Trees" and set up everything for ultra tree LOD including the mesh rule to LOD4 to Static LOD4, then it is using the EVT 3D LOD ultra trees. Unfortunately terrain/object/tree LOD can not cast or receive shadows. That would be something for Boris/ENB - if possible at all. Yes, improved and easy Terrain LOD meshes/textures generation will exist in the near future. It is being worked on. LOD for grass we will see - Zilav and I discussed this a bit how to "fake" it. We may be able to figure out an OK substitute for Skyrim SE (would also work in Skyrim of course, but it may be just to memory/performance intensive)

This could be due to the game being installed to the special Program Files (x86). Try running everything as admin. Make sure anti virus does not interfere. If all fails, install game outside of special windows folders as recommended by every installation guide. Also make sure DynDOLOD is not installed to special OS folder. MO or game folders. Post the DynDOLOD log.

This is probably related to the max number of particles in SkyrimPrefs.INI [Particles] iMaxDesired=750 See if raising this value helps. The DynDOLOD Resources LOD fires/waterfalls in Meshes\DynDOLOD\lod\[clutter|effects|water] are all versions that do not use particles. Double check these files are completely installed. Check that DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_TES5_dyndolodfiles.txt has a list of those files (around 100 files) Install "Giantfires Low" from Resources to replace the LOD for giantfires with a no particle version. It is just 2 meshes you can install at any time without having to redo LOD or anything. If you uninstall make sure to install the original versions from DynDOLOD Resources - Core Files again. It also could be that something else with lots of particles gets picked up for LOD. I just realize there is no similar txt file in cache that shows all nifs used in dynamic LOD. So, if above didn't help yet, post DynDOLOD\Logs\DynDOLOD_TES5_log.txt, I may be able to spot something.

1/ Quote away as much as you need, no worries. 2/ If you plan to release a mod with pre-made DynDOLOD included, see the DynDOLOD_Mod_Authors.html. As it explains it is best to not include any dynamic LOD, so users will have no problems generating their own LOD later. In case of 3D tree LOD, I suggest to leave the Grid column empty for the tree rules. 3/ Just in case, I am always happy to include files into DynDOLOD Resources directly. Otherwise just upload to Nexus and I will add links etc to description/manual.

It is has incorporated and expanded into Enhanced Landscapes

That is great that it is working! Looking forward to the screens. Any plans for uploading those trees as a mod, then let me know so I can add it to the list.

It would help if you specifically state what result you excepted and what happened. "No joy" does not tell me anything really as it could mean any number of things. If you generated with the vanilla hybrids and LOD4/BB/BB, but see the LOD4 3D model all the way to the worlds end then I have to assume the LOD4 distance is set very high in the SkyrimPrefs.INI / DynDOLOD MCM Settings. Verify if the higher LOD level BTO really contain 3D trees instead of billboards. A Meshes\Terrain\Tamriel\Objects\Tamriel.4.*.*.bto should look like this in nifskope A Meshes\Terrain\Tamriel\Objects\Tamriel.16.*.*.bto with Billboards should look like this in nifskope If there indeed are unexpected 3D trees instead of Billboards in the higher LOD level files, make sure there are no mesh rules higher up in the list that accidentally match the mesh path/filename of the full model trees before your intended mesh rule.. Check DynDOLOD\Edit Scripts\Export\LODGen_TES5_Tamriel.txt for the lines for the trees. For example, I tested *lod_0.nif / *lod_1.nif filenames with a LOD4/LOD8/BB mesh rule with a EVT 3D LOD tree and get the expected output in the last 3 tab columns (LOD 4/8/16) for LODGen.exe in the TAB separated export file DynDOLOD\Edit Scripts\Export\LODGen_TES5_Tamriel.txt: 00012E18 00000000 23954.832031 -41983.386719 -152.900131 0.0000 0.0000 0.0000 0.800000 TreePineForest01 00000001 meshes\landscape\trees\srg_treepineforest01.nif meshes\dyndolod\lod\trees\srg_treepineforest01_2148710epassthru_lod_0.nif meshes\dyndolod\lod\trees\srg_treepineforest01_2148710epassthru_lod_1.nif textures\terrain\lodgen\skyrim.esm\srg_treepineforest01_0001306d.dds Are there any log message in DynDOLOD\Logs\LODGen_TES5_Tamriel_log.txt about the replaced trees and their CRC32? If the CRC32 filenames are correct, there should be no mention in the log. If no matching LOD files can be found for updated trees with completely new full model names, then there can be no LOD created for it and consequently there is no need to update the base record. Just make sure all files are named correctly and the rules match as desired. To verify billboard names, generate 2D tree LOD and check the LOD for the found / not found messages.

I am not sure why SkyFalls/Mills causes objects to disappear. Didn't test, especially while Skyrim SE still has game breaking bugs. There should be no need to do anything about the other mods moment. Large references will flicker as reported in the end of log, unless you set the large reference distance to 5. But no others problems should arise.

I suggest to not use Skyrim mods in Skyrim SE. I suggest to remove SkyFalls/Mills before generating LOD - this seem to be the obvious first trouble shoot step, no? Especially after looking at the log. It *should* be fine but probably something else is going on in conjunction with it.

When it is at the end when generating from scratch, then at least all its data will be also in DynDOLOD - with the required LOD flag updates.