sheson

There is really no such thing as a cache other then for the native xEdit reference building. The shiftz, width, depth and height values are directly read from the billboard txt. The bottom vertex z should be reference position z + ShiftZ and the vertex top z should be then just the height value added. If that is not the case then the height is still randomly changed for some reason and I would like to know. Delete the Billboard dds and txt files that you do not want to be used from the data folder. LOD is only generated for trees for which LOD assets exists.

That is by design to counter the butterfly effect. A billboard only really matches a tree when you happen to look at its exact front (and maybe its back). For all other angles and especially the side views the single billboard texture typically does not match very well. Combine that with the normal use case that billboards in object LOD are usually for LOD level 8/16 which is further away. So, to counter the butterfly effect the exact height value is used for the top vertices of the plane that matches front/back and the height of the plane for the side view is randomly bit higher. In case an external billboard NIF is used, the height is randomly varied for all planes if there is only the typical billboard texture available. If multiple billboard textures (mentioned in Docs/trees.ultra/DynDOLOD-Trees.html) are defined for the different planes, then the exact height value is used for all planes of the external billboard NIF. It should be enough to copy a billboard texture from SomeTree01_12345678.dds to SomeTree01_12345678_1.dds and SomeTree01_12345678_2.dds to not have the height changed for external 2x2 billboards NIF. Of course SomeTree01_12345678_2.dds should be the side view for best results. Results will be even better if this is combined with normal map textures. See Docs\trees.ultra\examples\2-textures-billboard-example\textures\terrain\LODGen\skyrim.esm\ folder

In Windows display settings temporarily change the size of text apps and other items to 100%. Or find the program in Windows Explorer, right-click to open its properties, switch to compatibility tab and check Override high DPI scaling. A reboot might be required. Use DynDOLOD 3 Alpha. Without the -sse command line argument the tools run in TES5 Skyrim mode. The tools need to be started from the mod manager otherwise it will not find any of the installed mods.

You have tested this with vanilla LOD and it happens as well. Then this is is z-fighting. 2 different shapes with different textures occupy close to the same 3D space and once far away enough the z-buffer precision is too low to keep them separate. A solution would be to edit the vanilla LOD models of the windows / the LOD BGSM files and set the Decal and Decal No Fade flags on the Windows that should be in front. In case BGSM need to be edited its best to make a new filename to make sure only the Windows use the flags. For decals flags to work, create an options file "FO4LODGen_Fallout4_Commonwealth_Options.txt" in the Edit Scripts folder and add a line with UseDecalFlag=True.

While DynDOLOD and TexGen are a modified xEdit and all command line arguments work, setting some are pointless though. For example the ones related to editing plugins. When setting paths they need to be valid. The output path needs to start with a drive letter. Set the output path in the TexGen/DynDOLOD options as explained in the included instructions.

The error message is in plain English: Exception in unit userscript line 709: Unable to create directory Set a valid output path in the command line or better, do not copy and paste unnecessary arguments and follow the instructions in the included manual instead and just set -sse and nothing else. "C:\Modding\DynDOLOD\TexGenx64.exe" -IKnowWhatImDoing -AllowMasterFilesEdit -o:"Path\to output\folder" -SSE

The xEdit plugin loader tells us that the group HAZD exists twice in Skyrim.esm. Nothing needs to be done about it. The "Requirements" section in the included manual lists what is required to generate tree and object LOD with DynDOLOD. The descriptions of third party mods should explain what they do.

xEdit/xLOGen/DynDOLOD/TexGen use the data path from the Windows Registry. The launcher started from Steam has no problems updating it correctly. The obvious thing to do would be too look up the Registry key with regedit and edit or maybe delete it manually before running the launcher and make sure it is not blocked by some crapware. HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Bethesda Softworks\Skyrim Special Edition

1. See Load/Overwrite Orders in the DynDOLOD manual. The load order of third party mods depends entirely in their instructions and your preference what mod should win in case they modify the same things. 2. + 3. No. LOD resources are often used directly in the game. 4. No. INI settings do not influence LOD generation. 5. Not sure why anyone would want to use an insane number like 21 for that buggy feature. It makes no sense. Higher values require exponential more resources/performance and the large reference bugs and other visual oddities (decals for example) will be more visible. None of these questions seem to directly relate to the reason you gave why you are asking these questions: Object LOD uses two snow LOD material object shaders. They are applied onto the object LOD in game.Shaders do not affect object LOD generation or vice versa object LOD generation does not change the shader records.Whatever plugins modify 00050372 SnowLODMaterial or 0006AE38 SnowLODMaterialHD are responsible how snow covered mountain rocks look in the distance. LOD mountain rocks without snow use the same LOD models/textures as the one with the snow, meaning any other issues would be visible on all LOD mountain rocks.

Yes that is normal. It is the "API" or expected format version of the data files/scripts.

There is nothing really in the DynDOLOD patches archive that could possible cause that error message.

Exception in unit userscript line 350: Can not copy RockCliff08_HeavySN [sTAT:0002ED7A] from BDS - MM Patch.esp into DynDOLOD.esp Assertion failure (C:\Delphi\projects\DynDOLOD\wbImplementation.pas, line 5767) Check log lines above the exception for additional hints. Check the FAQ and search official forum http://forum.step-project.com/forum/101-shesons-dyndolod-support/ for those errors. If problem persists, post error report with entire contents (not just the last couple lines) of ..\DynDOLOD\bugreport.txt and ..\DynDOLOD\logs\DynDOLOD_SSE_log.txt to official forum http://forum.step-project.com/forum/101-shesons-dyndolod-support/ Checking the FAQ finds this: FAQ: DynDOLOD.exe: Can not copy xxxx from xxxx.esp into xxx.esp A: Often caused by a broken bashed patch. Use a newer Wrye Bash version to create the patch or do not use the merge patches option. A: There is a plugin in the load order with errors. Check the load order for errors with xEdit.exe before generating LOD. Fix all errors. See this video for help. Searching the forum finds this: https://forum.step-project.com/topic/14342-load-order-fileid-xx-can-not-be-mapped-to-file-fileid-for-file-dyndolodesp Seems likely that there is a problem with BDS - MM Patch.esp, though it might be caused by other plugins needing cleaning or error fixing.

Post some useful information if you want an answer or help troubleshooting. Useful information would be for example the two logs of the generations and which xLODGen version you are talking about.

Just check which plugins are the last to overwrite the cell records. DynDOLOD SkyUI MCM You Are Here tells you the coordinates of which cell you are in. In xEdit use the cell browser CTRL+ALT+F to look them up.

Are you sure the screenshot shows the border between loaded cells and LOD? It looks like 2 adjacent fully loaded cells and no LOD being involved at all. If the problem goes away by removing a plugin, then it means that one plugin makes changes to the heightdata of a cell but not of the adjacent cell.

This is a simple file check. It fails because of one of these reasons: Do not install DynDOLOD Resources intended for Skyrim. Install DynDOLOD Resources SE Core Files instead. Do not modify files from DynDOLOD Resources SE. Do not change any of the installed DynDOLOD Resource Core Files. Verify the archive or files were not corrupted. If the archive did not download completely, not all files are installed. It is possible this happens without any error messages.

The DynDOLOD log contains 4 generations and you also uploaded a bugreport. However the last generation shows that DynDOLOD plugins were loaded. I hope those are not from the failed generation beforehand. Do not use any files from the output folder when the LOD generation process did not complete successfully as mentioned in the manual. Fix this error. Exception in unit userscript line 249: Load order FileID [37] can not be mapped to file FileID for file "DynDOLOD.esp"Check log lines above the exception for additional hints. Check the FAQ and search official forum http://forum.step-project.com/forum/101-shesons-dyndolod-support/ for those errors. Check the FAQ and search the forum for it. It is most likely caused by a broken Bashed Patch. If the LOD generation runs through without the Bashed Patch in the load order, it means the Bash Patch is broken and should not be used. Use a newer Wrye Bash version to create a new working patch. Delete the output folder and remove old files from the load order before generate LOD from scratch without errors. You can also delete old logs and bugreports as they are now irrelevant. In case CTD still happens then, set "debug":"true" in skse\plugins\StorageUtilData\DynDOLOD_Worlds.json as explained in the DynDOLOD-README.txt (explained in the FAQ answer about CTD) so the papyrus log can be used to troubleshoot for missing invalid NIF. It might provide additional clues. Assuming you do not have old files from failed generations in the load order, the .Net Crash log tells us you need to look up the reference form id 11012C9F in xEdit. That form id will change if there are new plugins generated. Look up whatever form ids are reported. Post a screenshot of it and also a screenshot of its base record.

What mod manager would have such an option not to install all files from an archive and why would it be disabled by default? In any case, there is no readme.txt in DynDOLOD Resources. There are 4 billboard txt files. Any mod manager that does not install required files sounds like a misconfigured mod manager.

You have installed a mod that replaces the single object LOD texture textures\lod\wrbuildingslod02.dds which seem to have made the thatch look red. Remove/Hide the single object LOD texture so it uses the vanilla version again when generating the LOD texture atlas. To update only the LOD texture atlas, use expert mode as explained in DynDOLOD_TexGen.html "Update Texture Atlas"

Make sure the system/hardware is stable, for example overclocking/memory times and drivers are up to date. Check in task manager if DynDOLOD uses CPU. Just wait then. It may be just busy creating textures atlasses. Make a screenshot of the message window where it gets stuck.

That video seems to show the already mentioned large reference bugs. See FAQ Q: Game: Out of place objects / floating objects / flickering full models. The last answer.

The log shows that advice was ignored. Set a dedicated output folder with -o. Then install output like a mod with the mod manager. Consider creating a BA2 out of the meshes and textures. It is normal that there is no options file. The image doesn't really show much with that dark foggy weather. The best way to show LOD is from an elevated position in clear weather at day light. The LOD meshes can be opened in NifSkope. Check they show what is expected. If the generated LOD is fine, then there is probably an issue with the load order. Reinstalling just resets INI and makes all game files vanilla and remove 3rd party files. Proper modding practice and troubleshooting can do the same more easily and less destructive. Make sure LOD distances are fine in the INI settings.

Test if it runs through without the Bashed Patch. If it does, it means the Bashed Patch is broken and should not be used. Generate a new Bashed Patch with a more recent version of Wrye Bash.

Adding command line parameters is a basic OS function. In Windows it can be done via Shortcuts. Better would be to use a proper mod manager, like MO, though.

I suggest to not install the game or any tools to a special Windows folder like Program Files x86 and to not not install programs to special Windows folder like Desktop. When starting xLODGen set a dedicated output folder with -o as explained on the first post. Reading the log tells you exactly what happens: Terrain LOD meshes generate fine. Terrain LOD textures are skipped: Object LOD generates fine. Refer to the Terrain-LOD-Readme.txt included in the download archive: If terrain LOD textures already exist in the output folder, their generation will be skipped. This can be used to continue generating terrain LOD textures for large worldspaces in case there was a problem like not enough space left on a drive. Simply restart with the same options. Otherwise move or selectively delete old terrain LOD textures before generating new ones. Take note of the skipping messages. If the diffuse or normal texture for a higher LOD level already exists, then all lower LOD levels that are covered by the higher LOD level are skipped as well. So in order to re-generate a LOD level 4 texture, it is not enough to just delete the LOD level 4 files for the diffuse and normal texture, the higher LOD level diffuse and normal textures files need to be deleted as well.