DynDOLOD 3.00 Alpha 182

[vrnord]

Idea/request for a possible future update: Billboard 2 looks more convincingly like full models from a distance to me, but when it is backlit by the sun (morning or evening, using the billboard model's soft-lighting shader) the illusion is broken because the bits that are supposed to be dark or opaque (shadows and the trunk) light up as much as the leaves/needles that should actually have some subsurface scattering.  This is especially noticeable with snowy pines, because all the white snow on the branches starts to basically glow and look translucent. 

This is because the billboard model reuses the diffuse texture in slot3, and the diffuse image seems to be captured by Texgen using frontal lighting (looks like bright daytime).  My suggestion is to use a new 3rd texture in the 3rd slot of the billboard models, which would also generated by Texgen (so texture.dds in slot 1, texture_n.dds in slot 2 and texture_sk.dds in slot 3).  That new *_sk.dds texture would be captured using lighting that more closely simulates backlighting - so trunks and shadows are darker and thus less illuminated by the soft lighting shader when backlit.  See below screenshots for the Nifskope lighting settings I found most closely resembled backlighting (backlit subsurface scattering version on left, daytime normal lighting for diffuse on right):

 

Thanks for considering and for all your work on Dyndolod!

[drift123]

I have some questions...

Do dynamic window lights on Whiterun castle work if I select upper right Medium rules for Candles and FX Glow, but keep Glow Window and High checked in the lower section? Or do I have to use High rules at the top right for dynamic lights to function?

The grass precache and grass LOD's seemed to be working, except there is a color mismatch between the LOD grass being green and the loaded cell grass being more brown/yellow. What is the best way to fix this?

I also had a warning about ELFX missing a mesh called "Warning: File not found Meshes\effects\elfx\candlelanternwithcandle02.nif. Used by EnhancedLightsandFX.esp". I'm not sure how to fix this or if it needs fixing at all.

Is it better to use the Alpha 3 or Beta version at this time?

[sheson]

3 hours ago, drift123 said:

I have some questions...

Do dynamic window lights on Whiterun castle work if I select upper right Medium rules for Candles and FX Glow, but keep Glow Window and High checked in the lower section? Or do I have to use High rules at the top right for dynamic lights to function?

The grass precache and grass LOD's seemed to be working, except there is a color mismatch between the LOD grass being green and the loaded cell grass being more brown/yellow. What is the best way to fix this?

I also had a warning about ELFX missing a mesh called "Warning: File not found Meshes\effects\elfx\candlelanternwithcandle02.nif. Used by EnhancedLightsandFX.esp". I'm not sure how to fix this or if it needs fixing at all.

Is it better to use the Alpha 3 or Beta version at this time?

The Glow windows and the High checkboxes are their own discrete options that have nothing to do with mesh rules, loading mesh rule candles or rules for FX glow. Look at the advanced mode interface how these options are separated, hover the mouse to see hints and read the explanations that open when clicking the Help button: https://dyndolod.info/Help/Advanced-Mode

Since Glow LOD windows are not the same as candles or FX glow, they all have their own checkboxes (hover for hints) and explanations. Click the Help button to open https://dyndolod.info/Help/Advanced-Mode and click also see https://dyndolod.info/Help/Glow-LOD.

https://dyndolod.info/Help/Grass-LOD#Settings
In case the grass LOD brightness or color seems off (it might depend on weathers or ENB settings), try different Direct/Ambient settings for grass LOD billboards in TexGen. In addition or alternatively change the GrassBrightnessTop*/ComplexGrassBrightnessTop* and GrassBrightnessBottom*/ComplexGrassBrightnessBottom* settings in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini - those settings help if the color tone is off. Especially the image based lighting effect from ENB has a big impact on the brightness and color tone of the grass LOD. Additional complex grass lighting and time of day settings will obviously not apply to object LOD, as they are separate meshes and shaders. Do not use them so full grass and grass LOD match better for all weathers/times.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which entire DynDOLOD log and debug log to upload instead of posting only parts of the logs or pieces of a single log line or messages.

See https://dyndolod.info/Messages/File-Not-Found-Meshes. It also explains how to check if a mesh is required or not and gives hints how to fix the file not found error.

Typically it is "better" to use the latest DynDOLOD 3 Alpha version, for current game and mod support and to help to improve and develop it quicker. The answer also depends on the user goals and what is installed.

[Jonado]

On 3/24/2024 at 10:14 PM, sheson said:

The debug log is saved and replaces the old debug log when the tool is shutting down. Let the tool close on its own, do not terminate it via X for example. Delete the log folder for a new session, so there are no write protected files or files in use preventing overwriting them.

In order to properly troubleshot the issue, provide updated log, debug log, object report all for the same LOD generation session.
Provide links to the mods where I can download them. send links to private mods/uploads via PM if needed.

Also upload ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_Tamriel.txt and LODGen_SSE_Export_Tamriel_WIN.txt

Hi, I have finally been able to produce a valid debug log (took me two attempts, and I didn't have the patience to rerun it when DynDOLOD again failed to produce a debug log, hence the wait). To recap, the issue was a badly mismatched LOD model during winter, likely due to something breaking after applying mesh mask rules. The issue still persists. You are probably able to get the details by backtracking the conversation. The log files and other requested files can be found here: https://www.dropbox.com/scl/fi/ef90b9t3zloufid6620xn/Logs.7z?rlkey=nnt7uh9ohtanmkzlqktnsttdx&dl=0

I also reported that a certain building was not showing up on the map, despite having proper LOD models and the level 4 and level 8 LODs being successfully generated. That issue remains too. I have a bit more information on the issue, though, having found no less than six objects which suffer from the same issue (the list is likely not exhaustive). See the list below (with examples of references in parenthesis):

RTKeep01.nif (e.g. 00080C57)
RTFarmhouse01.nif (e.g. 167A~RiftenExtension.esp)
RTFarmhouse02.nif (e.g. 16A7~RiftenExtension.esp)
RTStables01.nif (e.g. 000BB7B4)
CWTower01.nif (e.g. 7EDC~Bells of Skyrim - OCS Patch.esp)
SHouseForSale.nif (e.g. 0008E2CA)

All of these meshes have specific form swaps for winter. Interestingly, three of them, RTFarmHouse02WIN.nif, RTStables01Snow.nif, and CWTower01Snow.nif do have level 16 LOD, despite using the same LOD meshes as the base objects (or copies thereof). I don't know whether it is related to the issue.

Edited May 31 by Jonado

[sheson]

6 hours ago, Jonado said:

Hi, I have finally been able to produce a valid debug log (took me two attempts, and I didn't have the patience to rerun it when DynDOLOD again failed to produce a debug log, hence the wait). To recap, the issue was a badly mismatched LOD model during winter, likely due to something breaking after applying mesh mask rules. The issue still persists. You are probably able to get the details by backtracking the conversation. The log files and other requested files can be found here: https://www.dropbox.com/scl/fi/ef90b9t3zloufid6620xn/Logs.7z?rlkey=nnt7uh9ohtanmkzlqktnsttdx&dl=0

I also reported that a certain building was not showing up on the map, despite having proper LOD models and the level 4 and level 8 LODs being successfully generated. That issue remains too. I have a bit more information on the issue, though, having found no less than six objects which suffer from the same issue (the list is likely not exhaustive). See the list below (with examples of references in parenthesis):

RTKeep01.nif (e.g. 00080C57)
RTFarmhouse01.nif (e.g. 167A~RiftenExtension.esp)
RTFarmhouse02.nif (e.g. 16A7~RiftenExtension.esp)
RTStables01.nif (e.g. 000BB7B4)
CWTower01.nif (e.g. 7EDC~Bells of Skyrim - OCS Patch.esp)
SHouseForSale.nif (e.g. 0008E2CA)

All of these meshes have specific form swaps for winter. Interestingly, three of them, RTFarmHouse02WIN.nif, RTStables01Snow.nif, and CWTower01Snow.nif do have level 16 LOD, despite using the same LOD meshes as the base objects (or copies thereof). I don't know whether it is related to the issue.

DynDOLOD saves the debug log right after the normal log. Simply let it close/shut down normally. It can take a while.

No mods or links to mods were provided.
No useful screenshots were provided. https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots
No base record form IDs were provided.

Read https://dyndolod.info/Installation-Instructions and https://dyndolod.info/Updating#New-DynDOLOD-Version. Do not install newer versions over older versions.

I assume for all listed references, the issue is both, the winter LOD does not match and no LOD on the map when the season is winter?

00080C57
swapped to base record to 844~SoS_Seasonspatch_Riften.esp from Simplicity of Seasons? CRC32 of plugin does not match Simplicity of Seasons 1.4.1?
Full model rtkeep01snow.nif CRC32 dos not match Simplicity of Seasons 1.4.1?
LOD uses vanilla LOD model and should have snow cover via the snow LOD shader in winter LOD.
With the current default rules there is no LOD model defined for LOD level 16 for default or winter seasons. so it expected the it does not show in the map. Create a custom rule that sets Level1 to LOD Level 16 to show it on the map.

167A~RiftenExtension.esp
swapped to base record to 83A~SoS_Seasonspatch_Riften.esp from Simplicity of Seasons? CRC32 of plugin does not match Simplicity of Seasons 1.4.1?
Full model rtfarmhouse01snow.nif CRC32 dos not match Simplicity of Seasons 1.4.1?
LOD uses vanilla LOD model and should have snow cover via the snow LOD shader in winter LOD.
With the current default rules there is no LOD model defined for LOD level 16, so it expected the it does not show in the map. Create a custom rule that sets Level1 to LOD Level 16 to show it on the map.

167A~RiftenExtension.esp
swapped to base record to BBD~Seasonal Landscapes - SoS_Seasons patch.esp, unclear what mod the plugin is from.
Full model rtfarmhouse02win.nif, unclear what mod it is from.
LOD uses vanilla LOD model and should have snow cover via the snow LOD shader in winter LOD.
With the current default rules there is no LOD model defined for LOD level 16, so it expected the it does not show in the map.  Create a custom rule that sets Level1 to LOD Level 16 to show it on the map.

000BB7B4
swapped to base record to 86C~SoS_Seasonspatch_Riften.esp from Simplicity of Seasons? CRC32 of plugin does not match Simplicity of Seasons 1.4.1?
Full model rtstables01snow.nif CRC32 dos not match Simplicity of Seasons 1.4.1?
LOD uses rtstables01snow_lod.nif, unclear what mod it comes from.
LOD has snow cover via the snow LOD shader.  LOD model defined for Level 16, so It should show on the winter map.

7EDC~Bells of Skyrim - OCS Patch.esp
Reference form id not found in any logs

0008E2CA
swapped to base record to 889~SoS_Seasonspatch_Solitude.esp from Simplicity of Seasons? CRC32 of plugin does not match Simplicity of Seasons 1.4.1?
Full model shouseforsalesnow.nif CRC32 dos not match Simplicity of Seasons 1.4.1?
LOD uses "vanilla" LOD model from DynDOLOD Resources and should have snow cover via the snow LOD shader in winter LOD.
With the current default rules there is no LOD model defined for LOD level 16, so it expected the it does not show in the map.  Create a custom rule that sets Level1 to LOD Level 16 to show it on the map.

All the swapped full models (minus the rtfarmhouse02win.nif) I have here from Simplicity of Seasons, do not contain 3D snow covers. The snow cover for the full model always seems to be realized via using a snow shader. So in that regard the default LOD models using the snow LOD shader should match?

[drift123]

I have a question about the Preset rules Low, Medium and High. If I check Candles and FXGlow and then click High preset, I presume it loads all mesh rules for High preset, including the Candles and FXGlow.

If I click first Medium preset, and then check Candles and FXGlow, and then click High preset. Will it override the Medium Preset changes and make them all high? Or will it only change the Candles and FXGlow rules to high?

Or for example, if I select the High preset, and then check Candles and FX Glow, and then click Medium preset, will it change all rules to medium, including the Candles and FX Glow rules? Or will I get a combination of High rules for Candles/FX Glow and Medium rules for other meshes?

The other thing is, what is the difference between Vanilla window glow and the Dyndolod with Glow Window + High checked (lower section)? When I disabled Dyndolod Output I could still see the Whiterun castle glow and it would turn off in the daytime on a new save. I'm not sure if that is because of the ELFX mod or if Vanilla has dynamic window glow on Whiterun castle by default.

Edited June 1 by drift123

[sheson]

15 minutes ago, drift123 said:

I have a question about the Preset rules Low, Medium and High. If I check Candles and FXGlow and then click High preset, I presume it loads all mesh rules for High preset, including the Candles and FXGlow.

If I click first Medium preset, and then check Candles and FXGlow, and then click High preset. Will it override the Medium Preset changes and make them all high? Or will it only change the Candles and FXGlow rules to high?

Or for example, if I select the High preset, and then check Candles and FX Glow, and then click Medium preset, will it change all rules to medium, including the Candles and FX Glow rules? Or will I get a combination of High rules for Candles/FX Glow and Medium rules for other meshes?

https://dyndolod.info/Help/Advanced-Mode#Low-Medium-or-High-Preset-Buttons
All existing rules will be replaced.

https://dyndolod.info/Help/Advanced-Mode#Candles-FXGlow
The check boxes activate rules for Candles and FXGlow.
These rules will be loaded when clicking any of the low, medium or high preset buttons.

As explained, clicking Low, Medium or High will always replace all existing rules. It will then load the rule files that match the selected preset and any files without any preset identifier or _all in the filename.

[Jonado]

7 hours ago, sheson said:

No mods or links to mods were provided.
No useful screenshots were provided. https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots
No base record form IDs were provided.

I did provide detailed information further up in the thread. Let me dig it up for you:

On 3/19/2024 at 12:08 AM, Jonado said:

I found some other LOD issues from the same generation. For some reason, I am getting a total mismatch for the LOD model for sbluepalacegate.nif during winter (but during the other seasons it looks fine). I am using a custom form swap for this object during winter, but the replacement is using the same mesh. I tried using mesh mask rules to get LOD for this building, perhaps I screwed something up? The generated object LOD mesh can be found here, please tell me if you need anything else: https://www.dropbox.com/scl/fi/yui7f3dhiqo5y62eylu30/Tamriel.4.-16.24.WIN.bto?rlkey=fohj4dpjul471rmn3e4i13afh&dl=0

On 3/24/2024 at 1:25 AM, Jonado said:

All the logs are here, just as they were before: https://www.dropbox.com/scl/fi/ef90b9t3zloufid6620xn/Logs.7z?rlkey=nnt7uh9ohtanmkzlqktnsttdx&dl=0. I have added the object report log to the zip file too now. I can see if I can upload some screenshots later, but it at least affects the reference 0xC938~Open Cities Skyrim.esp and all objects with FormID 000801ED.

This should also help:

On 3/24/2024 at 9:01 AM, sheson said:

What mod are  SoS_Seasonspatch_Solitude.esp and SoS_Seasons - Vigilant.esp from?

The debug log shows a couple duplicate EditorIDs which should be unique in the load order and can screw with swapping based on EditorIDs
Duplicate editor ID SBluePalaceGateWinter in SoS_Seasons - Vigilant.esp SBluePalaceGateWinter [STAT:FE2A4802] and SoS_Seasonspatch_Solitude.esp SBluePalaceGateWinter [STAT:FE0F2812]>

The object report shows that SBluePalaceGateWinter from SoS_Seasonspatch_Solitude.esp xxyyy812 uses the full model meshes\architecture\solitude\sbluepalacegate.nif for LOD which is most likely not what you want.

On 3/24/2024 at 9:18 PM, Jonado said:

I think this requires some explanation from my side. SoS_Seasonspatch_Solitude.esp is from the mod Simplicity of Seasons, which is an IMO broken mod which I have spent a lot of time in the last months to try to patch up. While working with that I decided to incorporate some of its features (with fixes) into a seasons mod for Vigilant, which I have published on Nexus with the mod name Seasons for Vigilant. As a workaround to avoid my mod to depend on Simplicity of Seasons, and while waiting for my bug fixes to get finished, I simply copied the relevant objects from Simplicity of Seasons to my mod (it should be fine according to the mod's permissions). That is the reason for the duplicate. But I am using FormIDs and not EditorIDs for seasonal swapping, so should it matter?

The full-model swap is likely from the mesh mask rules (the object in Simplicity of Seasons is using the same flags as the base object). I simply copied the rule from a similar line from RedBag's Solitude's custom rules (which I think are incorrectly configured, because that mod does not include any file called SBluePalaceGate.nif). But that should be same as for the non-formswapped object. The mesh mask rules only depend on the mesh, which is the same.

That said, the Simplicity of Seasons meshes have been quite heavily modified by me, and for good reason. rtstables01snow_lod.nif was provided by me, and is a copy of rtstables01_lod.nif from the DynDOLOD resources. rtfarmhouse02win.nif is shipped with the mod Seasons for Vigilant for the time being (but will be published elsewhere later). Anyway, I think this fully explains the issue I am facing:

7 hours ago, sheson said:

With the current default rules there is no LOD model defined for LOD level 16 for default or winter seasons. so it expected the it does not show in the map. Create a custom rule that sets Level1 to LOD Level 16 to show it on the map.

I don't understand why those rules are not set by default, though. Those buildings are big enough that it is noticeable that they do not show up on the map. I am not saying I cannot fix it myself, just that I think it should be a main part of DynDOLOD. If you want, I can add it as a request to the mesh mask rule thread we started a while ago. I also think that it is weird that some of the winter models get different rules than the base models, despite using exactly the same LOD mesh, and having the same LOD rules attached to the object.

Edited June 1 by Jonado

[sheson]

2 hours ago, Jonado said:

I did provide detailed information further up in the thread. Let me dig it up for you:

This should also help:

That said, the Simplicity of Seasons meshes have been quite heavily modified by me, and for good reason. rtstables01snow_lod.nif was provided by me, and is a copy of rtstables01_lod.nif from the DynDOLOD resources. rtfarmhouse02win.nif is shipped with the mod Seasons for Vigilant for the time being (but will be published elsewhere later). Anyway, I think this fully explains the issue I am facing:

I don't understand why those rules are not set by default, though. Those buildings are big enough that it is noticeable that they do not show up on the map. I am not saying I cannot fix it myself, just that I think it should be a main part of DynDOLOD. If you want, I can add it as a request to the mesh mask rule thread we started a while ago. I also think that it is weird that some of the winter models get different rules than the base models, despite using exactly the same LOD mesh, and having the same LOD rules attached to the object.

If you want to report a mismatch between full models and LOD, then provide screenshots of the full model (with more informative console) and the LOD. The reference and base record form ID are required to look things up in the logs.

The "highest" available LOD models in these cases end in *1.nif, which means Level1. The last / rule automatically assigns those to LOD8 max. *2.nif = Level2 is assigned to LOD16 automatically as explained in the documentation. But no such LOD models exist in these cases.

So in this case add mesh rules for these models and set Level1 to LOD16 - choose the partial mesh mask right, a couple rules might be enough to cover all cases and seasons. There are no such rules yet, because nobody reported a problem so far. I will most likely address this in future updates.

[Jonado]

Here you go. The gate has been replaced by a wall of some kind in the object LOD mesh.

As for Level2 LOD models, would it work to simply copy the Level1 models and rename them as *2.nif? That would be easier for me than to mess with the mesh mask rules again. Otherwise I can just wait until you fix it, I am not going to actually play the game in quite a while anyway.

[sheson]

9 hours ago, Jonado said:

Here you go. The gate has been replaced by a wall of some kind in the object LOD mesh.

As for Level2 LOD models, would it work to simply copy the Level1 models and rename them as *2.nif? That would be easier for me than to mess with the mesh mask rules again. Otherwise I can just wait until you fix it, I am not going to actually play the game in quite a while anyway.

LODGen_SSE_Export_Tamriel_WIN.txt
BA00C938 00000000 -52591.691406 101743.687500 -8256.000000 0.000000 0.000000 45.000000 1.000000 XJKBluePaSBluePalaceGateWIN 08000000 Snow Meshes\jk's blue palace\sbluepalacegate.nif Meshes\jk's blue palace\sbluepalacegate.nif Meshes\jk's blue palace\sbluepalacegate.nif

The shown full model reference/base record uses the full model sbluepalacegate.nif for LOD in Level 4 and 8.

Remove that line from LODGen_SSE_Export_Tamriel_WIN.txt and then Execute LODGen in export for Tamriel/Win only with Specfic Chunk=4 W=-16 S=24 to only generate that specific BTO. It should still have that wall. Try to find the actual reference

Whatever you see in the LOD screenshot is caused by a different reference. Use tfc in console to get closer.

https://dyndolod.info/Mod-Authors#How-to-add-your-own-object-LOD-models
The automatic matching assigns the different distant LOD meshes levels based on _[0|1|2|3] part of the filename. To assign models to specific distant LOD meshes levels, use house_lod_0.nif for level 0, house_lod_1.nif for level 1, and house_lod_2.nif for level 2 and house_lod_3.nif for level 3.

However, in this case it is easier, quicker and more compatible to use rules with mesh masks that match entire groups of filenames, since variations exist. For example if the mesh mask is just rtfarmhouse, it will match all vanilla rtfarmhouse01, rtfarmhouse02 and any custom variation added by mods like rtfarmhouse01win, rtfarmhouse02snow, rtfarmhouse03 etc. without having to rename dozen of files.

Just make a rule that looks like the last / rule and enter rtfarmhouse as mesh mask.

[AzraNoxx]

ERROR REPORT
>Note, probably my fault somehow
>Where can I learn how to fix an access violation error in more detail? Or will one of you walk me through it?
 

[Window Title]
DynDOLOD

[Main Instruction]
One or more errors occurred Access violation at address 0040A9FC in module 'DynDOLOD.exe'.

[Content]
Read of address 00000000 Access violation at address 0040A9FC in module 'DynDOLOD.exe'. Read of address 00000000 Access violation at address 0040A9FC in module 'DynDOLOD.exe'. Read of address 00000000 Access violation at address 0040A9FC in module 'DynDOLOD.exe'. Read of address 00000000.

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

For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum.

[OK] [Exit DynDOLOD]

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

See logs.
> Note, I'm having trouble parsing the log reporting instruction, so you get my entire log folder from DynDOLOD.
 Bug Log
_SSE_ChildworldCopies_Tamriel
_SSE_Debug_Log
_SSE_Dynamic_LOD
DynDOLOD_SSE_log
_SSE_ModelsUsed_Tamriel
_SSE_Object_LOD
_SSE_Object_Report
_SSE_Reverse_List
_SSE_TexturesUsed_Tamriel
_SSE_Tree_Export
_SSE_Tree_LOD
_SSE_Tree_Report
LODGen_SSE_Tamriel_log
TexGen_SSE_Debug_log
TexGen_SSE_log

Solutions

Unclear. I'm not sure how to find similar errors or resolve this. The built in link to Exceptions - Access Violations made no sense to me because I'm too new to this.

 

[sheson]

36 minutes ago, AzraNoxx said:

ERROR REPORT
>Note, probably my fault somehow
>Where can I learn how to fix an access violation error in more detail? Or will one of you walk me through it?
 

[Window Title]
DynDOLOD

[Main Instruction]
One or more errors occurred Access violation at address 0040A9FC in module 'DynDOLOD.exe'.

[Content]
Read of address 00000000 Access violation at address 0040A9FC in module 'DynDOLOD.exe'. Read of address 00000000 Access violation at address 0040A9FC in module 'DynDOLOD.exe'. Read of address 00000000 Access violation at address 0040A9FC in module 'DynDOLOD.exe'. Read of address 00000000.

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

For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum.

[OK] [Exit DynDOLOD]

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

See logs.
> Note, I'm having trouble parsing the log reporting instruction, so you get my entire log folder from DynDOLOD.
 Bug Log
_SSE_ChildworldCopies_Tamriel
_SSE_Debug_Log
_SSE_Dynamic_LOD
DynDOLOD_SSE_log
_SSE_ModelsUsed_Tamriel
_SSE_Object_LOD
_SSE_Object_Report
_SSE_Reverse_List
_SSE_TexturesUsed_Tamriel
_SSE_Tree_Export
_SSE_Tree_LOD
_SSE_Tree_Report
LODGen_SSE_Tamriel_log
TexGen_SSE_Debug_log
TexGen_SSE_log

Solutions

Unclear. I'm not sure how to find similar errors or resolve this. The built in link to Exceptions - Access Violations made no sense to me because I'm too new to this.
 

"DynDOLOD.exe"

https://dyndolod.info/Installation-Instructions
Use the x64 versions of DynDOLOD/TexGen.

That means to use TexGenx64.exe and DynDOLODx64.exe

https://dyndolod.info/Messages/Exceptions, also says:
Make sure to use the x64 versions of the tools.

Scrolling to https://dyndolod.info/Messages/Exceptions#Access-violation, also suggests:
This could be low or out of memory problems. Use the x64 version of the tools.

[sheson]

16 hours ago, Jonado said:

Here you go. The gate has been replaced by a wall of some kind in the object LOD mesh.

As for Level2 LOD models, would it work to simply copy the Level1 models and rename them as *2.nif? That would be easier for me than to mess with the mesh mask rules again. Otherwise I can just wait until you fix it, I am not going to actually play the game in quite a while anyway.

I looked some more into this.

There are 2 references adding the palace gate twice:
xx5A004B in BluePalaceTerrace.esp and xx00C938 in Open Cities Skyrim.esp

It probably happens because of conflicting swaps for the same base record (or EditorID) to different new base records in different INIs:

sos_seasonspatch_solitude_win.ini
Season WIN, swapping record Skyrim.esm SBluePalaceGate [STAT:000801ED] to SoS_Seasonspatch_Solitude.esp SBluePalaceGateWinter [STAT:FE12F812

sos_seasons_vigilant_win.ini
Season WIN, swapping record Skyrim.esm SBluePalaceGate [STAT:000801ED] to SoS_Seasons - Vigilant.esp SCWgateWinter [STAT:FE310801]

DynDOLOD loads in the swap INIs in the same order as the plugins and as usual whatever is loaded last wins.

It is possible that Seasons of Skyrim does it different for some reason. If that is the case and actually intended to work differently than usual, then I will change that in DynDOLOD obviously.

In any case, the swap from the palace gate SBluePalaceGate to Solitude main gate SCWgate in sos_seasons_vigilant_win.ini seem wrong anyways.

[Jonado]

14 hours ago, sheson said:

LODGen_SSE_Export_Tamriel_WIN.txt
BA00C938 00000000 -52591.691406 101743.687500 -8256.000000 0.000000 0.000000 45.000000 1.000000 XJKBluePaSBluePalaceGateWIN 08000000 Snow Meshes\jk's blue palace\sbluepalacegate.nif Meshes\jk's blue palace\sbluepalacegate.nif Meshes\jk's blue palace\sbluepalacegate.nif

The shown full model reference/base record uses the full model sbluepalacegate.nif for LOD in Level 4 and 8.

Remove that line from LODGen_SSE_Export_Tamriel_WIN.txt and then Execute LODGen in export for Tamriel/Win only with Specfic Chunk=4 W=-16 S=24 to only generate that specific BTO. It should still have that wall. Try to find the actual reference

Whatever you see in the LOD screenshot is caused by a different reference. Use tfc in console to get closer.

https://dyndolod.info/Mod-Authors#How-to-add-your-own-object-LOD-models
The automatic matching assigns the different distant LOD meshes levels based on _[0|1|2|3] part of the filename. To assign models to specific distant LOD meshes levels, use house_lod_0.nif for level 0, house_lod_1.nif for level 1, and house_lod_2.nif for level 2 and house_lod_3.nif for level 3.

However, in this case it is easier, quicker and more compatible to use rules with mesh masks that match entire groups of filenames, since variations exist. For example if the mesh mask is just rtfarmhouse, it will match all vanilla rtfarmhouse01, rtfarmhouse02 and any custom variation added by mods like rtfarmhouse01win, rtfarmhouse02snow, rtfarmhouse03 etc. without having to rename dozen of files.

Just make a rule that looks like the last / rule and enter rtfarmhouse as mesh mask.

I think this analysis is partially incorrect. Being aware that there are several versions of sbluepalacegate*.nif, I have applied the following mesh mask rule:

LODGen153=sbluepalacegate,Full,Full,None,None,FarLOD,Unchanged,0,

which produces the above result. The wall is definitely related to sbluepalacegate.nif, but it must be for the duplicate, 0x5A004B~BluePalaceTerrace.esp (I need to get rid of that one; I have created the Open Cities patch for JK's Blue Palace Terrace myself). Was this the only thing you found by looking into that reference?

8 hours ago, sheson said:

I looked some more into this.

There are 2 references adding the palace gate twice:
xx5A004B in BluePalaceTerrace.esp and xx00C938 in Open Cities Skyrim.esp

It probably happens because of conflicting swaps for the same base record (or EditorID) to different new base records in different INIs:

sos_seasonspatch_solitude_win.ini
Season WIN, swapping record Skyrim.esm SBluePalaceGate [STAT:000801ED] to SoS_Seasonspatch_Solitude.esp SBluePalaceGateWinter [STAT:FE12F812

sos_seasons_vigilant_win.ini
Season WIN, swapping record Skyrim.esm SBluePalaceGate [STAT:000801ED] to SoS_Seasons - Vigilant.esp SCWgateWinter [STAT:FE310801]

DynDOLOD loads in the swap INIs in the same order as the plugins and as usual whatever is loaded last wins.

It is possible that Seasons of Skyrim does it different for some reason. If that is the case and actually intended to work differently than usual, then I will change that in DynDOLOD obviously.

In any case, the swap from the palace gate SBluePalaceGate to Solitude main gate SCWgate in sos_seasons_vigilant_win.ini seem wrong anyways.

The issue anyway seems to happen for all instances of SCWgateWinter/SBluePalaceGateWinter (the JK's Blue Palace version works just fine now when I look at it carefully). I think you might be at something, though. If DynDOLOD loads form swaps by plugin order, you are doing it wrong. Seasons of Skyrim applies rules in the alphabetical order of the config files, which is written clearly in the documentation (but I don't know what that means in this case, given the underscore - ask powerofthree). Normally, there should not be any problem applying two different rules for the same object (I have good reasons for doing so here), because it is anyway the one that loads last that wins. But if you are not using the same file order, I guess that could cause problems when mesh mask rules are involved. I could try commenting out one of the form swaps and see if it helps, but you need to fix this too.