sheson

If you have any CTDs make sure to double check heap memory usage with Memory Blocks Log. The typical increase from 256 to 512 (768 in SKSE.ini) might just not be enough anymore. Object LOD including roads doesn't have a brightness settings as it usually does not suffer from the lighting problems the typical tree LOD has. Maybe you are using a texture replacer that changes the look of the roads? Then use DynDOLOD TexGen.pas. You can update the LOD textures without having to redo the whole process. See ..\Docs\DynDOLOD_TexGen.html in the download archive for instructions. If after that you still want to remove roads, click to advanced and scroll down the mesh rules until you find a rule \roadchunk | Static LOD4 | Static LOD8 | Static LOD16 | Yes | [empty] | Unchanged and change it to \road | [empty] | [empty] | [empty] | Yes | [empty] | Unchanged Then update existing LOD or generate it from scratch. If no LODGen.exe command prompt window got stuck eternally in the background it is a good sign. Check ..\TES5Edit\LODGen_log.txt for "error" or "not found" messages though to be sure.

See DynDOLOD_Manual.html section "Overwrite Orders"

Looks correct. Post a screenshot of the bottom with the last lines of the command prompt window.

The json files are in the skse folder skse\plugins\StorageUtilData\DynDOLOD_Tamriel.json for example. The meshes/skse/texture folder that were created to the output folder when LOD was generated need to be all copied to a new mod folder (call it DynDOLOD output). It should be after the DynDOLOD source folder with the esp and the meshes/scripts/textures folder installed from archive. If this is still a new installation there should be no need to do the save game routine as long as you keep using save from before DynDOLOD. Now, if it keeps telling that it can not read data from a file, it usually means it can not find the json file because it is not there. Check the overwrite folder of MO for any old versions of those files that do not belong there. Check the MCM information page, it will probably also say n/a for the missing file(s). A directory is a folder. The game directory/folder is ..\Skyrim\Data\ Since you use a mod manager the meaning of "game directory" its equivalent means for the mod manager. For MO it would be a mod folder. File in sync means, all files in meshes/skse/textures should be from the same generation or update process run by DynDOLOD Worlds.pas. Specifically, esp needs to match the json files. There will be a different message if the json files can be read but do not match the esp.

Check the the FAQ or search this thread... If one of the tools involved crashes, it means whatever that tool was doing didn't complete successfully. Did you update to the latest xEdit , which also includes the latest LODGen.exe (LODGeneratorCMD) 1.0 beta 4? Check ..\TES5Edit\LODGen_log.txt for "Skyrim Object LOD Generator v1.0.0 beta 4" and then for errors. However if it crashes it wont be able to write something meaningful to the log most of the times. If this doesn't help, post a screenshot or copy and paste the error message from the command prompt window. From the FAQ Q: LODGen.exe crash A: Make sure to get the latest version included in the required xEdit download. If problem persists post an error report (screenshot or copy text) to https://forum.step-project.com/topic/5011-dynamic-distant-objects-lod-dyndolod Q: Tree LOD / TES5Edit\TES5Edit_log.txt: and similar A: Ignore, any messages about missing files for shrubs, fern, bushes etc. are normal. It only generates billboard LOD for trees. Some world spaces do not have any trees. Q: A: Ignore. A handful of trees can not have traditional tree LOD for technical reasons and will be done as static LOD. Static LOD uses the normal _n.dds textures, but LOD tree billboards do not have one so the flat replacement is used, just as traditional tree LOD does.

The buttons load the same default rules regardless of wizard or advanced. If you change rules in advanced, do not click low, medium or high again. It replaces your changes by the defaults again. If you went back to wizard, same thing. Any customization would be lost. Low, Medium, High are just 3 different "defaults".

See post with updated beta scripts above though. I was able to cut down some use of strings. Seems like a good idea either way. Post to official SKSE thread on Beth forum usually gets their attention. I would think this issue must have come up before already, it seems like a prominent limitation the more I look at it.

You have the latest LODGen.exe 1.0 beta 4 from the FO4Edit download? I just created a new set of trunks for hybrid tree having to use old version. Based on this info, I went ahead and updated the papyrus scripts to use as few strings as possible. Comparing the total amount of strings before/after in the save files after a speedrun shows a couple thousand less strings in the table actually. I figured every bit helps for busy load orders... To update an existing save, first deactivate DynDOLOD from MCM, wait for deactivation message, go into interior, check MCM DynDOLOD is still deactivated, save, exit game. Disable DynDOLOD .esp and remove old scripts. Start game, load last save, wait a bit, save again. Install the updated BETA papyrus scripts, enable DynDOLOD.esp, start game, load the last save, go outside. DynDOLOD should initialize by itself.

For this user it happens in nifskope and the game. @some_random_guy could you try the latest nifskope 2 pre alpha 4? If I remember correctly newer nifskope uses OpenGL now to render things and not DirectX anymore. Not sure exactly when the switch happened.

The z-fighting will has its reason beyond the meshes. We both have the same source meshes and consequently should have the same merge result in the LOD bto file. If I had to hazard a guess it is related to any of OS, DirectX, graphics drivers / hardware. But I have no idea why or how to address the issue.

Combining meshes into one large supermesh is the whole point of generating LOD... You could disable use of the entire group of meshes by 2 mesh rules: Mesh = tundrastream Mesh = tundrapond LOD4/LOD8/LOD16/Grid = empty, VWD = checked, Reference = Unchanged Or delete Meshes\lod\tundra\tundra*.nif (also in subfolders) Or better, edit those source meshes in nifksope and remove the dirt patches by highlighting their NiTriShape and right click, Block, Remove Branch, then save. However, you might want to spend some time investigating why there is the z-fighting to begin width. I have no idea why it is so bad for you. I have zero z-fighting, see:

Since DynDOLOD is lightyears ahead of any other mod because it is a patcher use the settings to fix it yourself by removing the objects for example. In my nifskope 2 pre alpha 4 and in my game these tundra stream LOD objects do not flicker. NVIDIA card, still using driver 361.75.

I looked into this and can not verify. Can you show me a save which for some reason has several 10,000 unique strings from DynDOLOD? I counted about 80 unique strings for DynDOLOD in my save. It doesn't matter how many script instances use the same unique string. It is a reference table... The limit does exists and other mods may go crazy on unique strings, but there is nothing I can do about them. If there is any issue there is always a way to work around. DynDOLOD is already using external json data files for a reason :) The guys from SKSE could probably write a wrapper around the whole thing.

Interesting, I was speculating about a 16bit overflow at some point. I will look into this. It is called z-fighting. Why care about z-fighting in nifskope? Any trouble with those in the game?

LOD32 is unused. FO4 is the first game to use it. The map usually uses LOD16, unless ini setting overwrites it, Same function, DynDOLOD just presets some options. I can do this because the DynDOLOD archive also has updated/fixed vanilla meshes and LOD textures, so the settings are for them. You can change some of those settings in DynDOLOD World.pas editing the code at the top. The final size and dimensions of the atlas depend on the number of textures for a worldspace. It usually grows in full width first, then height. While it can support 8192x8192, for DynDOLOD I set max of 4096x4096. The one important value is the max title size, which is the drop down in advanced/expert. The LOD atlas is one single texture while the game uses hundreds more textures at then same time. It dimension and size are not that important - unless you have an old graphics card with no VRAM to speak of. The important part is, that LOD combines separate meshes into one merged mesh that uses the same shader/texture and thus reducing draw calls dramatically. That the braziers or whatever other bowls holding the fires are missing is fully intentional on my part :) It is a simple find string in string function. "brazier" will find all meshes that have that word in their path or filename.

If you are not using Climates Of Tamriel - Winter Edition you do not need to install the patch for Climates Of Tamriel - Winter Edition.

Fixing that, output folder of course. will be fixed next version Correct under (4) From: If the selected world is Tamriel the process also scans the 5 major towns for references that now have LOD added by (2) and (3). To: If the selected world is Tamriel, the process also scans the 5 major towns for references that now have LOD added by (2) and (3). The child worlds to scan are listed for each parent worldspace in DynDOLOD_TES5.ini. See this changelog (1.0 changelog is still worked on while it is beta) - also see the FO4LODGen thread. The FO4 export file uses new features.... Mostly it just does things magically as Zilav and I need it to do, so it works across all the supported games. Some voodoo with the firstborns is involved, too. I just do not have the time to start and maintain a wiki. I would contribute if pointed to one whenever clarification is needed.

OMG someone reads the DynDOLOD_reference, which I haven't updated since August last year. Thanks for helping out. Below are some updates to clear up the wording. From: The scanning process will only work completely reliable when the BTT files were generated with the same load order. To: The scanning process will only work correctly if the BTT files were generated for the same load order. Insert: (0) If tree LOD generation is checked, start TES5LODGen for Tree LOD to create tree LOD in data/meshes/terrain/[world]/trees/*.btt and tree LOD atlas texture in data/textures/terrain/[world]/trees/[world]treelod.dds. Step 0 so I don't have to update the order for now ;) Back in the day tree LOD had to be generated separately... how far we come From: This way it is easy to 'overwrite' meshes with. To: This way it is easy to 'overwrite' meshes by making sure they are found later in the scanning process depending on the folder structure. The scanning order of folder is set in the DynDOLOD_TES5.ini From: Since the whole data/meshes folder is scanned, mod authors that use new assets can provide lod.nifs with their mod and they are automatically discovered and used. Obviously they need to exist as real files, so they need to be unpacked from the BSAs. To: Since the whole data/meshes folder is scanned - BSA loaded by xEdit, then loose files - mod authors that use new assets can provide lod.nifs with their mod and they are automatically discovered and used. This was from a time LODGen.exe could not read files from BSA. From: In addition some of the default mesh rules set the 'out of order' rules. To: In addition the low, medium and high mesh rules cover the vanilla names breaking the default rules. Proably for performance reasons vanilla LOD sometimes uses higher level meshes in lower levels - mountain trims for example. Check the 'Use original LOD assigments' to keep the vanilla levels. From: Click the 'Exceute LODGen.exe' button lower left. Note that the *.bto output path is hardcoded into the export file. To: In expert mode (set Expert=1 in DynDOLOD_TES5.ini), click the 'Exceute LODGen.exe' button lower left. At that time there only was one mode. It is its own worldspace with almost no objects past the walls. It is not a Tamriel child world. I guess because of performance reasons. From: the mesh rules filters determine how a reference should be processed. Also the LOD tree list is used to filter out all references to trees that already have LOD. To: The mesh rules determine how a reference should be processed. Also the LOD tree list is used to filter out all references to trees that already have LOD. Yes, it should always be the 'mesh rules' doing something From: If a reference has the neverfade flag set, the flag will be unset. In case the rerference can static LOD for TES5LODGen it is added to the export file for LODGen.exe. If the reference is a dynamic object it will be added as a DynDOLOD object. To: If a reference has the neverfade flag set, the flag will be unset. In case the reference can be done as static LOD for TES5LODGen, it is added to the export file for LODGen.exe. If the reference is a dynamic object it will be added as a DynDOLOD object. The word "Reference" is defined in DynDOLOD_Manual.html. The rest depends on the settings found in the file (like DynDOLOD_TES5_manual_refr_Tamriel.txt) it talks about. The file also explains what the data is for. Beyond that find out more by actually looking at the documented code (create.pas - search for "process DynDOLOD_manual_refr.txt") using this data and how it adds it to the esp and the json. I would truly love yo detail everything in more detail - but things change all the time to what I currently need to make things work and there is only so much time to document things. The comments in the code will have to do - but do ask if they don't. It is the other way around, so I updated like this: From: If scanning the world in (4) found any child town references a new reference for either TES5LODGen or DynDOLOD will be added into the world. To: If scanning the world in (4) found any new references with LOD in a child town, a new reference for either TES5LODGen or DynDOLOD will be added into the parent world. From: The DynDOLOD base elements for these references were already added in (6). To: The DynDOLOD base elements for these references were already added in (4). I should really add some of new features/details like how TES5LODGen now creates a texture atlas etc. Some day... For now I am leaving presets and rule folders alone. This may be addressed in a possible future standalone version without the scripting limitations.

I will check if this error can be caught and fixed at runtime. In the meantime just remove the empty worldspace An_SancreselWorld "Sancresel" [WRLD:0A08D671] from AnnaNPCs.esp

Yes, this is normal. I think the problem shows more with water mods that uses very different "local" waters while all LOD for a worldspace can only be of one type.

Actually this already happens for water1024.nif for medium/high. However the water in the screenshot is not a reference with a baselement / mesh. It is water defined in the cell record, which uses WATR records directly. The LOD for this water generated in the terrain LOD *btr files. LOD water always just uses one WATR defined for a worldspace. Technically the LOD water planes in the *btr files can be disabled (or just removed from LOD4 only) and replaced by dynamic LOD water meshes with animation and everything. Somebody would have to create those meshes so they match the look and reflection of the WATR though. They need to ACTI records with a nif and a link to the WATR. It could be as simple as creating a 4096x4096 version. I have yet not looked into that. In theory they could be done in static LOD as well - but I think that would be worse to the existing LOD water. I find that between Skyrim.ini settings and ENB water settings I never have THAT problem shown in the screenshot. May have to do with the fact that currently I do not use a water mod. I might get to this problem some day - after trees and ice/glaciers - when I do more testing about the bad occlusion culling that turns off large patches of the ocean from terrain LOD.

Ha, will update the ini filenames. Thanks. Yes, the vanilla trees are covered. However the _Static LOD8 *_flat_2.nif are replaced by the newer and better 'Billboards" instead. I just left the flat nifs in there in case something goes wrong with the automatic Billboard creation and for fallback. Eventually I want to get rid of them. Current fallback for TreeFullFallBack=0 will use whatever billboard, lod.nif, lod_0.nif, lod_1.nif, lod_2.nif is found first. So use Static LOD4, Billboard, Billboard. It is the better option and makes sure that LOD 8/16 always use the installed billboards and already match non-vanilla trees. I am currently working on a process to createnew 3D statics with 2D trunks for non vanilla trees for Static LOD4 as much a possible automatically.

The papyrus log will not report missing nifs. They are reported to TES5Edit_log.txt when DynDOLOD Worls.pas is generating LOD. You can enable debugging in game for DynDLOD as explained in the readme.txt. It will list all used nifs in the location and if an invalid or missing nif is causing the CTD it will be one of the last lines in papyrus log. Test with a new game, coc whiterun.

Yeah, current versions of LODGen are 1.0 beta x 0.8 is quite old

You need to check SKSE.ini heap memory settings with Memory Blocks Log not in Papyrus. Check ../TES5Edit/TES5Edit_log.txt for messages like 'Missing model "meshes\..\*.nif" - ignoring * [sTAT:xxxxxxxx] for dynamic LOD'