DynDOLOD 3.00 Alpha 196

[z929669]

1 hour ago, godescalcus said:

I'm failing to get DynDOLOD_CRC32Gen.pas to work.

I copied it to xEdit\Edit scripts, open the mod in xEdit and run the script on its tree base records. Set the origin and output folders as such:

const
  source = 'H:\SteamLibrary\steamapps\common\Skyrim Special Edition\Data\meshes\';
  output = 'C:\modding_tools\DynDOLOD\docs\trees.ultra\tools\hybrids\input\ulvenwald\';

(on a previous run I set the source to 'C:\modding_tools\DynDOLOD\docs\trees.ultra\tools\hybrids\input\ulvenwald_origin\' - which is a folder where I copied the entire set of tree meshes contained in the mod).

Clearly this isn't how it's used, but I'm guessing since I can't find instructions anywhere. Searched this forum, googled, looked into documentation for the older DynDOLOD, seems like if there were instructions, they're gone now? Last night I spent 4 hours using 7zip to get the CRC32, then manually add it to hundreds of filenames, it would be great to avoid having to do that again...

Also found re-uv.bat and merge.bat that could help make it quicker to process the original mesh into a static mesh, before further processing and splitting - but also can't find instructions on how to use them. Are these in older DynDOLOD files that have not been included in the most recent versions? Any way to reach?

This is how I set it up. I just use the folder structure expected by the script and run xEdit via MO. The output will be a meshes folder in the xEdit Output adjacent to DynDOLOD-Source.

Right click the Tree node in xEdit for each relevant plugin, and the renamed tree NIF will all be generated. If your tree mod replaces vanilla trees and those trees don't have references in the mod plugin, you need to be certain full tree meshes from your mod exist under DynDOLOD-Source folder "as-is" but renamed like "TreeFile01_passthru_lod.nif" and you will need to also run this on the vanilla Tree nodes for each vanilla plugin (Skyrim, Hearthfires, Dawnguard, Dragonborn, TreeModPlugin ... all of them to be sure).

When finished, all trees with LOD from your mod will have the CRC32 under the meshes output folder. These are the only ones that need to be made into hybrids, and the file names are accurate. Be certain all of the base models are 'final' before you do it or the CRC will be wrong later after edit of the base NIFs.

[DarthVitrial]

Got an Assertion Failure message in Alpha-127.

Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 17505) while processing Glenmoril.esm [REFR:1C00DE69] (places NorTempleExterior01Base [STAT:00026FDE] in GRUP Cell Temporary Children of GHKyneTemple02 [CELL:1C00DE64] (in zGHWitchForestWorld "Vahdin Holt" [WRLD:1C00DE4D] at 0,2))
Error: Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 17505) while processing Glenmoril.esm [REFR:1C00DE69] (places NorTempleExterior01Base [STAT:00026FDE] in GRUP Cell Temporary Children of GHKyneTemple02 [CELL:1C00DE64] (in zGHWitchForestWorld "Vahdin Holt" [WRLD:1C00DE4D] at 0,2))
User says "Exit DynDOLOD"

 

log and bugreport attached.

Debug log (it's big): https://mega.nz/file/F1NChSxb#HZkBC1X-UVLWwNiNBgEgMhH5aG8wAZ0CbKi8ezQqesA

 

 

I also found the following in my Event Log:

Description: A .NET application failed.
Application: LODGenx64Win.exe
Path: E:\Dyndolod\Edit Scripts\LODGenx64Win.exe
Message: You must install or update .NET to run this application.

App: E:\Dyndolod\Edit Scripts\LODGenx64Win.exe
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '6.0.0' (x64)
.NET location: C:\Program Files\dotnet\

The following frameworks were found:
  7.0.4 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

If this is the same issue, does that mean LodGen doesn't work with .Net 7? I always thought .Net 6 onward was backward compatible (actually doesn't installing 7 remove 6?) but if not I'll roll back to .net 6 and try again. (I'm certain I've used DynDoLod/LodGen with .Net 7 before with no issues though, as recently as two months ago, which is odd. Maybe the two errors are unrelated?)

bugreport.txt DynDOLOD_SSE_log.txt

Edited May 11, 2023 by DarthVitrial

[sheson]

7 hours ago, godescalcus said:

I'm failing to get DynDOLOD_CRC32Gen.pas to work.

I copied it to xEdit\Edit scripts, open the mod in xEdit and run the script on its tree base records. Set the origin and output folders as such:

const
  source = 'H:\SteamLibrary\steamapps\common\Skyrim Special Edition\Data\meshes\';
  output = 'C:\modding_tools\DynDOLOD\docs\trees.ultra\tools\hybrids\input\ulvenwald\';

(on a previous run I set the source to 'C:\modding_tools\DynDOLOD\docs\trees.ultra\tools\hybrids\input\ulvenwald_origin\' - which is a folder where I copied the entire set of tree meshes contained in the mod).

Clearly this isn't how it's used, but I'm guessing since I can't find instructions anywhere. Searched this forum, googled, looked into documentation for the older DynDOLOD, seems like if there were instructions, they're gone now? Last night I spent 4 hours using 7zip to get the CRC32, then manually add it to hundreds of filenames, it would be great to avoid having to do that again...

Also found re-uv.bat and merge.bat that could help make it quicker to process the original mesh into a static mesh, before further processing and splitting - but also can't find instructions on how to use them. Are these in older DynDOLOD files that have not been included in the most recent versions? Any way to reach?

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.

[sheson]

2 hours ago, DarthVitrial said:

Got an Assertion Failure message in Alpha-127.

Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 17505) while processing Glenmoril.esm [REFR:1C00DE69] (places NorTempleExterior01Base [STAT:00026FDE] in GRUP Cell Temporary Children of GHKyneTemple02 [CELL:1C00DE64] (in zGHWitchForestWorld "Vahdin Holt" [WRLD:1C00DE4D] at 0,2))
Error: Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 17505) while processing Glenmoril.esm [REFR:1C00DE69] (places NorTempleExterior01Base [STAT:00026FDE] in GRUP Cell Temporary Children of GHKyneTemple02 [CELL:1C00DE64] (in zGHWitchForestWorld "Vahdin Holt" [WRLD:1C00DE4D] at 0,2))
User says "Exit DynDOLOD"

 

log and bugreport attached.

Debug log (it's big): https://mega.nz/file/F1NChSxb#HZkBC1X-UVLWwNiNBgEgMhH5aG8wAZ0CbKi8ezQqesA

 

 

I also found the following in my Event Log:

Description: A .NET application failed.
Application: LODGenx64Win.exe
Path: E:\Dyndolod\Edit Scripts\LODGenx64Win.exe
Message: You must install or update .NET to run this application.

App: E:\Dyndolod\Edit Scripts\LODGenx64Win.exe
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '6.0.0' (x64)
.NET location: C:\Program Files\dotnet\

The following frameworks were found:
  7.0.4 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

If this is the same issue, does that mean LodGen doesn't work with .Net 7? I always thought .Net 6 onward was backward compatible (actually doesn't installing 7 remove 6?) but if not I'll roll back to .net 6 and try again. (I'm certain I've used DynDoLod/LodGen with .Net 7 before with no issues though, as recently as two months ago, which is odd. Maybe the two errors are unrelated?)

bugreport.txt 302.72 kB · 0 downloads DynDOLOD_SSE_log.txt 383.65 kB · 0 downloads

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)

[DarthVitrial]

9 hours ago, sheson said:

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)

It's repeatable. Different cell, same error.

Same error in the event log too. I have the x64 version of the .Net Runtime 7 installed (with the Desktop Runtime, yes).

Bugreport and log attached.

Debug log: https://mega.nz/file/g9chHZRR#z3flhjM-b6rKAQsX8eRsrddQgbPMEEkQi7273i-D2pQ

bugreport.txt DynDOLOD_SSE_log.txt

[sheson]

31 minutes ago, DarthVitrial said:

It's repeatable. Different cell, same error.

Same error in the event log too. I have the x64 version of the .Net Runtime 7 installed (with the Desktop Runtime, yes).

Bugreport and log attached.

Debug log: https://mega.nz/file/g9chHZRR#z3flhjM-b6rKAQsX8eRsrddQgbPMEEkQi7273i-D2pQ

bugreport.txt 307.19 kB · 0 downloads DynDOLOD_SSE_log.txt 396.37 kB · 0 downloads

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.

[DarthVitrial]

52 minutes ago, sheson said:

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.

That build seems to have fixed it.

The .net error still showed up in the event log but LodGen finished with no issues, no assertions or error messages in the log.

Mind if I ask what you changed in that test build?

DynDOLOD_SSE_log.txt

Edited May 11, 2023 by DarthVitrial

[sheson]

1 hour ago, DarthVitrial said:

That build seems to have fixed it.

The .net error still showed up in the event log but LodGen finished with no issues, no assertions or error messages in the log.

Mind if I ask what you changed in that test build?

DynDOLOD_SSE_log.txt 1.69 MB · 0 downloads

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

[proton252]

I am writing this message using translation, some parts may not be understood, sorry.
I've been trying to build lod with Dyndolod 12x versions for about three weeks, I'm constantly encountering the same problems, including the last version.

System 1: Ryzen 7 5800, Radeon 6700XT, 16Gb 3600mhz Ram, SSD. Windows 10 pro clean install, pagefile 30GB. Defender is disabled throughout the process, AMD and Radeon processes are terminated from the task manager.
Both SSDs in the system were formatted and the operating system was reinstalled, the mod list was installed from scratch. Almost 1500 mods.

System 2: Intel i3 12100f, Radeon 6600XT, 16Gb 3200mhz Ram, SSD.
Windows 11 730 mod.

Symptoms/problems:
1. Completely stopping at different locations while creating the atlas (except for lodgen, it continues to work and dyndolod does nothing when the process is complete.)
2. Dyndolod random crashes while Lodgen is still running.
3. Even though it has not created an atlas of all regions, it goes to waiting as if it has finished. Even though the Lodgen creation process is finished, it stays in the standby state.

Unfortunately I can no longer use Terrain underside, occlusion options as the system is completely locked (the setting in the ini file doesn't make any difference). I also gave up on the grass lod option. I didn't have many of these problems in old versions, and lod file sizes weren't that huge.

V127 Medium settings, no lod 32, no occlusion, no terrain underside, so only tamriel lods became 13GB.

The lod archive I prepared a few months ago for my 670 mod Vortex collection is 12GB unzipped, including tree and terrain lod 32, occlusion and grass cache.

Now I run it with the debug option turned on and the program is completely stopped, not frozen. Lodgen isn't running in the background either.
I have to terminate the program myself.

I'm aware that the program is an alpha version, but it gets worse with each new version, at least on AMD systems.

https://mega.nz/file/Ai5UzIab#lNpWrUy_S5GR0gy8lXz389g82Qkm5BPkI9J3OcAKCPY

https://mega.nz/file/Zjpz2BLD#5dOl_BQL7aaAH7BND7OX3x1yYwcY51UAa6zFoeCtSqY

[z929669]

36 minutes ago, proton252 said:

I am writing this message using translation, some parts may not be understood, sorry.
I've been trying to build lod with Dyndolod 12x versions for about three weeks, I'm constantly encountering the same problems, including the last version.

System 1: Ryzen 7 5800, Radeon 6700XT, 16Gb 3600mhz Ram, SSD. Windows 10 pro clean install, pagefile 30GB. Defender is disabled throughout the process, AMD and Radeon processes are terminated from the task manager.
Both SSDs in the system were formatted and the operating system was reinstalled, the mod list was installed from scratch. Almost 1500 mods.

System 2: Intel i3 12100f, Radeon 6600XT, 16Gb 3200mhz Ram, SSD.
Windows 11 730 mod.

Symptoms/problems:
1. Completely stopping at different locations while creating the atlas (except for lodgen, it continues to work and dyndolod does nothing when the process is complete.)
2. Dyndolod random crashes while Lodgen is still running.
3. Even though it has not created an atlas of all regions, it goes to waiting as if it has finished. Even though the Lodgen creation process is finished, it stays in the standby state.

Unfortunately I can no longer use Terrain underside, occlusion options as the system is completely locked (the setting in the ini file doesn't make any difference). I also gave up on the grass lod option. I didn't have many of these problems in old versions, and lod file sizes weren't that huge.

V127 Medium settings, no lod 32, no occlusion, no terrain underside, so only tamriel lods became 13GB.

The lod archive I prepared a few months ago for my 670 mod Vortex collection is 12GB unzipped, including tree and terrain lod 32, occlusion and grass cache.

Now I run it with the debug option turned on and the program is completely stopped, not frozen. Lodgen isn't running in the background either.
I have to terminate the program myself.

I'm aware that the program is an alpha version, but it gets worse with each new version, at least on AMD systems.

https://mega.nz/file/Ai5UzIab#lNpWrUy_S5GR0gy8lXz389g82Qkm5BPkI9J3OcAKCPY

https://mega.nz/file/Zjpz2BLD#5dOl_BQL7aaAH7BND7OX3x1yYwcY51UAa6zFoeCtSqY

Carefully read the DynDOLOD FAQ under section "DynDOLOD/TexGen Questions", and modify DynDOLOD_SSE.ini settings accordingly.

I suspect your issues are due to having so many mods installed. Some may also have non-optimized LOD (e.g., some tree mods have 'LOD' models with huge triangle counts).

[sheson]

1 hour ago, proton252 said:

I am writing this message using translation, some parts may not be understood, sorry.
I've been trying to build lod with Dyndolod 12x versions for about three weeks, I'm constantly encountering the same problems, including the last version.

System 1: Ryzen 7 5800, Radeon 6700XT, 16Gb 3600mhz Ram, SSD. Windows 10 pro clean install, pagefile 30GB. Defender is disabled throughout the process, AMD and Radeon processes are terminated from the task manager.
Both SSDs in the system were formatted and the operating system was reinstalled, the mod list was installed from scratch. Almost 1500 mods.

System 2: Intel i3 12100f, Radeon 6600XT, 16Gb 3200mhz Ram, SSD.
Windows 11 730 mod.

Symptoms/problems:
1. Completely stopping at different locations while creating the atlas (except for lodgen, it continues to work and dyndolod does nothing when the process is complete.)
2. Dyndolod random crashes while Lodgen is still running.
3. Even though it has not created an atlas of all regions, it goes to waiting as if it has finished. Even though the Lodgen creation process is finished, it stays in the standby state.

Unfortunately I can no longer use Terrain underside, occlusion options as the system is completely locked (the setting in the ini file doesn't make any difference). I also gave up on the grass lod option. I didn't have many of these problems in old versions, and lod file sizes weren't that huge.

V127 Medium settings, no lod 32, no occlusion, no terrain underside, so only tamriel lods became 13GB.

The lod archive I prepared a few months ago for my 670 mod Vortex collection is 12GB unzipped, including tree and terrain lod 32, occlusion and grass cache.

Now I run it with the debug option turned on and the program is completely stopped, not frozen. Lodgen isn't running in the background either.
I have to terminate the program myself.

I'm aware that the program is an alpha version, but it gets worse with each new version, at least on AMD systems.

https://mega.nz/file/Ai5UzIab#lNpWrUy_S5GR0gy8lXz389g82Qkm5BPkI9J3OcAKCPY

https://mega.nz/file/Zjpz2BLD#5dOl_BQL7aaAH7BND7OX3x1yYwcY51UAa6zFoeCtSqY

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.

[proton252]

19 minutes ago, sheson said:

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 that 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 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.

I am aware of the error with Kernelbase.dll but it does not always give this error.
Drivers are up to date, no programs except background Windows processes. The most common issue I run into is Texconvx64.exe stopping while rendering Texture Atlas and never continuing.

Really, I have neither the strength nor the time to deal with Dyndolod anymore.

If you really want to fix these problems, try installing a large mod list and creating Lod using AMD graphics card, not Nvidia.

Thank you anyway.

[sheson]

4 hours ago, proton252 said:

I am aware of the error with Kernelbase.dll but it does not always give this error.
Drivers are up to date, no programs except background Windows processes. The most common issue I run into is Texconvx64.exe stopping while rendering Texture Atlas and never continuing.

Really, I have neither the strength nor the time to deal with Dyndolod anymore.

If you really want to fix these problems, try installing a large mod list and creating Lod using AMD graphics card, not Nvidia.

Thank you anyway.

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.

[spacepillow]

Hi there,

I've been having trouble generating my LOD for some reason. It keeps hanging at certain points. I was able to generate Tamriel just fine, but the program stalls after 4-8 minutes when I try to generate all worldspaces. Following STEP guide and ACMOS' instructions. I noticed that it seems to hang on "creating atlas textures" for wyrmstooth, or at least it did on my most recent run. It may be getting stuck on that. I also have a few other errors in the logs but I'm not especially worried about them because my output came out just fine last time. 

Could you take a look at this for me? I'd be happy to give any more information, but I don't really know too much about this area of modding so I don't know what's useful. Attached is a zip link with my (hefty) debug log, the regular log, two wyrmstooth logs, and also a log for solstheim which happened to be selected when I shift-clicked these guys into an archive. Sorted by date modified so I guess it was adjacent to wyrmstooth, which probably doesn't matter.

Anyhow -- I'm going to run on more attempt at this and set my computer to fall asleep two from now or something. I'd appreciate any help if you have the time. Thank you and hoping to hear back soon. Here is the link to the files.  https://ufile.io/b2uyufqh 

[sheson]

1 hour ago, spacepillow said:

Hi there,

I've been having trouble generating my LOD for some reason. It keeps hanging at certain points. I was able to generate Tamriel just fine, but the program stalls after 4-8 minutes when I try to generate all worldspaces. Following STEP guide and ACMOS' instructions. I noticed that it seems to hang on "creating atlas textures" for wyrmstooth, or at least it did on my most recent run. It may be getting stuck on that. I also have a few other errors in the logs but I'm not especially worried about them because my output came out just fine last time. 

Could you take a look at this for me? I'd be happy to give any more information, but I don't really know too much about this area of modding so I don't know what's useful. Attached is a zip link with my (hefty) debug log, the regular log, two wyrmstooth logs, and also a log for solstheim which happened to be selected when I shift-clicked these guys into an archive. Sorted by date modified so I guess it was adjacent to wyrmstooth, which probably doesn't matter.

Anyhow -- I'm going to run on more attempt at this and set my computer to fall asleep two from now or something. I'd appreciate any help if you have the time. Thank you and hoping to hear back soon. Here is the link to the files.  https://ufile.io/b2uyufqh 

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.