DynDOLOD 3.00 Alpha 182

[sheson]

55 minutes ago, VladossX said:

bugreport.txt 161.61 kB · 0 downloads

Thanks, better than nothing! Just in case you come this across again at a later time, zip log, debug log and bugreport.txt before running the tools again and upload to a file service.

[sheson]

40 minutes ago, heheloveer said:

I haven't seen it in game yet since it's late where I am and that my game has been plagued with a strange CTD recently, but I can see how this could fix the issue after editing the mesh in NifSkope. This makes me wonder though, some other lod meshes in the mod also have translation in the BSFadeNode. Does this mean their in game positions would also be different from the full models'?

This also reminded me, the LODGen log has this message: meshes\cotn\landscape\bridges\lod\cotn_wood_small_01_noroof_end_lod.nif unexpected root node. Ignoring file. Now that I thought about it, it's most likely related to what is described here. However I looked at the mesh and its root node block type is BSTriShape, and I can't seem to convert it into BSFadeNode using NifSkope. Any workarounds?

Lastly I asked about how to show the Whiterun Temple Tree on the map. I use Level 32 object LOD for the map and changed the wrtempletree rule several times but could never get it to show. In fact sometimes the tree could also disappear from in game when viewed from a distance outside the city, which is very peculiar, since I even resorted to making all levels of its lod use the full model.

CK/LODGen adhere to root node transformations while the game does not. If a LOD model with root node transformation ends up at a different position, rotation or scale than the full model depends on a case by case basis. There may be LOD models where this is intentional or the transformation data is required so it matches the full model.

You need to Block -> Insert a new BSFadeNode and then add the BSTriShape as a child to it. Reorder blocks afterwards so the BSFadeNode has index 0.

The temple tree references have dynamic LOD since they change their enable state based on quest status. So the object LOD levels settings do not apply to them. If you want to show them further than the FarGrid, change Grid to Neverfade LOD for example. 

[heheloveer]

9 minutes ago, sheson said:

CK/LODGen adhere to root node transformations while the game does not. If a LOD model with root node transformation ends up at a different position, rotation or scale than the full model depends on a case by case basis. There may be LOD models where this is intentional or the transformation data is required so it matches the full model.

You need to Block -> Insert a new BSFadeNode and then add the BSTriShape as a child to it.

The temple tree references have dynamic LOD since they change their enable state based on quest status. So the object LOD levels settings do not apply to them. If you want to show them further than the FarGrid, change Grid to Neverfade LOD for example. 

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?

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