DynDOLOD 3.00 Alpha 196

[sheson]

35 minutes ago, heheloveer said:

Well, since there's already one mismatch caused by root node transformations I can imagine similar things exist in other models from the mod as well. But you're right, this should be analyzed case by case, and as long as I don't notice them causing any visual problems like the bridges do, I guess I don't need to mind them.

Is the end result supposed to look like this?

About dynamic lod, I'm actually quite confused: as I understand it every mesh mask rule includes settings for both the static and dynamic lod. So what dictates whether a lod is dynamic or static in game?

The NifSkope screenshot looks correct.

https://dyndolod.info/Help/Dynamic-LOD
Dynamic LOD - while optional was the primary reason for the creation and name of DynDOLOD - is a new type of LOD for objects that change their visual state based on distance to the player and their quests status like military tents or ships. In addition it supports animated objects like waterfalls or fires or glow LOD windows that react to weather/sunlight.

References that have enable parents and/or are initially disabled for example will have dynamic LOD so it can be enable/disabled accordingly to the enable state of the full model reference it represents.

[heheloveer]

18 minutes ago, sheson said:

The NifSkope screenshot looks correct.

https://dyndolod.info/Help/Dynamic-LOD
Dynamic LOD - while optional was the primary reason for the creation and name of DynDOLOD - is a new type of LOD for objects that change their visual state based on distance to the player and their quests status like military tents or ships. In addition it supports animated objects like waterfalls or fires or glow LOD windows that react to weather/sunlight.

References that have enable parents and/or are initially disabled for example will have dynamic LOD so it can be enable/disabled accordingly to the enable state of the full model reference it represents.

Got it. Thanks for the explanation!

[RainingTacco]

What can cause dyndolod to be activated and after some time deactivate itself?

 

Dyndolod deactivates itself when i arrive to Solstheim, despite working in skyrim. Im sure ive generated lods for all worlspaces. 

Edited March 17, 2023 by RainingTacco

[sheson]

8 hours ago, RainingTacco said:

What can cause dyndolod to be activated and after some time deactivate itself?

Dyndolod deactivates itself when i arrive to Solstheim, despite working in skyrim. Im sure ive generated lods for all worlspaces. 

Read the first post which log and debug log to upload when making posts.

https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs
If there are suspected problems related to dynamic LOD or the the DynDOLOD SkyUI MCM in the game, enable and upload the c:\Users\[USERNAME]\Documents\My Games\[Skyrim|Skyrim Special Edition|Skyrim VR]\Logs\Script\Papyrus.0.log.

The only thing that can unset the Active status in the DynDOLOD SkyUI MCM is the user or PapyrusUtil failing to read its status or some severe problem with the patch plugins or scripts.

[sheson]

On 3/17/2023 at 4:19 PM, heheloveer said:

As with the last time, everything DynDOLOD related in the papyrus log seemed pretty normal.

Looked more into it. DynDOLOD 3 Alpha 120 should hopefully fix all remaining cells not unloading the object LOD for the large references when using the large reference bugs workarounds.

[heheloveer]

7 hours ago, sheson said:

Looked more into it. DynDOLOD 3 Alpha 120 should hopefully fix all remaining cells not unloading the object LOD for the large references when using the large reference bugs workarounds.

Tested with Alpha 120 and had some interesting discoveries. I made saves on the Whiterun Watchtower and near Angi's camp, and every time I opened the game and loaded these saves, the large reference bugs would show up in the same old cells. Walking to other cells would make large reference bugs appear in cells that newly enter the uGridsToLoad - uLargeRefLODGridSize range. Fast traveling to nearby cells has the same effect. However, it seems fast traveling to a sufficiently faraway cell could make the large reference bugs go away for good until you load a save. Sometimes loading a save would make the large reference bugs show up again and sometimes it wouldn't. I'm not sure why this was the case. As for the distance you have to fast travel to make the large reference bugs disappear, I would guess "outside the uLargeRefLODGridSize range". Just a guess though, not sure if there's any way to prove that. I also don't know if the earlier versions behaved like this since I never tested it thoroughly until now.

Another curious thing: the first time I loaded a save after opening the game, I could see large reference bugs disappearing in some cells while remaining in others, as shown in the video. Not sure if this is relevant though.

This time I also found out that in Whiterun City, looking outside the walls, there were also grass lods and full grass overlapping. At least one building outside also had the full model/lod z-fighting going on. How does the large reference system work in child worlds anyway? Do they even work at all?

Lastly I changed the grid settings of Whiterun Temple Tress and the windmill fans to NeverFade LOD but they just refused to appear most of the time. In fact in one of my other DynDOLOD generations with version 119 I didn't change their grid setting (Far LOD) but set FarGridsToLoad to 31 instead. That time I also couldn't see them most of the time despite them being absolutely in that range.

As usual, the logs and stuff: https://anonfiles.com/Sakc74f5ze/Logs_and_Stuff_20230319_rar

[sheson]

31 minutes ago, heheloveer said:

Tested with Alpha 120 and had some interesting discoveries. I made saves on the Whiterun Watchtower and near Angi's camp, and every time I opened the game and loaded these saves, the large reference bugs would show up in the same old cells. Walking to other cells would make large reference bugs appear in cells that newly enter the uGridsToLoad - uLargeRefLODGridSize range. Fast traveling to nearby cells has the same effect. However, it seems fast traveling to a sufficiently faraway cell could make the large reference bugs go away for good until you load a save. Sometimes loading a save would make the large reference bugs show up again and sometimes it wouldn't. I'm not sure why this was the case. As for the distance you have to fast travel to make the large reference bugs disappear, I would guess "outside the uLargeRefLODGridSize range". Just a guess though, not sure if there's any way to prove that. I also don't know if the earlier versions behaved like this since I never tested it thoroughly until now.

Another curious thing: the first time I loaded a save after opening the game, I could see large reference bugs disappearing in some cells while remaining in others, as shown in the video. Not sure if this is relevant though.

This time I also found out that in Whiterun City, looking outside the walls, there were also grass lods and full grass overlapping. At least one building outside also had the full model/lod z-fighting going on. How does the large reference system work in child worlds anyway? Do they even work at all?

Lastly I changed the grid settings of Whiterun Temple Tress and the windmill fans to NeverFade LOD but they just refused to appear most of the time. In fact in one of my other DynDOLOD generations with version 119 I didn't change their grid setting (Far LOD) but set FarGridsToLoad to 31 instead. That time I also couldn't see them most of the time despite them being absolutely in that range.

As usual, the logs and stuff: https://anonfiles.com/Sakc74f5ze/Logs_and_Stuff_20230319_rar

Large references bugs workarounds will only be applied when areas load while walking around or after fast travel. If the bugs for an already fixed area reappear after loading a save, the large reference bugs workarounds are not applied again, since the area was already loaded/fixed before the save. You would need to leave and come back. That's something I will have to look into.

Childworlds replace parent cells with the child version cell while (typically) using the LOD from the parent world the same way for stuff outside the active cells just like things work in the parent world.

For the tree and fans, test with a new save.
Everything works same same regardless if the FarGrid is 21 or 31. However, 21 means 441 cells while 31 means 961 cells - more than double the work to enable/disable dynamic LOD references.

[heheloveer]

9 minutes ago, sheson said:

Large references bugs workarounds will only be applied when areas load while walking around or after fast travel. If the bugs for an already fixed area reappear after loading a save, the large reference bugs workarounds are not applied again, since the area was already loaded/fixed before the save. You would need to leave and come back. That's something I will have to look into.

Childworlds replace parent cells with the child version cell while (typically) using the LOD from the parent world the same way for stuff outside the active cells.

For the tree and fans, test with a new save.
Everything works same same regardless if the FarGrid is 21 or 31. However, 21 means 441 cells while 31 means 961 cells - more than double the work to enable/disable dynamic LOD references.

Is it possible to make the large reference bugs workaround apply every time you load a save? From what I understand, if it is possible, it probably would resolve most of the large reference issues I've encountered.

If I understand what you're saying correctly, typically there's no large references outside the city, and the overlapping full building was probably added by the option in DynDOLOD resources (didn't thought about clicking on it with the console open and now I'm off my PC, will have to check later). If that's the case, why would it happen? I thought that option would only add things outside the city that can't have a lod?

Also, how does this rule apply to grass outside the city? Is there any particular reason for the overlapping grass lod and full grass?

Everything I tested was on a completely new save made after installing the new DynDOLOD output, unfortunately. I mean, I once thought the windmill fan/temple tree not appearing was because they were outside the FarGrid area, so I increased it. Guess that wasn't the case. Now that I think about it, maybe it's a performance related issue. I think I'll have to test some more after tuning down some of my DynDOLOD settings.

[sheson]

19 minutes ago, heheloveer said:

Is it possible to make the large reference bugs workaround apply every time you load a save? From what I understand, if it is possible, it probably would resolve most of the large reference issues I've encountered.

If I understand what you're saying correctly, typically there's no large references outside the city, and the overlapping full building was probably added by the option in DynDOLOD resources (didn't thought about clicking on it with the console open and now I'm off my PC, will have to check later). If that's the case, why would it happen? I thought that option would only add things outside the city that can't have a lod?

Also, how does this rule apply to grass outside the city? Is there any particular reason for the overlapping grass lod and full grass?

Everything I tested was on a completely new save made after installing the new DynDOLOD output, unfortunately. I mean, I once thought the windmill fan/temple tree not appearing was because they were outside the FarGrid area, so I increased it. Guess that wasn't the case. Now that I think about it, maybe it's a performance related issue. I think I'll have to test some more after tuning down some of my DynDOLOD settings.

As I mentioned, I will have to look into applying that particular fix after reloading.

Large references work exactly the same in childworlds like they do in the parent world. The area is affected by a large reference bug in the child world just the same. I need to double check that the scripted large reference bugs workarounds are also applied in the child worlds.

Full grass is not a reference. The WhiterunExterioroGrass patch simply enables full grass in the child worldspace so full grass shows the in active cells the childworld replaces. NGIO should then still extend full grass into the LOD area with when using mode 2 and past that the grass LOD shows - unless large reference bugs make grass LOD show closer just the same cause and problem as in the parent world.

[heheloveer]

7 minutes ago, sheson said:

As I mentioned, I will have to look into applying that particular fix after reloading.

Large references work exactly the same in childworlds like they do in the parent world. The area is affected by a large reference bug in the child world just the same. I need to double check that the scripted large reference bugs workarounds are also applied in the child worlds.

Full grass is not a reference. The WhiterunExterioroGrass patch simply enables full grass in the child worldspace so full grass shows the in active cells the childworld replaces. NGIO should then still extend full grass into the LOD area with when using mode 2 and past that the grass LOD shows - unless large reference bugs make grass LOD show closer just the same cause and problem as in the parent world.

Thanks for the clarification. There's one thing that I want to add though: you generate grass cache before running DynDOLOD, while the WhiterunExteriorGrass patch, as I understand it, makes sure the Whiterun worldspace record in DynDOLOD.esp doesn't have the nograss flag. But if in the original load order the Whiterun worldspace has that flag, then NGIO wouldn't generate grass cache for it, right? So theoretically could this resulting in the grass outside the city still not appearing after running DynDOLOD with WhiterunExteriorGrass patch installed?

[sheson]

6 minutes ago, heheloveer said:

Thanks for the clarification. There's one thing that I want to add though: you generate grass cache before running DynDOLOD, while the WhiterunExteriorGrass patch, as I understand it, makes sure the Whiterun worldspace record in DynDOLOD.esp doesn't have the nograss flag. But if in the original load order the Whiterun worldspace has that flag, then NGIO wouldn't generate grass cache for it, right? So theoretically could this resulting in the grass outside the city still not appearing after running DynDOLOD with WhiterunExteriorGrass patch installed?

Any grass cache files for childworlds using a parent world for LOD are irrelevant for grass LOD generation since grass LOD is generated with the data from the grass cache files for the parent world. Grass cache files are also irrelevant how object LOD / large references works in the game.

Depending on the NGIO ini settings it will automatically generate missing grass cache files on demand when normally playing the game.

[heheloveer]

26 minutes ago, sheson said:

Any grass cache files for childworlds using a parent world for LOD are irrelevant for grass LOD generation since grass LOD is generated with the data from the grass cache files for the parent world. Grass cache files are also irrelevant how object LOD / large references works in the game.

Depending on the NGIO ini settings it will automatically generate missing grass cache files on demand when normally playing the game.

Indeed it's unrelated to large references, just something I suddenly thought of. Once I generated grass cache and DynDOLOD but only saw grass lods, no full grass outside Whiterun. Never encountered that again after I made a plugin which removes the nograss flag for Whiterun worldspace and made it overwrite every other plugin except DynDOLOD.esp. Well, whether it's actually useful or not, it never hurts to include a placebo.

[Blackread]

Hello sheson, I am once again looking for support with LOD issues. This time I'm having problems with some glow lods not unloading properly. Here are some examples:

Saving and reloading from the main menu does not clear them up. Going to an interior cell, or in the case of the Solitude dock area, to the city worldspace and back does fix them. I haven't seen them when arriving to a cell directly with fast travel or through other means.
Here are the logs: https://mega.nz/file/9P9lEZbD#HSgYOmOMDybs-vF0drYsXSFEY1bH1OmwhSgBDTi15NI

There were some errors originating from DynDOLOD in some of the Papyrus logs so I attached them too, but I'm not sure if they are related, as the glow lods were always there, but the Papyrus logs were sometimes clean.

Edited March 20, 2023 by Blackread

[sheson]

17 minutes ago, Blackread said:

Hello sheson, I am once again looking for support with LOD issues. This time I'm having problems with some glow lods not unloading properly. Here are some examples:

Saving and reloading from the main menu does not clear them up. Going to an interior cell, or in the case of the Solitude dock area, to the city worldspace and back does fix them. I haven't seen them when arriving to a cell directly with fast travel or through other means.
Here are the logs: https://mega.nz/file/9P9lEZbD#HSgYOmOMDybs-vF0drYsXSFEY1bH1OmwhSgBDTi15NI

There were some errors originating from DynDOLOD in some of the Papyrus logs so I attached them too, but I'm not sure if they are related, as the glow lods were always there, but the Papyrus logs were sometimes clean.

See https://dyndolod.info/FAQ "Out of place or floating objects"
Test with new game, wait in the exterior for the DynDOLOD initialized message before moving. If the problem goes away, the updating of an existing save game with old DynDOLOD plugins went wrong. Follow the clean save instructions when updating DynDOLOD .

If problem happens with a new game, upload..\skse\plugins\DynDOLOD_Data\DynDOLOD_Worlds.txt, DynDOLOD_Tamriel.txt and DynDOLOD_Tamriel_Objects.txt from the DynDLLOD output belonging to those log files and screenshots.

Generate a simple test LOD patch just for Tamriel, no Occlusion needed, without the large reference bugs / DynDOLOD DLL NG and Scripts just with PapyrusUtil or DynDOLOD DLL 2.x instead. Upload that log debug log and the same data files from ..\skse\plugins\DynDOLOD_Data\

Do you have all 3 options enabled in the Skyrim.INI for [Papyrus]
bEnableLogging=1
bEnableTrace=1
bLoadDebugInformation = 1

[Blackread]

2 hours ago, sheson said:

See https://dyndolod.info/FAQ "Out of place or floating objects"
Test with new game, wait in the exterior for the DynDOLOD initialized message before moving. If the problem goes away, the updating of an existing save game with old DynDOLOD plugins went wrong. Follow the clean save instructions when updating DynDOLOD .

If problem happens with a new game, upload..\skse\plugins\DynDOLOD_Data\DynDOLOD_Worlds.txt, DynDOLOD_Tamriel.txt and DynDOLOD_Tamriel_Objects.txt from the DynDLLOD output belonging to those log files and screenshots.

Generate a simple test LOD patch just for Tamriel, no Occlusion needed, without the large reference bugs / DynDOLOD DLL NG and Scripts just with PapyrusUtil or DynDOLOD DLL 2.x instead. Upload that log debug log and the same data files from ..\skse\plugins\DynDOLOD_Data\

Do you have all 3 options enabled in the Skyrim.INI for [Papyrus]
bEnableLogging=1
bEnableTrace=1
bLoadDebugInformation = 1

Problem does happen with a new game. Data files for the NG generation.

Logs and data files for the Tamriel test generation. I used the default scripts in DynDOLOD resources SE 3, so PapyrusUtil I believe.

Trace and DebugInformation were turned off. Two Papyrus logs with them turned on.