DynDOLOD 3.00 Alpha 190

[sheson]

  On 6/1/2024 at 9:18 PM, 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.

Expand  

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]

  On 6/2/2024 at 10:44 AM, 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.
 

Expand  

"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]

  On 6/1/2024 at 9:18 PM, 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.

Expand  

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]

  On 6/2/2024 at 6:48 AM, 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.

Expand  

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?

  On 6/2/2024 at 1:45 PM, 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.

Expand  

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.

[sheson]

  On 6/2/2024 at 10:00 PM, Jonado said:

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.

Expand  

It is correct. The screenshotted reference xx00C938 using Meshes\jk's blue palace\sbluepalacegate.nif also has Meshes\jk's blue palace\sbluepalacegate.nif in the BTO because of that mesh mask rule. The full model gate can be seen in the BTO. That reference is not involved in the issue you are seeing. As I suspected, I found the different reference to be xx5A004B in BluePalaceTerrace.esp. That is the one that is being replaced to a completely different model because of sos_seasons_vigilant_win.ini defines that swap.

You can look up these references (BA00C938 and 325A004B) in the export file LODGen_SSE_Export_Tamriel_WIN.txt to see which reference uses which LOD model in the BTO in the end.

  On 6/2/2024 at 10:00 PM, Jonado said:

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.

Expand  

I got confused with Base Object Swapper. Seasons INIs can have any file name and DynDOLOD does load them alphabetically (can be checked in the debug log). So "zzzConfig wins over aaaConfig". The problem is that SOS treats the filenames case sensitive while xEdit - like Windows - by default does not. For example, a is loaded after B by SOS. I will address that in the next alpha (including making sure the underscore sorts the same way - its after uppercase but before lowercase usually)

[User77111]

Hopefully this has not been asked already.

Is there a way to disable rim lighting and soft lighting when generating object LOD?

[sheson]

  On 6/4/2024 at 6:05 AM, User77111 said:

Hopefully this has not been asked already.

Is there a way to disable rim lighting and soft lighting when generating object LOD?

Expand  

By default, LOD assets and thus their LOD shapes in BTOs do not set these shader flags or have a third texture.

Only LOD assets that specifically instruct DynDOLOD to keep those settings have them generated in the BTO.

https://dyndolod.info/Official-DynDOLOD-Support-Forum
Report the actual problem or error message without making assumptions or asking leading questions. Read the explanations and tips below, especially about what information and logs to provide and how.

[User77111]

  On 6/4/2024 at 6:29 AM, sheson said:

By default, LOD assets and thus their LOD shapes in BTOs do not set these shader flags or have a third texture.

Only LOD assets that specifically instruct DynDOLOD to keep those settings have them generated in the BTO.

https://dyndolod.info/Official-DynDOLOD-Support-Forum
Report the actual problem or error message without making assumptions or asking leading questions. Read the explanations and tips below, especially about what information and logs to provide and how.

Expand  

I get these shader flags on the object LOD that causes trees and objects to illuminate even without the sun hitting them.

You can see here the sun is behind the mountain and the LOD objects are bright:

Once the objects themselves are loaded in:

(I froze in game time during this)

Here are the tree objects themselves:

The BTO file itself does not have the soft lighting and rim lighting on these specific trees, but sometimes they do. Even in this specific tree.

Tree Mod

Log Files

3D LOD files (overwrite with the 3d LOD resource files on the mod page)

I did not mess with the shader flags on my custom 3d LOD.

 

This is an example of a couple of trees showing the issue. This happens with all LOD objects, even mountains.

I should mention I use this mod as well: https://www.nexusmods.com/skyrimspecialedition/mods/63725

 

 

 

Edited June 4, 2024 by User77111

[sheson]

  On 6/4/2024 at 7:00 AM, User77111 said:

I get these shader flags on the object LOD that causes trees and objects to illuminate even without the sun hitting them.

You can see here the sun is behind the mountain and the LOD objects are bright:

Once the objects themselves are loaded in:

(I froze in game time during this)

Here are the tree objects themselves:

The BTO file itself does not have the soft lighting and rim lighting on these specific trees, but sometimes they do. Even in this specific tree.

Tree Mod

Log Files

3D LOD files (overwrite with the 3d LOD resource files on the mod page)

I did not mess with the shader flags on my custom 3d LOD.

 

This is an example of a couple of trees showing the issue. This happens with all LOD objects, even mountains.

I should mention I use this mod as well: https://www.nexusmods.com/skyrimspecialedition/mods/63725

Expand  

The link to the 3D LOD files requires a login, so I can not download it.

Based on the screenshots I would assume this has to do with LOD by default not receiving/casting shadows.

https://dyndolod.info/How-LOD-Works
LOD does not cast or receive shadows. This can be mitigated by the ENB distant shadow effect or Screen-Space Shadows. If large reference bugs workarounds are used, tree full models can be made to also load outside the active cells, to push their swap distance further away.

https://dyndolod.info/Help/Terrain-Underside#Troubleshooting
LOD does not cast or receive shadows. This can be mitigated by the ENB distant shadow effect or Screen-Space Shadows.

0005C06E uses s3dtrees_treepineforestsnow05_lod_0.nif with CRC32 91829509 which I could not match to any file I currently have. I assume it might be one from the upload that I can not access. If the LOD model sets those flags or third texture and they somehow end up in the BTO with those features despite no passthru in filename (or shapename), remove them form the LOD asset. https://dyndolod.info/Help/3D-Tree-LOD-Model

0005C06F uses s3dtrees_treepineforestsnow04_lod_0.nif with CRC32 56F8528E which indicates it is still the LOD files included in Skyrim3DTrees and Plants 3dLOD Resources, which does not set any rim or soft lighting or third texture. Its combined shapes in the BTO should not have such settings either.

The screenshot of NifSkope shows no rim or soft lighting flags being set. What is it supposed to show?

[User77111]

You should be able to download it now.

  On 6/4/2024 at 7:20 AM, sheson said:

0005C06F uses s3dtrees_treepineforestsnow04_lod_0.nif with CRC32 56F8528E which indicates it is still the LOD files included in Skyrim3DTrees and Plants 3dLOD Resources, which does not set any rim or soft lighting or third texture. Its combined shapes in the BTO should not have such settings either.

The screenshot of NifSkope shows no rim or soft lighting flags being set. What is it supposed to show?

Expand  

I am showing that the model and nifskope does not show a soft lighting or a rim lighting shader flag, yet it still behaves in game like there is one.

  On 6/4/2024 at 7:20 AM, sheson said:

LOD does not cast or receive shadows. This can be mitigated by the ENB distant shadow effect or Screen-Space Shadows. If large reference bugs workarounds are used, tree full models can be made to also load outside the active cells, to push their swap distance further away.

Expand  

I do not need LOD objects to receive or cast shadows to fix the LOD issue. Soft lighting and rim lighting with the skyrim engine will illuminate the object with or without shadows casting on the object or receiving shadows. You can see here that part of the LOD object does not behave this way:

 

Opening the BTO file in NifSkope, you can see the shader flags between the two parts of the object LOD tree is not much different. One had a vertex color shader flag and the other is marked as double sided.

I am not sure why the part with the double sided flag acts like there is a soft lighting flag/ rim lighting.

LOD items in the further regions where the tree LOD is not 3d do have the soft lighting/rim lighting shader flag:

Some objects are illuminated the same way with or without the shader flag:

I'n not really sure what is going on.

 

[sheson]

  On 6/4/2024 at 8:04 AM, User77111 said:

I am showing that the model and nifskope does not show a soft lighting or a rim lighting shader flag, yet it still behaves in game like there is one.

Expand  

However unlikely that seems to be, if we assume for a minute that to be true, what do you want the tool creating the BTOs to do differently if the engine does whatever it does regardless of settings? That would be something that needs to be addressed in the engine/shaders with ENB or Communuty Shaders etc.

If using ENB distant shadows or Community Shaders does not help, then I suggest to look into the normal vectors next. In these 3D tree LOD assets the normal vectors typically point upwards instead of the usual perpendiular direction from the surface. That is usually a better option for double sided triangles, so both sides are illuminated equally and brightest when the sun shines from above. Double check the BTOs that the normal vectors for the crowns still point upwards.

NifSkope shows the normal vectors if you unfold the Vertex Data array in the BSTriShape and highlight the normal entry in an array entry.

[sheson]

  On 6/4/2024 at 8:04 AM, User77111 said:

 

I'n not really sure what is going on.

Expand  

That screenshot is a good example for how the object LOD for some stony structures is not recieving shadows, while some full models that happen to be large references in the LOD area still do.

[User77111]

I just noticed the models in the screenshots receiving shadows are the full models. I just checked it looks like the terrain LOD and object LOD does not take any shadow at all.

In the screenshots comparing the 3d tree LOD brightness between the leaves vs the wood, it just looks like the LOD models have light shining on both sides of the double sided mesh that has the leaves regardless of where the sun is directing.

It seems like every double sided mesh does this. I wonder if there could be a solution for this.

Here is my Dyndolod Output: https://1drv.ms/u/s!Av1dDuTYEuYRgc5lQN88QDqgSpu2nQ?e=cLUIgS

TexGen: https://1drv.ms/u/s!Av1dDuTYEuYRgc5mm8dX9_PL10bORA?e=s07jOw

[sheson]

  On 6/4/2024 at 1:29 PM, User77111 said:

In the screenshots comparing the 3d tree LOD brightness between the leaves vs the wood, it just looks like the LOD models have light shining on both sides of the double sided mesh that has the leaves regardless of where the sun is directing.

It seems like every double sided mesh does this. I wonder if there could be a solution for this.

Here is my Dyndolod Output: https://1drv.ms/u/s!Av1dDuTYEuYRgc5lQN88QDqgSpu2nQ?e=cLUIgS

TexGen: https://1drv.ms/u/s!Av1dDuTYEuYRgc5mm8dX9_PL10bORA?e=s07jOw

Expand  

As I mentioned, the 3D LOD assets point the normal vector upwards so that double side triangles have equal brightness on either side and are brightest if the light shines from the top (they are actually slightly angled, so not exactly)

You could test removing the double sided flag and right click a BSTriShape, Mesh, Face normals, then again right click a BSTriShape, Mesh, Update Tangent Space.

If those work better, to restore the now missing "back triangles", convert the meshes to Skyrim (NiTriShapes) format with CAO. Duplicate the crown shape with right click on the NiTriShape, Block, Copy and right click on the root 0 BSFadeNode, Block, Paste. Then right click the NiTriShape, Mesh, Flip faces, Flip normals, Update Tangent Space.