DynDOLOD 3.00 Alpha 190

[RamboLeeNorris7]

Good evening!

I get the following error when running DynDolod (xLODGEN and TextGen seemed to go smoothly. Attempting Seasons of Skyrim and Unfrozen Skyrim for the first time).

Error: Checking for errors failed Access violation at address 00000000006B1EAC in module 'DynDOLODx64.exe' (offset 11EAC). Read of address FFFFFFFFFFFFFFFF for Complete Crafting Overhaul_Remastered.esp MineOreIron01_LSnowRocks "Iron Ore Vein" [ACTI:0010D05C]

 

Not sure how to fix. I've searched the forums, and can't find a consistent answer. 

 

Here is my debug_log.txt (consolidated due to size): https://pastebin.com/CeaqVTVz

Here is my bugreport.txt (full file): https://pastebin.com/Q1YpfLtj

Here is my log.txt (consolidated due to size): https://pastebin.com/dQHkvwJ9

 

Thanks in advance to anyone willing to help!

[sheson]

  On 4/7/2025 at 9:10 PM, z929669 said:

The three grasses produced when Texture size Min=64 relative to Texture size Min=32:

1. fieldgrasstu (8)_00000808.txt
2. icegrassw9_00000d92.txt
3. icegrassw11_00000804.txt

TexGen_minSize32_logs.7z

TexGen_minSize64_logs.7z

All testing done using your modified TexGen version from this post.

Expand  

The three grasses  are skipped because the ratio of opaque pixels to transparent pixels is too low and not because of size or resolution.

Forcing higher min size will typically just waste video memory since the game will probably never use the highest resolution mipmap. In case of these grasses the used mipmap will probably not have many opaque pixels if any. Also possible higher performance requirements due to overdraw. You should check the mipmaps on the object LOD atlas of these particular grass LOD billboard and how the grass LOD with them looks in the game.

https://dyndolod.info/Help/TexGen#Min-Max-texture-size
There is typically no point in raising the texture size Min of billboards as long as the units per pixel is used as intended to achieve sane texture resolutions for billboards.

See https://dyndolod.info/Help/Texture-Resolution#Determine-Sensible-Texture-Resolutions to test if the largest mipmap is used.

[sheson]

  On 4/7/2025 at 11:25 PM, Jonado said:

I am having some strange issues with the latest version of DynDOLOD:

1. When starting the game from an interior, the world map looks weird (with Seasons of Skyrim). It looks like the game is trying to load the seasonal map at the same time as the default map, see the attached screenshot. To fix the issue, I have to enter an exterior, save the game, and then restart it (then it looks like in the second image). I have packed all seasonal LOD files (terrain and object lods) in bsas to save disk space, while the regular files are retained as loose files. I have done this for convenience, so I can load all LODs in the Creation Kit without extra steps. I don't know why that would matter though.
2. Some LOD objects don't appear snowy in winter, despite that the base objects have snow on them. See screenshot. If I walk to the pier, those objects will get back the snow.

Logs can be found here: Logs.7z

Expand  

1. It looks like in the first in the first screenshot the terrain LOD for winter was not loaded. What rudimentary troubleshooting have you done to verify this is caused by the DynDOLOD output not another mod (e.g. SOS) or a maybe mod/game INI settings? See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Rudimentary-Troubleshooting. See https://dyndolod.info/FAQ#Pack-DynDOLOD-Resources-or-generated-output-into-BSA.

2. This is dynamic LOD. Also upload ..\Seasons\DynDOLOD_WIN.ini from the DynDOLOD output and ..\Seasons\MainFormSwap_WIN.ini if it exists or report that Ignore auto generated WIN formswap = true was set in ..\SKSE\Plugins\po3_SeasonsOfSkyrim.ini

[sheson]

  On 4/8/2025 at 3:19 AM, RamboLeeNorris7 said:

Good evening!

I get the following error when running DynDolod (xLODGEN and TextGen seemed to go smoothly. Attempting Seasons of Skyrim and Unfrozen Skyrim for the first time).

Error: Checking for errors failed Access violation at address 00000000006B1EAC in module 'DynDOLODx64.exe' (offset 11EAC). Read of address FFFFFFFFFFFFFFFF for Complete Crafting Overhaul_Remastered.esp MineOreIron01_LSnowRocks "Iron Ore Vein" [ACTI:0010D05C]

 

Not sure how to fix. I've searched the forums, and can't find a consistent answer. 

 

Here is my debug_log.txt (consolidated due to size): https://pastebin.com/CeaqVTVz

Here is my bugreport.txt (full file): https://pastebin.com/Q1YpfLtj

Here is my log.txt (consolidated due to size): https://pastebin.com/dQHkvwJ9

 

Thanks in advance to anyone willing to help!

Expand  

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which entire log (complete last session) and entire debug log from DynDOLOD to upload when making posts.

See https://stepmodifications.org/forum/topic/20141-dyndolod-300-alpha-182/page/676/#findComment-283035 about the mineorescript.pex being overwritten.

[z929669]

  On 4/8/2025 at 6:57 AM, sheson said:

The three grasses  are skipped because the ratio of opaque pixels to transparent pixels is too low and not because of size or resolution.

Forcing higher min size will typically just waste video memory since the game will probably never use the highest resolution mipmap. In case of these grasses the used mipmap will probably not have many opaque pixels if any. Also possible higher performance requirements due to overdraw. You should check the mipmaps on the object LOD atlas of these particular grass LOD billboard and how the grass LOD with them looks in the game.

https://dyndolod.info/Help/TexGen#Min-Max-texture-size
There is typically no point in raising the texture size Min of billboards as long as the units per pixel is used as intended to achieve sane texture resolutions for billboards.

See https://dyndolod.info/Help/Texture-Resolution#Determine-Sensible-Texture-Resolutions to test if the largest mipmap is used.

Expand  

I assumed the cause was something like this and that the higher min resolution might provide a bit more usable data for these three grasses. Please review the screen compares I made for this change (very first set) as evidence that there is a qualitative difference in game. Whether or not the outcome in game is higher resolution is difficult to tell, and whether or not it's an improvement is subjective.

I will look at the mips on the atlas and share results when I have more time, but here's links to the two atlases in the meantime if you want to have a look. Perhaps I could use the MipMapTests variable to glean something further in addition to manual assessment?

64

32

[sheson]

  On 4/8/2025 at 12:10 PM, z929669 said:

I assumed the cause was something like this and that the higher min resolution might provide a bit more usable data for these three grasses. Please review the screen compares I made for this change (very first set) as evidence that there is a qualitative difference in game. Whether or not the outcome in game is higher resolution is difficult to tell, and whether or not it's an improvement is subjective.

I will look at the mips on the atlas and share results when I have more time, but here's links to the two atlases in the meantime if you want to have a look. Perhaps I could use the MipMapTests variable to glean something further in addition to manual assessment?

64

32

Expand  

The mipmap test helps answering the question if the larger resolution is used in the game.

[Jonado]

  On 4/8/2025 at 7:42 AM, sheson said:

1. It looks like in the first in the first screenshot the terrain LOD for winter was not loaded. What rudimentary troubleshooting have you done to verify this is caused by the DynDOLOD output not another mod (e.g. SOS) or a maybe mod/game INI settings? See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Rudimentary-Troubleshooting. See https://dyndolod.info/FAQ#Pack-DynDOLOD-Resources-or-generated-output-into-BSA.

2. This is dynamic LOD. Also upload ..\Seasons\DynDOLOD_WIN.ini from the DynDOLOD output and ..\Seasons\MainFormSwap_WIN.ini if it exists or report that Ignore auto generated WIN formswap = true was set in ..\SKSE\Plugins\po3_SeasonsOfSkyrim.ini

Expand  

1. It affects both object LOD and terrain LOD (but I guess terrain LOD to a larger degree). If you look carefully, some objects have snow on them in the second sceenshot, but not in the first one. In some other areas, almost no objects had snow. Also, seasonal LOD shows up fine in game, it is just the map that is affected. And I have not experienced this before. I don't know whether this is directly related to DynDOLOD, but how would I troubleshoot it? It is obviously related to seasonal LOD, and as far as I know I need DynDOLOD in order for seasonal LOD to function. I guess it could be an issue with Seasons of Skyrim, but then I don't know how to fix it. powerofthree is notoriously difficult to get in touch with.

2. I'll send you my entire Seasons folder, because I have a lot of seasonal config files. These include WIP files for mods that I have not published yet, so please don't share this outside this forum (I will likely also take it down when you have had a look): Seasons.7z. The autogenerated formswap has been disabled. What I can tell though is that there should be nothing in there that touches those references. What I suspect has happened is that the MATO has failed to apply to those objects, which I know from experience sometimes happens with Seasons of Skyrim (I don't know what is causing it though). The console tells that DynDOLOD uses a different mesh for the LOD object - therefore I suspect SoS is not able to apply snow to that mesh. Normally, I would solve that by creating a new object based on that mesh and with a snow shader applied to it, and then use a custom form swap for it. But since it in this case only affects the LOD object and not the regular object, that is a route I would rather avoid if possible.

Also, why is it not supported to packing generated output as BSAs (I only packed the meshes and textures, not anything SKSE related, mind you)? The base game has its terrain and object LOD packed in BSAs, and that works perfectly, so I think this is a relevant question.

[sheson]

  On 4/8/2025 at 11:42 PM, Jonado said:

1. It affects both object LOD and terrain LOD (but I guess terrain LOD to a larger degree). If you look carefully, some objects have snow on them in the second sceenshot, but not in the first one. In some other areas, almost no objects had snow. Also, seasonal LOD shows up fine in game, it is just the map that is affected. And I have not experienced this before. I don't know whether this is directly related to DynDOLOD, but how would I troubleshoot it? It is obviously related to seasonal LOD, and as far as I know I need DynDOLOD in order for seasonal LOD to function. I guess it could be an issue with Seasons of Skyrim, but then I don't know how to fix it. powerofthree is notoriously difficult to get in touch with.

2. I'll send you my entire Seasons folder, because I have a lot of seasonal config files. These include WIP files for mods that I have not published yet, so please don't share this outside this forum (I will likely also take it down when you have had a look): Seasons.7z. The autogenerated formswap has been disabled. What I can tell though is that there should be nothing in there that touches those references. What I suspect has happened is that the MATO has failed to apply to those objects, which I know from experience sometimes happens with Seasons of Skyrim (I don't know what is causing it though). The console tells that DynDOLOD uses a different mesh for the LOD object - therefore I suspect SoS is not able to apply snow to that mesh. Normally, I would solve that by creating a new object based on that mesh and with a snow shader applied to it, and then use a custom form swap for it. But since it in this case only affects the LOD object and not the regular object, that is a route I would rather avoid if possible.

Also, why is it not supported to packing generated output as BSAs (I only packed the meshes and textures, not anything SKSE related, mind you)? The base game has its terrain and object LOD packed in BSAs, and that works perfectly, so I think this is a relevant question.

Expand  

1. If you pack LOD files into BSA any problem is your own responsibility. In case of problems, the first troubleshooting step is to use loose LOD files. It looks like in the first screenshot the terrain LOD for winter was not loaded while in the second it was. DynDOLOD does not generate or modify terrain LOD. DynDOLOD/xLODGen do not change how the game loads and displays terrain, object or tree LOD meshes/textures. Disabling DynDOLOD as a test should not affect any terrain LODs or problems with it caused by third party mods or settings. SOS has no hard requirement for DynDOLOD object LOD meshes to be in the load order (the description of SOS says "Seasons will fallback to using default LOD if these DynDOLOD/LODGen generated LOD files are not found."). It should still switch the seasonal terrain LOD regardless. AFAIK it should support loading from BSA. Check the po3_SeasonsOfSkyrim.log for what it reports.

2. It seems SOS does not apply the automatic snow shader, presumably because the model the path contains 'LOD\'. The LOD model itself works fine with the auto snow shader if moved somewhere else. Adding an entry under Multipass Snow Whitelist did not seem to work, looks like the internal blacklist takes precedence. I will try to address this in one of the next alphas, either by using the full model or adding a winter variant base record with the snow LOD shader.

[godescalcus]

  On 6/28/2024 at 8:48 PM, sheson said:

https://dyndolod.info/Help/Child-Parent-Worldspace-Copies
Walled cities like Solitude, Riften, Whiterun, Windhelm etc. are child worldspaces that are embedded into the Tamriel parent worldspace that they use for LOD.
The Child > parent option copies references that could have LOD from the child worldspaces to the parent worldspace.
The Parent > child option copies references that have LOD from the parent worldspace to the child worldspaces.

The Child > parent option makes sure that things only added to the inside of city can also be seen from the outside.
The Parent > child option makes sure that things can also be seen when inside a city and peeking past the walls.

Expand  

I use two mods - Whiterun Dibella Club and Solitude Arena - and have previously generated LOD with them without issues, but now I get these LODs overlapping when in the Tamriel worldspace. I disabled Parent>Child despite the barrenness because it also projected the outside walls in into the modified Whiterun and Solitude worldspaces, but I can't completely disable Child>Parent. Can this be turned off elsewhere, or perhaps the plugins that add these features can be set to be ignored?

[sheson]

  On 4/10/2025 at 1:31 PM, godescalcus said:

I use two mods - Whiterun Dibella Club and Solitude Arena - and have previously generated LOD with them without issues, but now I get these LODs overlapping when in the Tamriel worldspace. I disabled Parent>Child despite the barrenness because it also projected the outside walls in into the modified Whiterun and Solitude worldspaces, but I can't completely disable Child>Parent. Can this be turned off elsewhere, or perhaps the plugins that add these features can be set to be ignored?

Expand  

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts. Provide links to mentioned mods.

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make useful screenshots of references with more informative console.

https://dyndolod.info/FAQ#Out-of-place-or-floating-objects
Some mods are made with disregard to generating LOD or require updated rules and configs for best compatibility. This is especially true for mods modifying the walled cities. Users are asked and welcome to provide feedback to the official DynDOLOD support forum in order to get everything working with as much compatibility as possible. Include a link to the mod and screenshots (with open console / form id) to show the issues if possible. If the reference is added by a DynDOLOD plugin, follow the "pluginname_formid" information found in the Editor ID of the reference to find the plugin from which this reference originates. Also see Child/Parent Worldspace Copies and How to ignore all references of a child worldspace for copying to parent worldspace and LOD.

https://dyndolod.info/Mod-Authors#How-to-ignore-all-references-of-a-child-worldspace-for-copying-to-parent-worldspace-and-LOD
To disable this scan for a specific plugin and worldspace, create a rule file for the plugin in the ..Data\DynDOLOD\ folder as explained above. Add a new section [Skyrim Settings] and a new line line IgnoreWorlds=[List of worldspace Editor IDs]. For example:
[Skyrim Settings]
IgnoreWorlds=WhiterunWorld,SolitudeWorld

For example "DynDOLOD_SSE_WhiterunDibellaClubesp.ini" with [Skyrim Settings] IgnoreWorlds=WhiterunWorld
For example "DynDOLOD_SSE_SolitudeArenaesp.ini" with [Skyrim Settings] IgnoreWorlds=SolitudeWorld

[Jonado]

I am getting snow on some seasonal LOD objects that are not supposed to have it. See screenshots (left one is close-up view, the right one is when viewed from a distance). This time I think I know what is going on, and it is likely a bug on the DynDOLOD side. Searching for 0200CE5E in the debug log tells me that the object is getting swapped to GlacierRubbleTrim02 (FormID 00065CA2) in summer. Well, you can see from the screenshot that this is not correct, so I did a file search for that form swap. It turns out the only reference to it is in the file zzz_Icebergs_SUM.ini.vortex_backup, i.e. a backup copy of a Seasons config file, which is not used by Seasons of Skyrim. I can of course remove the file to fix the issue (I don't really need it), but since Vortex tends to create backup copies like that, I thought it is better you fix this on the DynDOLOD end.

Logs can be found here: Logs.7z

[Vingen]

Hello, I'm encountering an issue where Dyndolod closes prematurely during the processing of Skyrim.esm (Tamriel). I followed BiggieBoss's guide for using xLodgen, Texgen, and Dyndolod. The problem always occurs at the same point, when processing Skyrim.esm. (I also use vortex and game version 1.5.9.7)

I’ve already tried the following solutions:

• Running Dyndolod as an administrator

• Adding an exception in Windows Defender and Firewall

• Using Dyndolod both with and without xLodgen

• Lowering settings to low

• Running Dyndolod with and without the DLL

• Setting LockTexconv=1 and RenderSingle=1

• Reinstalling Dyndolod

Despite these attempts, Dyndolod still crashes at the same point. I've noticed that the RAM usage never gets close to my system’s maximum, so it doesn't seem like a memory issue. Additionally, there’s no log in Windows Event Viewer related to the crash. These are my logs: https://ufile.io/rq6dq4bk, https://ufile.io/0lkeq2xb, https://ufile.io/6it8bd5q

Any suggestions or insights would be greatly appreciated!

[sheson]

  On 4/11/2025 at 1:18 PM, Vingen said:

Hello, I'm encountering an issue where Dyndolod closes prematurely during the processing of Skyrim.esm (Tamriel). I followed BiggieBoss's guide for using xLodgen, Texgen, and Dyndolod. The problem always occurs at the same point, when processing Skyrim.esm. (I also use vortex and game version 1.5.9.7)

I’ve already tried the following solutions:

• Running Dyndolod as an administrator

• Adding an exception in Windows Defender and Firewall

• Using Dyndolod both with and without xLodgen

• Lowering settings to low

• Running Dyndolod with and without the DLL

• Setting LockTexconv=1 and RenderSingle=1

• Reinstalling Dyndolod

Despite these attempts, Dyndolod still crashes at the same point. I've noticed that the RAM usage never gets close to my system’s maximum, so it doesn't seem like a memory issue. Additionally, there’s no log in Windows Event Viewer related to the crash. These are my logs: https://ufile.io/rq6dq4bk, https://ufile.io/0lkeq2xb, https://ufile.io/6it8bd5q

Any suggestions or insights would be greatly appreciated!

Expand  

Load the load order into xEdit, let it build the reference cache for every plugin, then check all non vanilla plugins for errors. See if that runs through.

[Vingen]

  On 4/11/2025 at 2:48 PM, sheson said:

Load the load order into xEdit, let it build the reference cache for every plugin, then check all non vanilla plugins for errors. See if that runs through.

Expand  

Hey, thanks for the quick response! I finished checking for errors in xEdit — it processed over 1.3 million records and found around 52,000 errors. I’m not totally sure how to interpret all of them. Is there a specific type of error I should be looking out for? Or should I try disabling any mods that show a large number of these warnings?

This is the log: https://filebin.net/hj01cad2t88bk3ck (ufile stopped working for me)

[sheson]

  On 4/11/2025 at 4:02 PM, Vingen said:

Hey, thanks for the quick response! I finished checking for errors in xEdit — it processed over 1.3 million records and found around 52,000 errors. I’m not totally sure how to interpret all of them. Is there a specific type of error I should be looking out for? Or should I try disabling any mods that show a large number of these warnings?

This is the log: https://filebin.net/hj01cad2t88bk3ck (ufile stopped working for me)

Expand  

Upload the entire load log starting from the first line SSEEdit ... starting session

Are you using a recent version of xEdit? Get 4.1.5m from #xedit-builds channel of the xEdit Discord. Redo the error check in case you used an older version.

Start xEdit enter 000094E2 top left and hit enter to open the cell record -5,6 in Tamriel. Do the same with 000094E3 for -6,6.
Check if they look OK. Report which are the last plugins (most right) to overwrite them.