sheson

The provided log and debug log show DynDOLOD being started and then closed without generating anything. You would need to run the generation again recreating the issue in order to create a debug log as that is replaced every session.

In that case test what happens if you only disable Occlusion.esp. That should not change anything so continue with disabling the DynDOLOD.esp. If nothing changes, also disable the DynDOLOD.esm. In case there still is no change, hide/rename the meshes folder from the DynDOLOD output. Report results.

Check if it is LOD by disabling LOD with ttl in console. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Rudimentary-Troubleshooting If that does not change anything, see if you can click it with console open to get information about it with more informative console. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots Report results.

Repeat test with latest test version, upload the new test5*.dds, logs. You can skip test3_0.dds

It still should not happen, regardless the reason. Get the latest test version. Delete all old logs. While still having LockRecords=0 also add RealTimeLog=1. Then run just Tamriel. It will create a DynDOLOD_SSE_realtime_log.txt in the log folder which might grow big and really take some time, but hopefully it still exhibits the issue at some point. Once you exist it, it should still save log and debug log also. Upload all 3 logs if they exists.

Please report if you have more luck with the latest test version i just uploaded.

If the used texture is a "HD LOD texture" the LOD is not going to use the object LOD atlas texture but the full texture in the BTO regardless. This includes mountainslab01.dds and mountainslab02.dds, all textures listed in IgnoreTexture= in DynDOLOD_SSE.INI, textures listed in TNAM and UNAM - HD LOD texture on the worldspace records that have LOD. This makes sense for lots of LOD models using the same full texture as it still combines a lot of models into a single shape. For anything else, if the final UV (after applying scaling and whatnot from the TexGen data for stitched textures) is going to be outside the limits, LODGen might try to re-uv and force it. That takes extra time and is not perfect. It is is better to do this for LOD models properly manually. For best results, all UV coordinates should be positive (that is to the lower right in NifSkope), as close as possible to 0.0, 0.0 and if possible not exceed the max of the stitched texture created by TexGen.

In that case, also report all plugins overwriting the permanent cell 00000D74.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log, debug log and bugreport.txt (if it exists) to upload when making posts.

It flickers only once because in the intro something is enabled in that cell which has the VWD flag set or uses a base record with the LOD flag, but probably has no LOD model for it. The listed references all seem to be just "victims". Can you list all plugins that overwrite the cell 4,-20 with from ID 0000982A?

In that case, new 3D tree LOD model file are required. Curiously the mod contains them for the seasons versions. Put vurt_bentpine_20519046passthru_lod_0.nif and vurt_bentpine_20519046passthru_lod_1.nif into the folder Meshes\DynDOLOD\lod\trees\vurt\ of DynDOLOD Resources. Next version will contain them. Then generate LOD again. Let me know in case they do not seem to match well.

Make a useful screenshot of the full model with more informative console as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots. Also upload G:\DynDOLOD folder\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt Those seems to be tree LOD billboards. What version of bend Pines II do you have installed? They typically comes with a LOD model and rules. The debug log shows the rules being loaded. Check in MO2 right windows Data tab that there is a vurt_bentpinepassthru_lod.nif in a meshes subfolder (typically Meshes\DynDOLOD\LOD\Trees\) and report.

Make a useful screenshot of the full model with more informative console as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots. The game enables something in that cell that uses a base record with the Has LOD flag set. DynDOLOD is supposed to patch that out, not sure yet why the Level32 setting would affect that.

I uploaded a new test version. Delete all old logs, then run and report result and upload new logs if issue persists.

Get the latest test version from https://dyndolod.info/Downloads/Test-Versions. Delete all old logs and then try to run it without any changes to the INI. Report if it runs through or upload new logs or realtime log if it doesn't.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log, debug log and bugreport.txt to upload when making posts. In case logs are not created because you can not normally end the program, enable the realtime log and upload that as explained in the website link. Regardless of that, always clean plugins that have deleted references. See https://dyndolod.info/Messages/Deleted-Reference. Also see https://dyndolod.info/Messages/Reference-Attached-to-Wrong-Cell

The solution getting valid noise texture filenames from WATR records broke when a recent update to xEdit made changes to the element paths. Will be fixed in the next alpha version. If you like, get the latest test version from https://dyndolod.info/Downloads/Test-Versions to verify.

Read the first post which SSELODGen_log.txt to upload when making a post. Consider posting a screenshot of the map to show the issue with terrain LOD generated by xLODGen. It generates terrain LOD including water LOD based on the current load order with the chosen quality settings. See https://dyndolod.info/Mods/Maps-And-Map-Mods Whatever mod that is the last to contain the files used by the game for the map is the problematic one. So if a map mod is the last to overwrite those files, then it is the one causing the problem.

Please repeat with the latest test version I just uploaded.

Upload the requested logs that were created when it froze.

Remove or set CPUMipMaps=0 so it uses the GPU instead again. Get latest test version from https://dyndolod.info/Downloads/Test-Versions Generate Tamriel only. It will create a bunch of test textures to the root of the dedicated output folder. Please upload all of them.

https://dyndolod.info#DynDOLOD-3-Alpha Certain things may be incomplete, not work as expected or change considerably between versions. Use the official DynDOLOD support forum to provide feedback https://dyndolod.info/Official-DynDOLOD-Support-Forum Report the actual problem or error message or provide feedback without making unverified assumptions or asking leading questions. For example: "It would be nice if the grass density setting could just be changed in the expert interface when Executing LODGen instead of having to edit the export file." Let me worry about how to implement things. The instructions exist, because that is how things work with xEdit and the LODGen command line tool. I have not yet spend any of my free time to make it more convenient for non experts. If you want to contribute, contribute to https://github.com/TES5Edit/TES5Edit.

Report if there atlas texture is generated any different after adding CPUMipMaps=1 under [DynDOLOD] to C:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini

Please upload C:\Modding\Tools\DynDOLOD\Edit Scripts\Export\LODGen_SSE_ObjectAtlasMap_Tamriel.lst from the last generation.

Restore to the default TexGen_SSE.ini. Delete all old logs and bugreport.txt. Then run TexGen. If it crashes / has an error message upload new bugreport.txt and logs as usual. If it freezes, try to close it normally with one click to the X top right so it can hopefully save the log and debug log. If that doesn't work enable the realtime log as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs and upload that. There should be no reason for setting MaxRenderResolution anymore, since current versions should work around NVIDIA Linux drivers consuming all memory. Keep an eye on VRAM memory consumption.