sheson

Read the first post which log, debug log and bugreport.text (if it exists) to upload when making posts. As explained in the first post, always use the latest version and do not waste time using or posting about older versions.

Moved the post to the DynDOLOD Alpha thread. As explained before, use the appropriate threads (and forums) for asking questions. None of this has anything to do with ENB complex grass. https://dyndolod.info/Help/Grass-LOD: Grass LOD generation requires a warmed (current) grass precache from No Grass In Objects for the current load order. The grass cache contains grass model and placement information. Changing only the grass textures typically does not require updating the grass cache - just updating grass LOD billboards with TexGen as explained below. Which means, If settings are changed that affect grass placements - like its density, then the grass cache needs to be updated to account for those changes. Read https://stepmodifications.org/forum/topic/13451-xlodgen-terrain-lod-beta-95-for-fnv-fo3-fo4-fo4vr-tes5-sse-tes5vr-enderal-enderalse/, Terrain-LOD-Readme.txt included in the xLODGen download archive and https://dyndolod.info/Help/xLODGen. You will notice there is no mention about grass, NGIO or grass cache because it is irrelevant for terrain LOD generation. To delete specific files from the load order use the delete feature of the mod manager or the OS.

https://dyndolod.info/Installation-Instructions Refer to the manual of the mod manager how to add executables, for example Mod Organizer, Vortex. https://dyndolod.info/Help/Command-Line-Argument Refer to the manual of the mod manager how to add executables and command line arguments for them: Mod Organizer - Arguments field Vortex - Command Line field No idea what without "x"? refers to. Read the first post which log and debug log and bugreport.txt (if it exists) to upload when making posts. In case you have crapware installed in addition to graphics drivers, try without it to see if things go faster. https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-102/page/187/#comment-254612 and https://dyndolod.info/FAQ "Long running time or output several GB in file size"

mountainslabHQlod.dds is a stitched object LOD texture that is derived from full textures. Just like all the other stitched object LOD textures. So the near mountain LOD will match the full textures in case they are replaced. That does not change anything about the rendered object LOD textures for further away mountains. TexGen does it since Alpha 96. Next Alpha has the update for MM 4.0.

Use the command line arguments as explained at https://dyndolod.info#Skyrim-Special-Edition-GOG-Skyrim-Anniversary-Edition-GOG or https://dyndolod.info/Mods/Skyrim-Special-Edition-GOG-Skyrim-Anniversary-Edition-GOG https://dyndolod.info/Help/TexGen#Rendered-Object-LOD-Textures Note that the list of rendered object LOD textures is not covering all vanilla rendered object LOD textures. It can update the rendered object LOD textures for the walled cities and most structures. However, far away mountains, icebergs and glaciers are not yet covered. If a mod makes changes to these relevant full textures, it should also include updated pre-rendered object LOD textures.

Moved to the DynDOLOD 3 Alpha thread. Just in case you are not using DynDOLOD 3 Alpha - please use that version instead. Read the first post which log and debug log to upload when using DynDOLOD 3 Alpha. Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt Provide a link to the mod. It seems the mod does not adhere to the Bethesda filename convention that there should never be different files with identical filenames in the load order (probably causing filename collisions). It also seems that the mod is not providing required textures. For a test, remove the listed LOD meshes only from the load order. DynDOLOD 3 Alpha can often create texture replacements for LOD models on the fly based on the full model texture replacement - let me know if that works. Still pay attention to log messages about missing textures, though. They obviously need to be solved if those textures are needed...

What does the screenshot show that you haven't already wrote about? Check what the xLODGen option window explains at the bottom: Only worldspaces that have existing lodsettings file "LODSettings\<Worldspace>.lod" (.dlodsettings for Fallout3 and New Vegas) are shown either in the Data folder, or in BSA/BA2 archives. Archives are loaded similar to the game itself - the ones specified in the game ini file and those that match loaded plugins names You can use https://www.nexusmods.com/skyrim/mods/10896 to create the file. I have no idea what "did everything according to the guides" is supposed to mean or refers to.

in case you have crapware installed in addition to graphics drivers, try without it, to see if things go faster. https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-102/page/187/#comment-254612 and https://dyndolod.info/FAQ "Long running time or output several GB in file size" Try this test version https://mega.nz/file/YEJ2jRTC#Y9-R8TIr93UHqcTqnC4rwANPg5eqOYN8EwciWNRMYcM Check if textures\true forest\alnus\new\stitch_8(2)_n.dds is valid texture that can be opened in an image viewer (make sure it supports BC7)

Test with this version https://mega.nz/file/NFhA0BjL#UuCNkT1WUX-yKyJMBvzonMh-SjfANS5cxlHNtK6IXZk Generate all required/desired billboards with TexGen before running DynDOLOD. Remove/hide 3rd party billboards from mods. https://dyndolod.info/Help/Tree-Grass-LOD-Billboards#3rd-Party-LOD-Billboards

The number of threads to read BTO files does not change their heights or the occlusion calculations once the height data has been gathered. An UDR should have a z of exactly -30000. Always interesting in how many ways conventions can be accidentally circumvented. So, this test version https://mega.nz/file/NFhA0BjL#UuCNkT1WUX-yKyJMBvzonMh-SjfANS5cxlHNtK6IXZk looks at XESP opposite player only and will set the original x, y from the master and z to -30000 when it "fixes" what seems to be an UDR large reference in an ESM.

Video shows wrong occlusion data. https://dyndolod.info/FAQ "Rectangular holes in LOD" Generate occlusion for that load order. Make sure the Occlusion.esp is not being overwritten. Make sure there is no ESL flagged plugin with invalid object IDs added afterwards. If that building is supposed to be "deleted" it should have a z of -30,000 and thus be far underground? More Informative Console says the last plugin to change the reference is Skyrim and not DynDOLOD.esp (or The Great City of Winterhold v4.esp).

Of course they are. Fixed.

Set it to 1.0. Execute LODGen to update object LOD

Moved to the DynDOLOD 3 Alpha thread. As the first post explains, posts in this thread when participating in the alpha test. Read the first post which logs and debug logs to upload when making posts. They are created when the tools are closed. From the post, lets assume you are talking about ultra tree LOD with Level0 for LOD Level 4 and you have third party 3D tree LOD models installed that have size/scale issues. Check ..DynDOLOD\Logs\DynDOLOD_SSE_Tree_Report.txt to see which base record uses which 3D tree LOD model. If they are using 3D tree LOD models from Blubbos trees for Daves Trees Addon, make sure to use its latest version 1.3 which is supposed to include 3D tree LOD models I fixed. If you are using that version and none of the 3D tree LOD models are overwritten, then provide the filename of the 3D tree LOD model in question.

This is hardcoded in the game exe. https://dyndolod.info/Help/Snow-Ash-LOD-Shader

Unfortunately you started DynDOLOD again after the successful generation, so the debug log got overwritten. In regards to the CTD: I see you are using Veydogolt. The 3D LOD models are known to be bad and causing CTD. It came up before. In particular the model with NiSwitchNode Name: `TreeAspen03`. If check teh base record as I already wrote in the other post, you will most likely find it uses a 3D tree LOD model from the mod. I created a fixed version for another user: https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-102/?do=findComment&comment=263935 Also pay attention to log messages: https://dyndolod.info/Messages/Textures-Do-Not-Match - You seem to have a mod installed that overwrites DynDOLOD Resources SE imperial wall and fort LOD meshes. You might want to double overwrite orders for best visual results. https://dyndolod.info/Messages/Deleted-Reference - There are plugins in the load order that need to be cleaned.

Read the first post of the xLODGen thread: Only required to be loaded when generating terrain LOD. No harm done when loaded in-game but typically the player can not get close to these areas. There are no effects outside the far away added cells. Or Nexus description: Plugin needs to be active only while generating terrain LOD and should be removed or disabled afterwards. OR: https://dyndolod.info/Help/xLODGen#Requirements Remove or disable the plugins after terrain LOD generation. No harm done if loaded in-game. Typically the player can not get close to these areas. There are no effects outside the far away added cells. In case of questions use the appropriate threads.

TexGen settings affect the textures generated by TexGen. They have no effect how the game or ENB works. DynDOLOD does not change how the game works. DynDOLOD does not change any effects or image spaces, shaders etc. The output file size is not a metric to use for anything. Instead check the logs and reports in the log folder which tell you what is happening and was is being generated. Refer to the DynDOLOD documentation for example https://dyndolod.info/Help/Load-Overwrite-Orders Use the DynDOLOD 3 Alpha thread instead of making off topic posts here. Read the first post before posting.

LOD for grass is part of object LOD. https://dyndolod.info/Help/Grass-LOD The *brightness settings for LODGen are multiplied with the vertex colors of the grass LOD models before they are added to the the object LOD meshes. Static object LOD meshes are placed by the game at specific positions according to their filenames. They can not be manipulated with plugins or papyrus scripts. https://dyndolod.info/How-LOD-Works. The only thing that can load different object LOD meshes for the same positions is Seasons. If that (can) supports hot loading I do not know. Just generate a couple adjacent LOD quads with different *brightness settings if you want to compare more than one at a time.

Read the first post which DynDOLOD log and debug log to upload when making posts. The third party LOD model used by base record xx00A65E in DynDOLOD.esm needs to be fixed in order to be usable with dynamic LOD.

1. It is mainly image based lighting or time settings of day for complex grass. In the end - if you want things to be constant - you have to disable or tone down whatever settings have different effects on the 2 separate things you want to match. 2. *Brightness multipliers are for LODGen. They are multiplied with the vertex colors. Really read https://dyndolod.info/Help/Grass-LOD#Updating, also the last paragraph to only update a specific LOD quad. Take screenshots before and after to compare differences. 3. Static object LOD meshes/textures do not change while in the game. To compare how changes affect the game, find a spot and viewing angle that shows whatever you are manipulating. Set the desired time of day and weather. Make a save. Then keeping loading that save after making changes, make screenshot after loading and things have settled without changing viewing angle.

This is explained since half a decade ago when the mod came out. Because of the missing plugin data and assets DynDOLOD does not generate LOD for the worldspace by default. https://dyndolod.info/Mods/Beyond-Skyrim-Bruma Also, https://dyndolod.info/FAQ "Billboard tree LOD textures cut off mid-way"

Hmm I might add a message for that... and/or create an overwrite with the vanilla objects bounds.

I am not able to reproduce this so far. Double check object bounds are not weird (the 4.01 ESL moss plugin I have seem fine) and that DynDOLOD.esm sets game setting 0xf92 to 1. Make sure no other plugin overwrites it or adds a new record with Editor ID "fLargeRefMinSize. They are also still STAT base records, so object bounds is really the only thing that matters for large refs. MSTTs also need that flag.

Look up the form id of the references in ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_Tamriel.txt (this mist won't be listed obviously) Check if their lines contain "-LargeRef"