sheson

Default values are for the vanilla game and Vanilla Complex Grasses for ENB and no additional ENB effects for complex grass and no other affects, especially image based lighting. Different time of day values for certain ENB effects can mean that things will match only at certain times but not on others, same with different weathers. If grass LOD is too bright lower ComplexGrassBrightnessTop* and ComplexGrassBrightnessBottom*. If color tone is off, change the RGB channels individually. https://dyndolod.info/Help/Grass-LOD#Settings There procedures are trial and error. https://dyndolod.info/Help/Grass-LOD#Updating

Here is why I ask. Just checking 00009A6A alone, since it only has 2 plugins overwriting. Majestic Mountains only changes the LAND record, while the unofficial patch only overwrites TREEs. So neither cause the bugs, unless you have different versions doing something else. If I checked correctly, Skyrim.esm adds 5 REFR that are large references, 0001A370, 0001A480, 0001A482, 0001A483, 000C8C06. If nothing adds new large references and does not overwrite those, then check if anything overwrites the base records of those 5 references. 0003ACCD, 0003925C, 00042A88, 0003ABE3, 00077773

Did you modify any of those plugins or use older version than what is currently available on Nexus?

you made sure the go away with uLargeRefLODGridSize=5? Provide a list of all plugins overwriting their cells 000095DE, 00009A8A and 00009A6A. You will notice that those cells (coordinates) are not reported as having bugs right now.

Try this version https://mega.nz/file/RVhn2DAD#jIZ5ezOiKl96m26leZvvydq9S0q8s85TYIfGUBnOPaA RealTimeLog=1 under [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini actually.

Test with this version https://mega.nz/file/xEpHmR6J#yljvdAF6QlNWd_ZcDY9kV4RJwhYSnidUYdFKgE1huOM to see if there is any difference. Add RealTimeLog=1 in the DynDOLOD.ini in case it gets stuck. Check if CPU is 0 in task manager.

Try this test version https://mega.nz/file/AIR0gJQY#2Kf-ciaOXHQyqyv_TX7cSdOXnOWTd5iRpD_ej4fvMPw, which should which that.

Edit ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini in notepad and add LockTexconv=1 under [DynDOLOD]. See if that makes a difference. If not, it could mean a problem with antivir or unstable CPU/memory. Disable antivir / add exception for all exe involved.

Also upload the bugreport.txt as explained on the first post.

Read the first post which log and bugreport.txt to also upload when making posts.

Updating existing DynDOLOD output is always possible. https://dyndolod.info/Updating Do not rename any output files / do not invent instructions. However, I suggest to let me first investigate and probably fix the problem for the next version as there is no reason for that delay when it generates on-demand textures / it should not try to generate any if source textures are missing. Edit: Use Alpha-102 for that.

Great! Regarding the flat normalmaps, IIRC this came up before. For example the Enderal\landscape\Tropical\Vegetation\Trunk01.nif has 0 0 0 tangents/bitangents. You can also see in NifSkope, that it does not react to direct light, only ambient. Fix those with NifSkope and they should have nice normal maps generated.

Use the x64 version. If that does not help add TextureCache=10 to ..\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_ENDERAL.ini The trunks seemingly having flat normal map seems to be another issue I am looking into.

I have no problem with generating the stitched object LOD texture tropicalfloor which had the error in your log. If it always the same texture, check if it is valid / upload it. If it is not always the same texture, see if setting RenderThreads=1 helps. Do not install the game into special Windows folders like Program Files x86 to avoid issues with OS file permissions, UAC, anti vir etc.

Upload the entire log and the entire debug log.

Moved to the DynDOLOD 3 alpha thread. The cause is explained in the message. "Broken Tamriel terrain LOD meshes detected." and "Some terrain LOD meshes generated by Oscape have bugs resulting in severe visual issues" - You have installed a mod that contains broken terrain LOD meshes. How to resolve it is explained in the message. "Permamently remove the broken terrain LOD meshes or use xLODGen to generate terrain LOD meshes to overwrite the broken terrain LOD meshes" - Remove the broken terran LOD meshes or generate valid ones with xLODGen. As explained in the first post, click the link "Click on this link for additional explanations and help for this message" to open additional help. https://dyndolod.info/Generation-Instructions#Prerequisites Typically generate terrain LOD meshes and textures with xLODGen before generating the LOD mod with DynDOLOD, as the terrain LOD meshes are used to optimize object LOD meshes.

Try to close the program normally (not kill it) so the log and debug log files are created and upload them. For next run add RealTimeLog=1 under [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini Check if the program still uses CPU. Check with task manager if there are any LODGen/Texconv processes still running in the background it might be waiting for. Check if it runs through without enabling the worldspace BSHeartland.

Read the first post which log and debug log to upload when making posts. Make sure the OS, UAC, anti vir or some other 3rd party crap ware is not preventing TexConv from running. Install latest Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017, 2019, and 2022

Read the first post which entire log and debug log (in this case from TexGen and DynDOLOD) to upload when making posts. Read the first post which log and debug log to upload when making posts.

If there are no matching full textures it typically means the LOD textures should be rendered. I have adding that on the long list of things to do.

Fixed. Thanks

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log and debug log to uplaod when making posts. Read the entire message carefully as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages. Especially "Skyrim.esm might be the wrong version." Click the link "Click on this link for additional explanations and help for this message" as explained on the first post to open https://dyndolod.info/Messages/Unresolved-Form-ID with further explanation and help. The Bashed patch was most likely made for a different load order, maybe with a different version of Skyrim.esm or with plugins in the load order that inject records into it. Remove the broken Bashed patch and generate a new one for the current load order. Also see https://dyndolod.info/Generation-Instructions#Prerequisites

As I suggested, test LOD generated for vanilla (new MO2 profile just with requiremets, generate LOD for Tamriel only) to check things work as expected. Then add whatever you might suspect. The mod is out since a while, other users would have probably had issues and reported them. BTW, there is not need for PortalBoxFix=1 with SkyrimSE. Because that output path is wrong, obviously, Those textures should have overwritten the original path. Will be fixed next version.

You do not need to worry about being compatible with a mod that contains stitched object LOD textures. TexGen should overwrite them with correct files created automatically, if needed with additional configs for MoreRust-softcolors.esp specifially. Config files are parsed with the same priority as the plugins. so the last config to provide information for a LOD textures that was already defined earlier should "win". At least until you get around to update the LOD models or LOD material files to use they grayscale to palette. Vanilla LOD textures should typically always be created the same way form the same source textures. A mod that requires/expects different source-to-LOD-textures needs to use a different LOD texture file name so it doesn't conflict with other mods expecting the vanilla-style LOD texture.

https://mega.nz/file/UQJyQAJT#MshvMge0NfL_4YG-COUBh0QxoiSlYtDf4pkwXJEqtwc Use config below: The _d/_n are copied 1:1 to temp The _s copied to temp has contrast modified by -50, which means values are multiplied by 0.5. // AirplaneDebris01LOD 0 1 1 1 textures\Vehicles\Airplane\Airplane_EXT_01_d.dds x 7 0 0 DynDOLOD-Temp\textures\Vehicles\Airplane\Airplane_EXT_01_d.dds 0 x 0 1 1 1 textures\Vehicles\Airplane\Airplane_EXT_01_n.dds x 7 0 0 DynDOLOD-Temp\textures\Vehicles\Airplane\Airplane_EXT_01_n.dds 0 x -50 -1 1 1 textures\Vehicles\Airplane\Airplane_EXT_01_s.dds x 7 0 0 DynDOLOD-Temp\textures\Vehicles\Airplane\Airplane_EXT_01_s.dds 0 x 0 1 1 1 textures\Vehicles\Airplane\Airplane_INT_01_d.dds x 7 0 0 DynDOLOD-Temp\textures\Vehicles\Airplane\Airplane_INT_01_d.dds 0 x 0 1 1 1 textures\Vehicles\Airplane\Airplane_INT_01_n.dds x 7 0 0 DynDOLOD-Temp\textures\Vehicles\Airplane\Airplane_INT_01_n.dds 0 x -50 -1 1 1 textures\Vehicles\Airplane\Airplane_INT_01_s.dds x 7 0 0 DynDOLOD-Temp\textures\Vehicles\Airplane\Airplane_INT_01_s.dds 0 x 0 1 1 1 textures\Vehicles\Airplane\Airplane_Paint_EXT_01_d.dds x 7 0 0 DynDOLOD-Temp\textures\Vehicles\Airplane\Airplane_Paint_EXT_01_d.dds 0 x 0 1 1 1 textures\Vehicles\Airplane\Airplane_Paint_EXT_01_n.dds x 7 0 0 DynDOLOD-Temp\textures\Vehicles\Airplane\Airplane_Paint_EXT_01_n.dds 0 x -50 -1 1 1 textures\Vehicles\Airplane\Airplane_Paint_EXT_01_s.dds x 7 0 0 DynDOLOD-Temp\textures\Vehicles\Airplane\Airplane_Paint_EXT_01_s.dds 0 x 0 1 1 1 DynDOLOD-Temp\textures\Vehicles\Airplane\Airplane_EXT_01_d.dds 0.5 0.5 0 0.5 textures\lod\AirplaneDebris01LOD_d.dds 1 1 0 1 1 1 DynDOLOD-Temp\textures\Vehicles\Airplane\Airplane_EXT_01_d.dds 0.5 0.5 0.5 0.5 textures\lod\AirplaneDebris01LOD_d.dds 1 1 0 1 1 1 DynDOLOD-Temp\textures\Vehicles\Airplane\Airplane_INT_01_d.dds 0.5 0.5 0.5 0 textures\lod\AirplaneDebris01LOD_d.dds 1 1 0 1 1 1 DynDOLOD-Temp\textures\Vehicles\Airplane\Airplane_Paint_EXT_01_d.dds 0.5 0.5 0 0 textures\lod\AirplaneDebris01LOD_d.dds 1 1 BTW there are several vanilla LOD models using HitTechExtALargeLOD_d.DDS Vanilla LOD models/textures do not use "grayscale to palette" shader flags. LODGen supports that flag, though.