DynDOLOD 3.00 Alpha 180

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

[sheson]

5 hours ago, User77111 said:

 

I'n not really sure what is going on.

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]

2 hours ago, 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

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.

[KRZ]

Hey sheson,
I'm crashing in cities (only Riften and Whiterun tested) with DynDOLOD A-170 generated output. I've tried disabling the DynDOLOD Output which got rid of the issue and I rolled back to A-169, generated a new output and had no issue. Crash Logs are included in Logs.zip, DynDOLOD_SSE_Debug (https://mega.nz/file/UacwCRLb#BzV3vb1x-dauLDoHt4rHjQOrNXzYHn8fS2_bk4s-4To) as always had been to large.

Could you have a look? Thanks!

Logs.zip

Edited June 4 by KRZ

[User77111]

2 hours ago, sheson said:

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.

Thanks for the instructions I will try this out with all the LOD meshes and see if it works.

[sheson]

3 hours ago, KRZ said:

Hey sheson,
I'm crashing in cities (only Riften and Whiterun tested) with DynDOLOD A-170 generated output. I've tried disabling the DynDOLOD Output which got rid of the issue and I rolled back to A-169, generated a new output and had no issue. Crash Logs are included in Logs.zip, DynDOLOD_SSE_Debug (https://mega.nz/file/UacwCRLb#BzV3vb1x-dauLDoHt4rHjQOrNXzYHn8fS2_bk4s-4To) as always had been to large.

Could you have a look? Thanks!

Logs.zip 1.18 MB · 1 download

If you are absolutely sure that the load order did not change after generating the output with alpha 170 let me know for follow up questions/troubleshooting..

Otherwise, generate a LOD patch from scratch with the latest alpha for the current load order, to verify that the crash still happens.
If it does, upload new DynDOLOD log and debug log and new crash log and keep the output around for follow up questions/troubleshooting.

[drift123]

Do the settings used while generating a grass precache affect the performance of grass LOD? Or is LOD grass performance solely a matter of the Texgen and Dyndolod settings? I'm a bit confused as to whether the grass precache that is generated via the MO2 plugin is actually affecting the grass LOD density or other performance variables or if that is solely determined after the fact with the billboard and LOD settings. I used No grass in objects with grass helper NG to generate the precache but I'm not sure if the grass INI settings are influencing the quality of precache generation or if they only affect full grass appearance in the loaded cell.

Edited June 4 by drift123
typo

[sheson]

7 minutes ago, drift123 said:

Do the settings used while generating a grass precache affect the performance of grass LOD? Or is LOD grass performance solely a matter of the Texgen and Dyndolod settings? I'm a bit confused as to whether the grass precache that is generated via the MO2 plugin is actually affecting the grass density or other performance variables or if that is determined after the fact with the billboard and LOD settings. I used No grass in objects with grass helper NG to generate the precache but I'm not sure if the grass INI settings are influencing the quality of precache generation or if they only affect full grass appearance in the loaded cell.

https://dyndolod.info/Help/Grass-LOD
The grass cache contains grass model and placement information.

https://dyndolod.info/Help/Grass-LOD#Settings
In case the grass pre-cache was generated with SuperDenseGrass/Super-dense-grass = True, expect really long object LOD generation times. Lower the density to 33% or less.

https://dyndolod.info/Help/Grass-LOD#Performance

There are settings that change the amount of full grasses and the density of full grass in the cache. There more full grass, the more LOD grass, the higher the performance requirement. The denser the placements, the denser the grass LOD, the higher the performance requirements.

[drift123]

35 minutes ago, sheson said:

https://dyndolod.info/Help/Grass-LOD
The grass cache contains grass model and placement information.

https://dyndolod.info/Help/Grass-LOD#Settings
In case the grass pre-cache was generated with SuperDenseGrass/Super-dense-grass = True, expect really long object LOD generation times. Lower the density to 33% or less.

https://dyndolod.info/Help/Grass-LOD#Performance

There are settings that change the amount of full grasses and the density of full grass in the cache. There more full grass, the more LOD grass, the higher the performance requirement. The denser the placements, the denser the grass LOD, the higher the performance requirements.

So to be clear, the grass "pre-cache" is referring to the file generation using the MO2 plugin that launches Skyrim and crashes then relaunches Skyrim and outputs the CGID files?

Whereas the grass "cache" is the grass LOD output the Dyndolod creates? Or are the pre-cache and cache synonymous? As I understand it both the LOD grass and full grass are cached for better performance compared to the vanilla loading technique.

I have Superdense grass set to false and Dyndolod mode to 1 in the grass control .ini for No Grass In Objects mod. I'm only rendering full grass in the 5x5 loaded cell but it was still a heavy performance hit. I'm aware that I can lower the grass density in Dyndolod and lower the billboard quality in TexGen. Is there any performance reason to regenerate the CGID pre-cache files if SuperDenseGrass was false and the load order is the same?

[sheson]

24 minutes ago, drift123 said:

So to be clear, the grass "pre-cache" is referring to the file generation using the MO2 plugin that launches Skyrim and crashes then relaunches Skyrim and outputs the CGID files?

Whereas the grass "cache" is the grass LOD output the Dyndolod creates? Or are the pre-cache and cache synonymous? As I understand it both the LOD grass and full grass are cached for better performance compared to the vanilla loading technique.

I have Superdense grass set to false and Dyndolod mode to 1 in the grass control .ini for No Grass In Objects mod. I'm only rendering full grass in the 5x5 loaded cell but it was still a heavy performance hit. I'm aware that I can lower the grass density in Dyndolod and lower the billboard quality in TexGen. Is there any performance reason to regenerate the CGID pre-cache files if SuperDenseGrass was false and the load order is the same?

cache = precache = the files in the ..\data\grass\ folder generated by NGIO.

https://dyndolod.info/Help/Grass-LOD
Grass LOD uses grass LOD billboards in object LOD, similar to ultra tree LOD. [..] Grass LOD is generated for LOD level 4 only.
Grass LOD generation requires a warmed (current) grass precache for the current load order. It uses the *.CGID files found in the ..\Data\Grass\ folder.

If you do not change any settings that affect the data in the cache, like changing the filenames of full grass models, the number of full grasses per landscape texture or the density full grass, then there is no need to generate the grass cache again, as it will be more or less the same.

[Jonado]

On 6/3/2024 at 9:23 AM, sheson said:

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.

There was a typo in SoS_Seasons_Vigilant_WIN.ini, but I didn't notice because SoS_Seasonspatch_WIN.ini is taking priority on my build. I would have expected that at least one of the 10,000 people who have downloaded the mod would have noticed it and reported the bug, but apparently not. I have updated the mod now with a fix.

On 6/3/2024 at 9:23 AM, sheson said:

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)

Thanks for the clarification. I was a bit scared when you said you were using load order for determining priority rules, since that could have caused a lot of mismatches for other types of objects (like trees). But isn't Base Object Swapper also sorting alphabetically? It isn't documented, but I assumed that was the case, which is also what I have experienced during my testing. And are you sure about the case sensitivity? It sounds weird to me that a would load after B.

Edited June 4 by Jonado