sheson

Editing the z position of the reference in xEdit is pretty straight forward. Open DynDOLDO.esp in xEdit and enter DLC2SolstheimWorld_Underside_DynDOLOD_NOLOD into the Editor ID field top left and hit Enter to open up the record. Then in the right window scroll to the bottom and unfold Data - Position/Rotation, double or right click edit the Position Z entry and set something like -1200.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts. This is the terrain underside peeking through. Try to increase LOD distance in DynDOLOD SkyUI MCM Settings. Try to generate better quality terrain LOD for Solstheim with xLODGen. Try to generate better quality terrain underside and/or use higher height setting for Solstheim. You can change the z-height manually afterwards with xEdit by editing the reference. You get its form ID by clicking the mesh when console is open.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making problem reports. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make use full screenshots of the full model with more informative console, both with and without DynDOLOD enabled. Generating a LOD mod for Skyrim LE with DynDOLOD does not create a DynDOLOD.esm. Do not install output generated for other game versions. Make sure the output folder is empty before generating a new LOD patch from scratch.

Make sure to use a driver only installation and/or terminate crapware with task manager before testing. For example: amdfendrsr.exe atiesrxx.exe atieclxx.exe RadeonSoftware.exe cncmd.exe Use this test version https://mega.nz/file/MZA2VDoT#1KgtOQa-L74pnMVRCCF1uTsh4ixwTZ08Ezbbc4haBVg, upload new bugreport.txt, log and debug log.

Assuming the grass LOD billboards match the full grasses properly, https://dyndolod.info/Help/Grass-LOD#Settings In case the grass LOD brightness or color seems off (it might depend on weathers or ENB settings), try different Direct/Ambient settings for grass LOD billboards in TexGen. In addition or alternatively change the GrassBrightnessTop*/ComplexGrassBrightnessTop* and GrassBrightnessBottom*/ComplexGrassBrightnessBottom* settings in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini - those settings help if the color tone is off. Especially the image based lighting effect from ENB has a big impact on the brightness and color tone of the grass LOD. Additional complex grass lighting and time of day settings will obviously not apply to object LOD, as they are separate meshes and shaders. Do not use them so full grass and grass LOD match better for all weathers/times.

If a model does not exist in the load order, its bounds can not be calculated. In case of the vanilla grass model DLC02VolcanicAshRocks01.nif defined by GRAS record 0401771E, the model does indeed not exist. The record is not being used by anything (Referenced by tab in xEdit), so it is an orphaned record and the message can be ignored. That might be also the case for whatever grass mod you are using. Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen log and debug log to upload when making posts. I suggest to verify the updated esp with xEdit, that the objects bounds are actually updated and not -1 or 0 anymore for the GRAS records in question.

I do not provide support for other tools or generic modding support. Ask questions about how to use CK wherever people discuss or help with it. Make use of https://ck.uesp.net/wiki/index.php?title=Landing_page In CK load / set whatever grass plugin to edit as active. In the Object Window tree view select WorldObjects / Grass, mark all grasses in the list, right click, Recalc Bounds, save.

GLDebug=1 does more debugging and is not supposed to make a difference how things work, so no change is expected. Download this test version https://mega.nz/file/pQIW3BjB#lUFjXiTiHkI-yu1yfow_e0X5E2VrHkD_lp5tER_GrEA and upload new bugreport.txt, log and debug log.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log, debug log and papyrus log to upload when making posts. The message states a fact. The correct SKSE version is not installed or working properly. https://dyndolod.info/FAQ#DynDOLOD-requires-SKSE Install the correct version of SKSE and start SKSE from the MO2 drop down.

No logs were uploaded Read the first post and/or the readme.txt included in the download archive how to set the -o command line argument properly. https://dyndolod.info/Help/xLODGen#Installation MO2 only puts new files into the Overwrite folder, while existing files are being replaced in their mod folder. Read and follow the instructions. They exist for a reason.

Use latest DynDOLOD 3 Alpha instead of DynDOLOD 2.x Do not install the game into special Windows folders like Program Files x86. Follow a proper modding guide. Pay attention to obvious error messages about broken plugins: Error loading module information for "C:\Program Files (x86)\Steam\steamapps\common\Skyrim Special Edition\Data\AI Overhaul - Relationship Dialogue Overhaul Patch.esp": [Exception] Expected header signature TES4, found in file "C:\Program Files (x86)\Steam\steamapps\common\Skyrim Special Edition\Data\AI Overhaul - Relationship Dialogue Overhaul Patch.esp" Error loading module information for "C:\Program Files (x86)\Steam\steamapps\common\Skyrim Special Edition\Data\imp_helm_Immersive_Armors.esp": [Exception] Expected header signature TES4, found in file "C:\Program Files (x86)\Steam\steamapps\common\Skyrim Special Edition\Data\imp_helm_Immersive_Armors.esp" Error loading module information for "C:\Program Files (x86)\Steam\steamapps\common\Skyrim Special Edition\Data\NPCSelectForMCM.esp": [Exception] Expected header signature TES4, found in file "C:\Program Files (x86)\Steam\steamapps\common\Skyrim Special Edition\Data\NPCSelectForMCM.esp" Error loading module information for "C:\Program Files (x86)\Steam\steamapps\common\Skyrim Special Edition\Data\_Fuse00_ArmorRedWarrior.esp": [Exception] Expected header signature TES4, found in file "C:\Program Files (x86)\Steam\steamapps\common\Skyrim Special Edition\Data\_Fuse00_ArmorRedWarrior.esp" Error loading module information for "C:\Program Files (x86)\Steam\steamapps\common\Skyrim Special Edition\Data\_Fuse00_ArmorRogue.esp": [Exception] Expected header signature TES4, found in file "C:\Program Files (x86)\Steam\steamapps\common\Skyrim Special Edition\Data\_Fuse00_ArmorRogue.esp" Use xEdit to check those plugins. Replace by valid versions.

Either only use properly made mods, update the object bounds with CK or create the config file to force creation. With correct object bounds billboards will be created for large enough and above water grass only. If you force billboards, it is up to you to decide. Use preview or open generated billboard in image viewer.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs how to zip and upload large log files to a file service/ https://dyndolod.info/Help/Grass-LOD#Not-all-grass-types-have-LOD-grass-LOD-billboards Check that TexGen generates grass LOD billboards for all desired grass types. Plugins from mods often forget to set object bounds on base records, which filters them out from automatic tree/grass LOD billboard generation. See TexGen Configuration for further details. You can see in the log that only handful of grass billboards were generated for verdant. https://dyndolod.info/Help/Grass-LOD#No-Grass-LOD-Check-List Make sure TexGen is generating grass LOD billboards for grasses by checking its log ..\DynDOLOD\Logs\TexGen_SSE_log.txt. Pay attention to error messages and fix them. Double-check the object bounds of the GRAS records in the plugins as explained above https://www.nexusmods.com/skyrimspecialedition/mods/2296?tab=posts The bounds need to be recalculated again for this to work with grass LOD generation. I know the sticky says 1.8 was but you will still get false on every billboard generation in the txt file like the other comment sticky in here stated. I recalculated it "again" and it works now. So instead of guessing what shouldn't be false a simple ck recalculate bounds is all that's needed. https://dyndolod.info/Help/Object-Bounds In case the object bounds are not set properly in a plugin, the Creation Kit Object Window has a right click context menu entry 'Recalc Bounds' to update them.

In addition add GLDebug=1 under [DynDOLOD] in E:\Mod Tools\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini Remove old logs and bugreport.txt, run again, upload new logs and bugreport.txt.

The archive you uploaded include the log and debug in addition to the real time log all with the same timestamp. The log and debug log are saved when the tools shut down properly via exit or clicking the X top right once. The debug log and real time log seem to show that the tool was interrupted while Texconv converted textures. See https://dyndolod.info/FAQ#TexGen-DynDOLOD-stuck-while-creating-textures, test the suggested INI settings one by one. Let me know if/which one made a difference.

Download these test LOD meshes for a test https://mega.nz/file/tUpygK7T#HyzleyPqXWPLmS6b8tKiRUlvjkSr3Z9WUCjJTdRnc9M Let them overwrite the ones in DynDOLOD Resources. Start DynDOLOD in export mode and execute LOD to update the object LOD meshes of Tamriel. https://dyndolod.info/Help/Expert-Mode In case there still something too bright, make a screenshot of full model with more informative console and upload log, debug log and object_report.

You accidentally uploaded the terrain LOD *.btr file instead of the object LOD *.bto. You identified 3 different types of waterfalls being affected before: xx89C163 FXWaterFallBodySlope_NW.nif xx89C164 FXWaterFallBodyTall02_NW.nif xx89C165 FXWaterFallBodyTall.NW.nif Let me know which one is still affected and which is now OK.

Disabling mods/plugins is a troubleshooting step and not a fix. Disabling something that actually affects grass for generating the grass cache or grass LOD means that those changes are then not reflected in the grass cache and grass LOD. The problem is caused by following an outdated third party guide, which instructs to rename the *.cgid files to *.gid for grass cache generation. That means that in the case there is no grass cache file generated for a cell and grass cache fixes also does not include an empty replacement for those coordinates, the grass LOD generation loads and reports the broken vanilla gid file. The game would load it, too and crash. Read https://dyndolod.info/Help/Grass-LOD To use the *.CGID grass cache files in other runtime versions, use Grass Cache Helper NG. Do not disable any mods or plugins. Do not rename any *.cgid to *.gid Do not use grass cache fixes. Use Grass Cache Helper NG instead. Then it does not matter that there are no *.cgid files for certain cells. LOD generation and the game will work, and full and grass LOD will match the actual load order.

When you installed DynDOLOD Standalone 3 Alpha 156, did you unpack it over an existing installation? https://dyndolod.info/Installation-Instructions Use 7-Zip to unpack the DynDOLOD Standalone archive into a new and empty 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game, Data or any mod manager folders. For example C:\Modding\DynDOLOD\. Do that and generate LOD for the test profile from scratch. Check if there is anything different in regards to the waterfalls. Upload new debug log, object_report and the bto if the problem persists.

The logs just seem to show the generation being started and then being forcefully closed right after. https://dyndolod.info/FAQ#BSOD-Blue-Screen-Of-Death BSOD are a hardware, BIOS setting, OS or driver problem. For example, problems with overclocking, memory timings, cooling, unstable power supply etc. Searching the Internet for the BSOD code should help troubleshooting.

Use the x64 version and instead of renaming add -sse to Arguments field in MO2. For example: -sse -o:"c:\OutputPath\" You can rename xLODGenx64.exe to SSELODGenx64.exe or SEELODGen.exe. The x64 part of the file name is for humans.

The next alpha version will not have issues a diffuse being used as normal map. Also it will improve the blending a bit when creating the average background color in case the transparent parts of LOD textures are black, so the black outline will be not as strong. However, the 0 alpha threshold will still result in too thick leaves.

The black outline exists in the diffuse LOD textures shipping with the mod. The reason this is so obvious is because some LOD models set an alpha threshold of 0 instead of the default 128 and so the diffuse textures are adjusted when they are added to the texture atlas to reflect that setting. https://dyndolod.info/Help/3D-Tree-LOD-Model Note that LOD only has binary alpha with a fixed threshold of 128. DynDOLOD reads the alpha threshold from the NiAlphaProperty from the models used for LOD and adjusts the textures before it is added to the atlas texture. The final result in game may be to thick or thin like certain objects seem to be missing or transparency looks off. Try adjusting the NiAlphaProperty in the 3D LOD model. Previewing the LOD models in NifSkope shows the black outlines as well - it should look very similar to what you see in game. Changing the threshold from 0 to 128 of the affected LOD models should mitigate that.

This happens because of the s3dtrees_treepineforestsnow03_lod_[0|1|2].nif 3D tree LOD models setting a wrong normal map texture. That adversely affects pre-processing of the diffuse texture that is used by the other LOD model. From your log: [00:19] <Warning: Filename textures\landscape\s3dtrees_and_plants\lod4\treepineforestsnow04_lod_0.dds does not adhere to file naming conventions. Used by meshes\landscape\trees\s3dtrees\s3dtrees_treepineforestsnow03_lod_0.nif S3DTrees NextGenerationForests.esp TreePineForestSnow03 [TREE:0005C070]> [00:19] <Warning: Filename textures\landscape\s3dtrees_and_plants\lod4\treepineforestsnow04_lod_0.dds does not adhere to file naming conventions. Used by meshes\landscape\trees\s3dtrees\s3dtrees_treepineforestsnow03_lod_1.nif S3DTrees NextGenerationForests.esp TreePineForestSnow03 [TREE:0005C070]> [00:19] <Warning: Filename textures\landscape\s3dtrees_and_plants\lod4\treepineforestsnow04_lod_0.dds does not adhere to file naming conventions. Used by meshes\landscape\trees\s3dtrees\s3dtrees_treepineforestsnow03_lod_2.nif S3DTrees NextGenerationForests.esp TreePineForestSnow03 [TREE:0005C070]> If you fix the paths to treepineforestsnow03_LOD_0_n.dds as intended the LOD for the other trees won't fade to black.

The video does not show how things look with the underside disabled via console. Check with xEdit that the z position value of the reference for the underside is the negative value of the drop down after generating from scratch. If it is, change the value further down manually. You know from the manual that the HD snow LOD shader uses the vertex color alpha channel. These LOD models do not have vertex colors with alpha channel, so the engine assumes 1.0. Instead of changing the brightness of terrain LOD textures, I suggest to adjust overlays textures being used for the map. Otherwise you are going to see brightness change between the LOD levels when running around the game, unless you push LOD Level 32 terrain LOD past the max render distance.