DynDOLOD 3.00 Alpha 182

[DarthVitrial]

Unimportant, but are there any plans to swap from .Net 6 to .Net 8 in a future version?

[sneakarcheress]

I've been trying to troubleshoot this issue myself for about a week, but haven't been able to resolve it. TexGenx64 ran perfectly fine, but DynDOLODx64 has been sending me the same error message over and over. I've tried uninstalling and reinstalling my Skyrim VR directory and only enabling mods that would affect LOD (as well as their requirements), setting SKSEVR and DynDOLODx64 to run both as an administrator and non-administrator, cleaning all mod files and .esms as instructed, and fixing all errors and warnings that popped up over the course of troubleshooting. I no longer get any errors or warnings, but still have the same crash:

[Main Instruction]
Access violation at address 00000000012767D2 in module 'DynDOLODx64.exe'.

[Content]
Read of address 0000000000000000.

I'm running a modded setup of Skyrim VR and have been trying to generate LOD files with grass LOD using a Cathedral Landscapes precache file from the nexus - of course I turned off grass LOD generation when I got the error to see if my setup is incompatible, but I still got the error after doing so. I've also ported the creation club content from Skyrim AE (minus survival mode of course) over to VR as well, and am able to run the game bug-free with the port installed. Obviously I've tried disabling the port and all patches that require it and running DynDOLODx64 again, but still no dice. Am I doing something wrong, or is there something else that I need to fix? Would installing all the mods I have on VR on SSE, running DynDOLOD for SSE, and porting that export over to VR work?

Error Logs:

[Google Drive]

.zip with whole log folder: https://drive.google.com/file/d/1S8rE1YyShLna7vq54oMg5-eOcFh-SCJ6/view?usp=drive_link

[Paste.ee]

LODGen_TES5VR_Tamriel_log: https://paste.ee/e/xhEvH/0

DynDOLOD_TES5VR_log: https://paste.ee/e/K6Zyu/0

bugreport: https://paste.ee/e/OhmyM/0

[sheson]

47 minutes ago, DarthVitrial said:

Unimportant, but are there any plans to swap from .Net 6 to .Net 8 in a future version?

.NET6 is the last version to support Windows 7/8, so no plans.

[sheson]

40 minutes ago, sneakarcheress said:

I've been trying to troubleshoot this issue myself for about a week, but haven't been able to resolve it. TexGenx64 ran perfectly fine, but DynDOLODx64 has been sending me the same error message over and over. I've tried uninstalling and reinstalling my Skyrim VR directory and only enabling mods that would affect LOD (as well as their requirements), setting SKSEVR and DynDOLODx64 to run both as an administrator and non-administrator, cleaning all mod files and .esms as instructed, and fixing all errors and warnings that popped up over the course of troubleshooting. I no longer get any errors or warnings, but still have the same crash:

[Main Instruction]
Access violation at address 00000000012767D2 in module 'DynDOLODx64.exe'.

[Content]
Read of address 0000000000000000.

I'm running a modded setup of Skyrim VR and have been trying to generate LOD files with grass LOD using a Cathedral Landscapes precache file from the nexus - of course I turned off grass LOD generation when I got the error to see if my setup is incompatible, but I still got the error after doing so. I've also ported the creation club content from Skyrim AE (minus survival mode of course) over to VR as well, and am able to run the game bug-free with the port installed. Obviously I've tried disabling the port and all patches that require it and running DynDOLODx64 again, but still no dice. Am I doing something wrong, or is there something else that I need to fix? Would installing all the mods I have on VR on SSE, running DynDOLOD for SSE, and porting that export over to VR work?

Error Logs:

[Google Drive]

.zip with whole log folder: https://drive.google.com/file/d/1S8rE1YyShLna7vq54oMg5-eOcFh-SCJ6/view?usp=drive_link

[Paste.ee]

LODGen_TES5VR_Tamriel_log: https://paste.ee/e/xhEvH/0

DynDOLOD_TES5VR_log: https://paste.ee/e/K6Zyu/0

bugreport: https://paste.ee/e/OhmyM/0

Moved to the DynDOLOD 3 Alpha thread.

https://dyndolod.info/Messages/Exceptions#Access-violation

Test with the latest version. If problem persists, upload new DynDOLOD log, debug log and bugreport.txt.

Unrelated, it seems there are nonsensical command line arguments passed to DynDOLOD that can/should be removed.

[PRieST]

Edit:
I wrote this, while I started a new generation for the logs and got this message:

[Window Title]
DynDOLOD

[Main Instruction]
Error: OpenGL: 2610CB97 framebuffer incomplete attachment.

[Content]


Click on this link for additional explanations and help for this message

Clean install the latest recommended/WHQL (not optional and not beta) graphics drivers only without any bloatware.

If the issue persists, posts a problem report on the official DynDOLOD support forum.

[Exit DynDOLOD]

[Footer]
Online Help | Support Forum | Copy message to clipboard

This is new and never happened in the past even if I had one or two firefox tabs open.
LODGen is still running (very very slow) - may be because I didn't closed DynDOLOD.exe.
I am using plain nvidia drivers without anything else and also all of my 32GB ram were maxed as well as 100% CPU usage. I have no comparison to earlier generations, but this seems a bit odd, I don't think DynDOLOD/LODGen used all of my ram in the past.

Here are the logs to this point:
No Bugreport.log because I had to manually kill DynDOLOD (it just stayed open).
DynDOLOD/Debug log

__________________________________________________________________________________________________________________________

I know this may be a bit of not so good report, but somehow with alpha 166 the LODGen process is taking ages.
In earlier versions DynDOLOD in whole was finished in about 30 to 40 minutes (including generatin Occlusion.esp).
But now not even Level 4 *.bto of Tamriel are finished - infact it were only about 30 files.

I could provide you the logs to this point, as I don't want to wait hours before DynDOLOD is finished, as this is a new behavior.
This is written in the cmd window:
 

============================================================
Skyrim/Fallout Object/Terrain LOD Generator 3.0.21.0
Created by Ehamloptiran and Zilav
Updated by Sheson

Log started at 01:08:17
.NET Version: 6.0.26
Game Mode: SSE
Worldspace: Tamriel
Fix Tangents: False, False, False, False
Generate Tangents: True, True, True, True
Generate Vertex Colors: True, True, True, True
Merge Vertex Colors: True, True, True, True
Merge Meshes: True
Grouping: False
Remove Faces under Terrain: True
Remove Faces under Water: True
Remove Faces Z-Shift: 10
Use HD Flag: True
Ignore Materials: False
Alpha DoubleSided: False
Default Alpha Threshold: 128
Use Source Alpha Threshold: False
Use Backlight Power: False
Use Decal Flag: True
Specific level: No
Specific quad: No
Max Level: 32
Output: D:\DynDOLOD\DynDOLOD_Output\Meshes\Terrain\Tamriel\Objects\
Using UV Atlas: D:\DynDOLOD\Edit Scripts\Export\LODGen_SSE_ObjectAtlasMap_Tamriel.txt
Using Flat Textures: D:\DynDOLOD\Edit Scripts\Export\LODGen_SSE_FlatTextures.txt
Using Alt Textures: D:\DynDOLOD\Edit Scripts\Export\LODGen_SSE_AltTextures_Tamriel.txt
Generating object LOD meshes for worldspace Tamriel
Reading D:\DynDOLOD\Edit Scripts\Export\LODGen_SSE_LODGen_Terrain_Tamriel.bin
Threads: 20
Concs: 10

and after that the correspoding finished files (excerpt):

Finished LOD level 4 coord [44, -20] [211422/182082]
Finished LOD level 4 coord [-12, -12] [351088/297749]
Finished LOD level 4 coord [24, -4] [493912/446584]
Finished LOD level 4 coord [-32, 28] [740072/723720]
Finished LOD level 4 coord [16, 8] [944526/923257]
Finished LOD level 4 coord [36, -24] [126721/96119]
Finished LOD level 4 coord [40, -20] [210528/173473]

I didn't change anything big since the last generation with alpha 165 which could result in such long generation times. I looked at some created bto files and they also don't seem to be extra large or complex in comparison.
Maybe it's a fault on my end with too many high poly assets, but if this is the case I can't even tell which ones are the culprit.

Edited February 4 by PRieST

[DarthVitrial]

4 hours ago, sheson said:

.NET6 is the last version to support Windows 7/8, so no plans.

Right, Microsoft declared those EoL…and 10 will be EoL too soon, kinda scary.

I tested and you can have both 6 and 8 installed at the same time so it shouldn’t be an issue for now.

[quochunganhphu]

Dyndolod alpha 166 generated lod a lot longer than usual, it usually took only 45 minutes, but now 4 hours 

Logs:

https://www.mediafire.com/file/25ww5iq0k3ny4zx/Logs.zip/file
 

[z929669]

1 hour ago, quochunganhphu said:

Dyndolod alpha 166 generated lod a lot longer than usual, it usually took only 45 minutes, but now 4 hours 

Logs:

https://www.mediafire.com/file/25ww5iq0k3ny4zx/Logs.zip/file
 

Taken from DynDOLOD FAQ:

Quote

 

Long running time or output several GB in file size

The selected configuration options together with the installed mods and assets can require a lot of work. Use sensible settings. Manually closing DynDOLOD or LODGen while they are still running results in incomplete output that can not be used in the game. Delete it.

If there are more objects with LOD, it takes longer and creates larger files. If there are more triangles in the models used for LOD, it takes longer and creates larger files. If there are more triangles in the terrain meshes, it takes longer to optimize object LOD.

Do not use the experimental TreeFullFallBack setting without understanding what it does and what it is for.

Beware of mods adding or defining full models or not really well optimized LOD models for LOD.

It is normal for ultra tree LOD with 3D tree LOD models to take longer. Especially if the 3D tree LOD models are complex (large file size). Use or create optimized 3D tree LOD models or use tree LOD billboards instead. Do not use complex models for ultra tree LOD.

Check ..\DynDOLOD\Logs\DynDOLOD_[GAME MODE]_ModelsUsed_[WORLDSPACE].txt for a list of meshes and their total contribution to the object LOD meshes file sizes.

It normal that Grass LOD generation takes considerable longer. The more grass placements (mods, game INI, data in the grass cache) and the higher the density setting the longer. Grass LOD for complex grass may take even longer. The larger the grass cache, the large the generated object LOD and the longer it takes.

It is normal that generating LOD for seasons takes considerable longer.

Crapware installed with graphics drivers is known to prolong running times. Do a clean install of the latest recommended or official driver only. Do not install crapware shipping with the drivers or terminate it before running the tools.

 

This last point is commonly the issue in my XP. I run AMD and routinely kill all AMD background processes while generating LOD or creating the grass cache. If I don't, then grass caching and specific DynDOLOD Alpha version run times dramatically increase for me. Not all DynDOLOD alphas of the past have had the issues on my system, so I just disable all of my GFX driver software now every time, which totally resolves the issue.

Search this topic, and you will find many more posts and specifics on slow gen times.

[quochunganhphu]

i didn't have this issue with previous build, i've been using the same setting and configuration since, i will try to run one more time, maybe battle.net updating games was interfering with it

Edited February 4 by quochunganhphu

[quochunganhphu]

1 hour ago, z929669 said:

Taken from DynDOLOD FAQ:

This last point is commonly the issue in my XP. I run AMD and routinely kill all AMD background processes while generating LOD or creating the grass cache. If I don't, then grass caching and specific DynDOLOD Alpha version run times dramatically increase for me. Not all DynDOLOD alphas of the past have had the issues on my system, so I just disable all of my GFX driver software now every time, which totally resolves the issue.

Search this topic, and you will find many more posts and specifics on slow gen times.

it still took longer than usual, been running for 2 hour now but i decided to cancel it and reuse old output from previous build, idk texgen was running fine tho (only 4 minutes as usual) just dyndolod

[sheson]

8 hours ago, PRieST said:

Edit:
I wrote this, while I started a new generation for the logs and got this message:

[Window Title]
DynDOLOD

[Main Instruction]
Error: OpenGL: 2610CB97 framebuffer incomplete attachment.

[Content]


Click on this link for additional explanations and help for this message

Clean install the latest recommended/WHQL (not optional and not beta) graphics drivers only without any bloatware.

If the issue persists, posts a problem report on the official DynDOLOD support forum.

[Exit DynDOLOD]

[Footer]
Online Help | Support Forum | Copy message to clipboard

This is new and never happened in the past even if I had one or two firefox tabs open.
LODGen is still running (very very slow) - may be because I didn't closed DynDOLOD.exe.
I am using plain nvidia drivers without anything else and also all of my 32GB ram were maxed as well as 100% CPU usage. I have no comparison to earlier generations, but this seems a bit odd, I don't think DynDOLOD/LODGen used all of my ram in the past.

Here are the logs to this point:
No Bugreport.log because I had to manually kill DynDOLOD (it just stayed open).
DynDOLOD/Debug log

__________________________________________________________________________________________________________________________

I know this may be a bit of not so good report, but somehow with alpha 166 the LODGen process is taking ages.
In earlier versions DynDOLOD in whole was finished in about 30 to 40 minutes (including generatin Occlusion.esp).
But now not even Level 4 *.bto of Tamriel are finished - infact it were only about 30 files.

I could provide you the logs to this point, as I don't want to wait hours before DynDOLOD is finished, as this is a new behavior.
This is written in the cmd window:and after that the correspoding finished files (excerpt):

I didn't change anything big since the last generation with alpha 165 which could result in such long generation times. I looked at some created bto files and they also don't seem to be extra large or complex in comparison.
Maybe it's a fault on my end with too many high poly assets, but if this is the case I can't even tell which ones are the culprit.

Texconv and DynDOLOD ran out of vided memory it seems. Probably too many high resolution textures are being worked at the same time.

Add AtlasThreads=X under [DynDOLOD] in D:\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini
Start with X being the physical core count and lower it if problem persists.

Also enforcing to only run one Texconv convertion at a time with LockTexconv=1 should help.

 

Always upload entire logs, also from LODGen. Check if putting this test version of LODgenx64Win.exe in the ..\DynDOLOD\Edit Scripts folder makes a difference https://mega.nz/file/QIBRXTjR#-As4pmm4tn1890E77GuZZqUAcRnxEpka51kPiMsDk-U

[sheson]

6 hours ago, quochunganhphu said:

Dyndolod alpha 166 generated lod a lot longer than usual, it usually took only 45 minutes, but now 4 hours 

Logs:

https://www.mediafire.com/file/25ww5iq0k3ny4zx/Logs.zip/file 

Check if issue is fixed in latest the alpha version

[PRieST]

4 minutes ago, sheson said:

Texconv and DynDOLOD ran out of vided memory it seems. Probably too many high resolution textures are being worked at the same time.

Add AtlasThreads=X under [DynDOLOD] in D:\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini
Start with X being the physical core count and lower it if problem persists.

Also enforcing to only run one Texconv convertion at a time with LockTexconv=1 should help.

 

Always upload entire logs, also from LODGen.
Test if this  text version of LODgenx64Win.exe makes a difference https://mega.nz/file/QIBRXTjR#-As4pmm4tn1890E77GuZZqUAcRnxEpka51kPiMsDk-U

As said, this never happened before and also not with alpha 165. I see that it runs out of memory. With the regular version one LODGen process used up to 24GB of ram alone.
I think the 'run out of memory' was just at that time of the atlas creation, this didn't happened another time I ran DynDOLOD, so it was a one timer (because of tha ram usage spikes).

I am testing the test version right now. It's still running, but I can tell, that the generation of the bto files is fast again and the ram usage stays quite low.

Also it seems I am not the only one having these problems:

3 hours ago, quochunganhphu said:

it still took longer than usual, been running for 2 hour now but i decided to cancel it and reuse old output from previous build, idk texgen was running fine tho (only 4 minutes as usual) just dyndolod

[sheson]

1 minute ago, PRieST said:

As said, this never happened before and also not with alpha 165. I see that it runs out of memory. With the regular version one LODGen process used up to 24GB of ram alone.
I think the 'run out of memory' was just at that time of the atlas creation, this didn't happened another time I ran DynDOLOD, so it was a one timer (because of tha ram usage spikes).

I am testing the test version right now. It's still running, but I can tell, that the generation of the bto files is fast again and the ram usage stays quite low.

The out of memory error happened while generating the atlas texture for Solstheim. Hence the suggestion to limit the number of threads used for the atlas texture generation, so it works on less textures at the same time. The execution order and parallelism of things are not consistent across runs. Memory is a finite resource used by all processes shown in Windows task manager.

[PRieST]

5 minutes ago, sheson said:

The out of memory error happened while generating the atlas texture for Solstheim. Hence the suggestion to limit the number of threads used for the atlas texture generation, so it works on less textures at the same time. The execution order and parallelism of things are not consistent across runs. Memory is a finite resource used by all processes shown in Windows task manager.

With the test version DynDOLOD was finished in 20 minutes without any errors. Exchanging the exe file you provided was the only change I made.