sheson

Read the first post which log and debug log to upload when making posts. Also read https://dyndolod.info/Official-DynDOLOD-Support-Forum. Unsurprisingly testing with Vanilla and Holidays.esp in the load order, it is not added as a master to DynDOLOD.esm.

Moved to the DynDOLOD 3 Alpha thread. Read the first post which DynDOLOD log, debug log and bugreport.txt (if it exists) to upload when making posts. Also see https://dyndolod.info/Official-DynDOLOD-Support-Forum

Bethesda did this for performance, memory usage reasons. Past the wall is basically just a bit of terrain that does not reach very far with very few references if any. You might notice just a single rock reference placed per cell because of engine reasons. The mod will make much better distance views from inside Markarth. We discussed this long before Special Edition came out. Enabling this used to have noticeable performance impact in Skyrim. Probably less so now. Creating a patch file for for DynDOLOD to set the flag instead of a plugin could probably make this compatible with everything.

See Trees on the Map for further explanations. https://dyndolod.info//Help/Ultra-Tree-LOD#Trees-on-the-Map If no LOD level 32 object LOD files exist, the setting can cause stuck object LOD in active exterior cells or object LOD to be missing entirely. To generate LOD level 32 object LOD, set Level32=1 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini. LOD level 32 object LOD can only show on the map with the Skyrim INI setting. In the normal game view only LOD level 4, LOD level 8 and LOD level 16 Object LOD are shown.

https://dyndolod.info/FAQ "Entire LOD missing" Can be caused by [MapMenu] uLockedObjectMapLOD=32 in Skyrim.ini (or SkyrimCustom.INI or a mod INI), especially if there are no object LOD level 32 meshes (which is the vanilla/default). See Trees on the Map for further explanations. Either set uLockedObjectMapLOD=16 or generate LOD Level 32 files.

Moved to the DynDOLOD 3 Alpha thread. The bugreport shows out of memory errors. https://dyndolod.info/Installation-Instructions Use the x64 versions of DynDOLOD/TexGen. The x86 versions may run into memory errors especially with large texture resolution settings and are included in case a x86 OS is used. They are functionally identical, the only difference is the supported CPU architecture.

Read the first post which log and debug log to upload when making posts. https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots If making screenshots of objects missing with DynDOLOD output enabled, make a screenshot of the objects as explained above without DynDOLOD output enabled. https://dyndolod.info/FAQ "Out of place or floating objects"

No debug log was uploaded. https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs The screenshot seems to show no tree LOD and no object LOD. https://dyndolod.info/FAQ "Entire LOD missing" Increase terrain LOD, object LOD or tree LOD distances in the DynDOLOD SkyUI MCM Settings. Can be caused by [MapMenu] uLockedObjectMapLOD=32 in Skyrim.ini (or SkyrimCustom.INI or a mod INI), especially if there are no object LOD level 32 meshes (which is the vanilla/default). See Trees on the Map for further explanations.

It changes rendering using multiple threads for different tasks to a single thread.

Check in task manager if there are Texconvx64.exe processes running in the background that DynDOLOD might be waiting for. Add RenderSingle=1 under [DynDOLOD] in C:\Modding\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini and check if it makes a difference.

There is not point in making posts without having followed the suggestion I provided and without reporting the result with new corresponding log, debug, bugreport.txt, Windows event log etc. in case the issue persists. Texconx is a tool from Microsoft using DirectX to convert textures. If Texconv does not complete, then the tools waiting for it are not the problem. Install/Repair Visual Studio 2015, 2017, 2019, and 2022. Make sure that the OS, UAC, antivr, crapware etc. does not interfere with Texconv and tools. Make sure to only install the graphics driver only without any crapware. Make sure that the best graphics card is reported as the first by the OS. Otherwise add TexconvAdapterIndex=X under [DynDOLOD] to D:\Modding\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini, where X is the desired adapter index as reporting by the official Texconv version. If neither helps, disable GPU usage of Texconv by setting TexconvAdapterIndex=-1 so it uses the CPU instead. Anytime there is a categorical problem/bug, there are lots of proper reports from users. If a single user has different random issues, then the cause is is more likely hardware, BIO setting, OS, drivers, over modding, bad mods, plugins or game asserts not optimized for LOD, too high settings or options, etc. I do not have an AMD graphics card. This is a free hobby I do in my spare time which I happen to share for the explicit requirement to test and report problems with the tools or mods. If you do not want to troubleshoot and properly report problems, then do not participate in the alpha test.

The bugreport.txt you uploaded shows a handled access violation while checking script pex files. It can be ignored. The debug log (the accompanying normal log was not provided, see first post) you uploaded seems to show you closed the program mid operation. Check if there are Texconvx64.exe processes running in the background that DynDOLOD maybe be waiting for. Really only install the latest graphics driver only, without any of the crapware. Add RenderSingle=1 under [DynDOLOD] in D:\Modding\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini and check if it makes a difference. You are referring to a setting in the INI file without actually telling with setting or INI file. If the PC/OS locks up it is a hardware or OS problem. Generating the underside should typically not require much additional resources. See https://dyndolod.info/Help/Occlusion-Data#Out-of-Memory-while-Generating-Occlusion-Data See https://dyndolod.info/Help/Grass-LOD#LODGen-takes-a-long-time-or-uses-a-lot-of-memory See https://dyndolod.info/FAQ "High memory usage / Out of memory" No other logs, debug logs or bugreport.txt for any other described issues have been provided. When reporting a crash, upload the log, debug, log bugreport.txt for it as explained on the first post. https://dyndolod.info/Official-DynDOLOD-Support-Forum If the generated output is large, you might have mods that contain or define large NIF or full models NIFs for LOD generation or the grass density is too high, there are more mods, worldspaces, higher settings etc. The OpenGL rendering routines are pretty much the same for about a year now. Just with a couple bug fixes to address "invalid operation", which you did not report. The last bug fix was in February. As far as I can tell, TexConv is still using DirectX to convert textures pretty much the same way, too.

Regardless of what mods are installed, the generation instructions are always the same https://dyndolod.info/Generation-Instructions: Prerequisites Typically generate terrain LOD meshes and textures with xLODGen before generating the LOD mod with DynDOLOD 1. Generate The Required LOD Assets with TexGen 2. Generate The LOD Mod with DynDOLOD "This" is a truncated screenshot from MO2. There is no point in installed DynDOLOD DLL / DynDOLOD DLL Scripts when the scripts are not overwriting DynDOLOD Resources SE. https://dyndolod.info/Help/DynDOLOD-DLL It should be "DynDOLOD Resources SE 3 Alpha-36" It should be "DynDoLod V 3.0 Lod pack (all versions)" 4.01 The screenshot does not show Majestic Mountains itself. Correct, the SSE Terrain Tamriel plugin should only be active when generating terrain LOD. Do not forget to install and to enable the xLODGen terrain LOD output before running DynDOLOD. Do not forget to install and to enable the TexGen output before running DynDOLOD. You should be using DynDOLOD 3 Alpha-127 https://dyndolod.info/Generation-Instructions#2-Generate-The-LOD-Mod-with-DynDOLOD Keep all LOD assets (DynDOLOD Resources, 3rd party mods, TexGen output etc.) activated unless there are specific instructions to disable 3rd party mode. Object LOD and tree LOD assets may also be used directly.

You are generating ultra tree LOD which disables standard tree LOD, so changing the fTreeLoadDistance setting has no effect. You are using Billboard tree LOD for the higher object LOD levels. It is unclear if LOD Level 8 Billboard4 is already too bright or only LOD Level 16 with Billboard 1. Set the same Billboard1 or Billboard4 for both LOD Level 8/16 so the lighting between those two levels is consistent. See https://dyndolod.info/FAQ "Billboard tree LOD does not match close-up full model trees": If the billboard tree LOD seems overly dark or bright, use the billboard brightness setting of the advanced mode to account for lighting changes made by ENBs or weather mods. https://dyndolod.info/Mods/Majestic-Mountains Download and install the DynDOLOD V3.0 LOD Pack (all versions) from the mods file section. Make sure no other 3rd party mod overwrites Majestic Mountains and its LOD assets when generating TexGen. Then make sure only TexGen overwrites those LOD assets when generating DynDOLOD. The mountains in the nearest LOD level 4 typically use the same full textures and the full models. 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. The Majestic Mountain DynDOLOD V3.0 LOD Pack contains updated pre-rendered LOD textures that should match pretty well. Make sure to install the same option, e.g. default, light or dark side. Pushing the higher LOD levels with those pre-rendered object LOD textures further away will mitigate the problem. The switching of LOD levels can be pretty obvious even if textures match pretty well.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum and make a proper post.

Check the load order for errors with xEdit before generating LOD as explained by the page https://dyndolod.info/Messages/Unresolved-Form-ID that opens when clicking the "Click on this link for additional explanations and help for this message" of the message as explained in the first post: https://tes5edit.github.io/docs/7-mod-cleaning-and-error-checking.html The xEdit error check will list all unresolved errors (and more) unlike DynDOLOD which only checks records that might be eligible for LOD.

Adding critical sections to the 2 procedures in wbImplementation where the race conditions occurred. https://dyndolod.info/Help/LODGen LODGen.exe/LODGenx64.exe require .NET Framework 4.8 to be installed, which is typically included in Windows 10/11. LODGenWin.exe/LODGenx64Win.exe require .NET Runtime 6 to be installed. The higher .NET Runtime 6 version is preferred. A check at startup determines if it can be used or else automatically falls back to the .Net Framework 4.8 version. To know which version is being used, check the log for the line: External: C:\Modding\DynDOLOD\Edit Scripts\[LODGen|LODGenx64|LODGenWin|LODGenx64Win].exe So it falls back to the 4.8 Framework version for you. In my case the LODGen log reports .NET 6.0.16 being used despite only having .NET 7.0.5 x64 installed

If it is different records, worldspaces etc. it is random. Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 16418) and Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 17505) are different errors with different call stacks. Check what happens with this test version https://mega.nz/file/kZwkBLLb#t83YYfTIHUW4u67ngZwQj_eSLblhS5YWiwB-O1lz11M Reinstall/Repair the .NET installation. If that does not help ask MS support.

I take it the assertion is not repeatable? The x64 version of .NET Runtime 7 works for me (it is also included in the .NET Desktop Runtime)

As you found out yourself, the version.ini from DynDOLOD Resources SE Alpha-36 contains "3.00" as information. That is expected, reported and all that is needed. This time you generated billboards with TexGen for the current load order, installed and activated the TexGen output, so now the billboards can be found.

You can find instructions for DynDOLOD_CRC32Gen.pas in the DynDOLOD 2 download archive ..\DynDOLOD\Docs\trees.ultra\tools\DynDOLOD_CreateStaticTree.html To make creating CRC32 filenames easier, copy DynDOLOD_CRC32Gen.pas to xEdit\Edit Scripts and use it to generate the LOD filename for a full model tree. It expects a *_passthru_lod.nif in ..\SteamLibrary\SteamApps\common\skyrim\Data\DynDOLOD-Source\*_passthru_lod.nif and will copy it to -o:OUTPUT Path + \meshes\DynDOLOD\lod\trees\*_XXXXXXXXpassthru_lod.nif. Start xEdit.exe, unfold TREEs, mark trees you want to work on and then apply script DynDOLOD_CRC32Gen.pas. It will either log source file not found for a desitnation or print a line when it copies from source -> destination. If copying files is not required just copy the CRC32 filename from the log to rename a file manually. I suggest to use 3D tools / Simplygon to re-uv for stitched object LOD textures created by TexGen. As usual, with xEdit/xLODGen/DynDOLOD or any other tool, always set a dedicated outputput folder outside Steam, game, mod manager folders etc. Otherwise there will be issues with existing files being replaced in their mod folder or potentially file access issues.

I suggest to simply enable ApplyToBasicGrass=true in enbseries.ini instead. Read https://dyndolod.info/Official-DynDOLOD-Support-Forum Read https://dyndolod.info/Help/Grass-LOD#No-Grass-LOD-Check-List

The log you uploaded showed 2.88, that means without a doubt that the number "2.88" was read from the file ..\Meshes\DynDOLOD\LOD\Version.ini The good news is that this post likely means neither DynDOLOD Resources 2.88, DynDOLOD Resources SE 3 Alpha is installed/active in the load order. It also means that TexGen output is not installed/active either. Hopefully you did not just somehow remove the old version.ini while keeping the outdated LOD assets. So only enable DynDOLOD Resouces SE 3 Alpha-36 to make sure there are no outdated LOD assets from DynDOLOD Resources 2.88 interfering when you generate LOD. Enable the TexGen output again. https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages explains: If there is an error prompt, read the entire message carefully. Many of them describe the problem in detail and offer hints for for a solution. The message already gives a hint how to solve the problem: Generate LOD billboards with TexGen first. Read additional explanations and help for a message by clicking on the Click on this link for additional explanations and help for this message link of the message. That will open a corresponding page on this website with further explanations and help for the message. Clicking that link opens https://dyndolod.info/Help/Tree-Grass-LOD-Billboards, which has a section "LOD Billboard(s) Not Found" at the bottom: The message means that current TexGen output is not installed, maybe incomplete or access to the data folder to check for the output is prevented by the OS, anti vir or 3rd party software.

Read the first post which log and debug log to upload when making posts. https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make meaningful screenshots. Read the explanations in the INI above the LODGenThreadSplit setting. You will have to experiment with settings yourself to see what works best in your case while keeping an eye on max memory consumption of LODGen to make sure everything currently running doesn't consume all available physical memory.

The tools will always use all triangles of a BSLODTriShape. Converting them does the same and makes it clear for whoever might look at the NIF.