sheson

Not sure why anyone would use CK for LOD generation since we have FO4LODGen since quite some time now. If there are new static base records for which object LOD is desired, set Has Distant LOD and define LOD models. Create a data/lodsettings/*.lod file with LodFileGenerator for the new worldspace. Get suitable worldspace bounds from worldrecord. Best to round down lower left cell to a multiple of 32, e.g start at -64, -64 for example. Start xLODGen and generate object and terrain LOD. Typically the map uses object LOD level 16 and terrain LOD level 32, unless change via INI settings.

You can use ENB settings to increase the window brightness. LOD windows that you can can click with open console and have a reference form id in a DynDOLOD plugin are "High" windows that get their brightness from the weather. The others are in static object LOD and you could edit the *glow_lod_*.nif in Meshes\lod\solitude\ folder of DynDOLOD Resources directly in NifSkope and manually increase their Emissive Multiple. Then generate LOD again or use the "Execute LODGen" button in expert mode to simply rerun the object LOD meshes generation only.

You need to ask the mod author what the mod does. Or simple check the snow LOD shader yoursellf in xEdit. https://forum.step-project.com/topic/14930-white-mountain-bug-after-lod-generation https://forum.step-project.com/topic/14577-dark-distant-mountainssnow-lods

Check which BSA or mod contains these textures. Load xEdit and start the Asset Browser with CTRL+F3 to find the sources. Right click to check if the textures can be opened. Re-install the BSA or mod.

The "improved" snow shader has nothing to do with LOD generation. It is applied to what the game things is snow in the loaded cells. If darker/brighter noise.dds has no effect on terrain LOD textures, then the noise.dds is being overwritten by another mod. Applying any brightness/contrast/gamma means that the terrain LOD textures will not match the full terrain textures in the loaded cells. xLODGen uses the currently installed full landscape textures to do the exact same terrain splatting as in the loaded cells. It is either noise.dds and/or INI settings causing discrepancies.

Great

FAQ: Game: Tree LOD: LOD trees show in child worlds / towns A: This is a game engine limitation. A mod added trees into the same area in the parent world. Either disable that mod when generating tree LOD, or add a XESP - Enable Parent to the player reference 0x00000014 to each tree in question. Tree LOD generation skips all trees with enable parents leaving them to be done as static object or dynamic LOD which don't have the limitation. See the section 'Custom Settings For Specific Mods - Mods that add trees to the same area as child worlds' in the ..DynDOLOD\Docs\DynDOLOD_Manual.html for more information and how to use DynDOLOD rules to address the issue.

DynOLOD is the easier and advanced version of xLODGen. xLODGen.exe beta is a versions of xEdit.exe with a beta test of terrain LOD and occlusion generation. xLODGen is a CK replacement LOD generator. DynDOLOD.exe is a modified xLODGen.exe to easily create a LOD patch with improved tree and object LOD for entire load orders. The DynDOLOD package automates dozen of processes and steps that otherwise take months if not years with CK, xEdit, xLODGen, 3D programs like Blender/3DMax, image tools like PhotoShop/Paint etc. I suggest to simply ignore posts or advice that are blatantly wrong or misleading. Such ignorant statements are easily identified by phrases like "xLODGen is easier", "xLODGen does what DynDOLOD does", "DynDOLOD is performance heavy", suggesting to use xLODGen for tree and object LOD generation instead of DynDOLOD or that pre-made LOD included in mods should be used instead of generating it. These people do not understand the immense differences of the programming, code and LOD generation, especially when it comes to ultra tree LOD, texture generation, automatic patching and what a comprehensive LOD mod for the load order means. You use both, obviously, as explained plenty of times: 1. use xLODGen to generate terrain LOD 2. use TexGen/DynDOLOD to generate drastically improved object and tree LOD 3. use xLODGen to create Occlusion.esp - or create data with DynDOLOD in step 2.

Nothing else to it. A program would have to be maliciously exploit things to cause BOSD. Search for the BSOD code together with the chipset/CPU/GPU combination. Look at overclocking guides for the Motherboard/CPU combination. Good guides/discussions have a list of issues and their causes/solutions.

The video is set to private. If you have problems with third party guides you need to check with the author(s) of the guide or use their support forum/discord etc. If you have problems with LOD resources from third party mods, then you need to check with the author(s) of the mod. FAQ: Game: Tree LOD: LOD trees do not match close-up full model trees A: If the billboard tree LOD seems overly dark or bright, use the tree LOD brightness setting on the advanced options to account for lighting changes made by ENBs or weather mods. A: Doublecheck billboards and billboard load order. Open console, click on full model tree to get form id like 000185C7. Lookup this FormID top left in xEdit, bringing up the tree reference in the right pane. Find the form id of the 'NAME - Base', like TreeAspen01 [TREE:0006A9E6]. Search in Textures\Terrain\LODGen\ subfolders for files with that number, like TreeAspen01_0006A9E6.dds and TreeAspen01_0006A9E6.txt. Replace files with correct versions. A: The DynDOLOD log will print a detailed list for each tree which billboard (and 3D LOD model if applicable) it is using. Use the base form id like 0006A9E6 to easily find the entries in the log. A: Find better matching billboards for the tree mods or create them. See this video The brightness setting only affects billboards, obviously. 3D tree LOD models should have no noticeable brightness differences if they use the same leaf meshes and textures as their full models. If they use dedicated LOD textures, then you would need to edit them directly. Edit: Video works now. It seems to show well matching 3D tree LOD. The difference is that LOD does not cast or receive shadows. Shorten the shadow distance or use the ENB effect Distant Shadow that applies shadows to LOD, which can help lessen the effect.

Read the installation instructions in the included manual. By default the tools start in Skyrim mode, which is the same as adding the -tes5 command line parameter. Add -sse as a command line parameter to DynDOLOD.exe/DynDOLODx64.exe or TexGen.exe/TexGenx64.exe to start the tools in Skyrim Special Edition mode. Add -tes5vr as a command line parameter to DynDOLOD.exe/DynDOLODx64.exe or TexGen.exe/TexGenx64.exe to start the tools in Skyrim VR mode. Add -enderal as a command line parameter to DynDOLOD.exe/DynDOLODx64.exe or TexGen.exe/TexGenx64.exe to start the tools in Enderal mode in case the Steam version is used. See DynDOLOD-Shortcut.txt for help.

Check log lines above the exception for additional hints. Check the FAQ and search official forum http://forum.step-pr...ndolod-support/ for those errors. 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.

FAQ: Game: Tree LOD: LOD trees show in child worlds / towns A: This is a game engine limitation. A mod added trees into the same area in the parent world. Either disable that mod when generating tree LOD, or add a XESP - Enable Parent to the player reference 0x00000014 to each tree in question. Tree LOD generation skips all trees with enable parents leaving them to be done as static object or dynamic LOD which don't have the limitation. See the section 'Custom Settings For Specific Mods - Mods that add trees to the same area as child worlds' in the ..DynDOLOD\Docs\DynDOLOD_Manual.html for more information and how to use DynDOLOD rules to address the issue. FAQ: Game: Tree LOD: LOD trees show in loaded cells A: Make sure all plugins with ITM or deleted references are cleaned. See https://tes5edit.github.io/docs/7-mod-cleaning-and-error-checking.html#ThreeEasyStepstocleanMods A: If the load order / priority of plugins adding or changing tree references was changed, generate tree LOD again so it matches the new load order.

That means the bashed patch broken and should not be used in the game. Generate a valid patch with a newer Wrye Bash version.

This is addressed on the first post and discussed in the xLODGen thread. If brightness/contrast/gamma are left alone, then the LOD textures match the full textures in the loaded cells as long as the "improved" snow shader from Skyrim Special Editon is disabled. That awful shader does not apply to LOD. Use a "neutral" noise.dds that does not darken or brighten the LOD textures. Moving around xLODGen output does not solve anything. Either you use the generated LOD textures or you don't.

The glow changes based on daytime and weather are not controlled by DynDOLOD. They happen because the glow LOD window is added as a reference and has a XEMI record linked. None of your problems make any sense right now. Make a new profile with no mods other than SKSE, PapyrusUtil, Unofficial Patch, SkyUI. Generate LOD for Tamriel. See what happens then.

The "DynDOLOD successfully initialized" only shows once per worldspace. Deactivating/activating from the DynDOLOD SkyUI MCM is a different function. Does that solve the issue permanently? Is this with Papyrus Util or do you use DynDOLOD DLL? Open skse\plugins\StorageUtilData\DynDOLOD_Tamriel_Objects.json in notepad and search for "226780", you should find a line that looks like "226780":["","1","1","","","829162","Skyrim.esm","-1","-1","1","1","WinterholdExtTower01:10","829162","Skyrim.esm"], Copy and paste yours.

The EditorID of the reference starts with the pluginname_formid, Skyrimesm_0CA6EA in the screenshot. That means the source reference for which this LOD object was added is 000CA6EA Check if this reference is being overwritten by other plugins. Check if its base record that defines the model is overwritten by other plugins.

It is not set deliberately. This setting works since years for everybody.

Check the EditorID to find out for which plugin + form id the windows are added for. Check which plugins overwrite the original plugin and form id

OK, now do the 5th suggestion from my first post. Get form ID of windows, look up in xEdit, check EditorID to find out for which plugin + form id the windows are added for. Check which plugins overwrite that.

Is there a question? See the troubleshooting steps already given earlier in this thread. Especially the part about large references and the MCM setting. Did you test with a new game, for example from main menu with coc whiterun in console? Let me know if I need to specifically ask for more information to help with troubleshooting?

This focuses on textures, only. In that regard the statements are correct. Terrain LOD textures also should be generated again if a mod makes changes to the terrain texture layers on the LAND record. If only textures changed there is no need to re-run all of DynDOLOD after updating the object LOD textures with TexGen. Just updating the texture atlases in expert mode is enough as explained in the TexGen manual. I wouldn't stress myself trying to figure what a mod changes. If a particular LOD type does not match anymore, generate it for the new load order. If it is terrain LOD, then update terrain LOD. If it is object LOD textures, run TexGen and update the object LOD atlas, etc.

So the older version of the mod had LAND records. Simply check what might be up with those LAND records in xEdit. Use CK to add some LAND records with terrain height data and maybe paint some landscape texture on them.

If you search the forum as suggested by the log messages you would find these https://forum.step-project.com/topic/15011-assertion-failure-wbimplementationpas-line-14062 https://forum.step-project.com/topic/14697-assertion-failure-wbimplementationpas-line-14062 Caused by a broken Bashed Patch. Use a newer Wrye Bash version to create a valid patch that is not corrupted.