DynDOLOD 3.00 Alpha 182

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

[sheson]

10 hours ago, 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.

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.

10 hours ago, 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.

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]

24 minutes ago, User77111 said:

Hopefully this has not been asked already.

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

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]

50 minutes ago, 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.

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 by User77111

[sheson]

40 minutes ago, 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

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.

21 minutes ago, 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?

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.

23 minutes ago, 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.

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]

4 hours ago, 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.

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.