DynDOLOD 3.00 Alpha 169

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

[PRieST]

With Alpha 120 I get this kind of an issue, a lot of these warnings:

Quote

<Warning: Textures do not match for "RockCliff08:0": textures\landscape\snow01.dds in rockcliff08.nif -> textures\landscape\dirt02.dds in rockcliff08_lod_0.nif for WIZ_FoscsF.esp WIZ_RockCliff08Snow_LightSN [STAT:FE10A83E]>
[00:46] <Warning: Textures do not match for "RockCliff08:0": textures\landscape\snow01.dds in rockcliff08.nif -> textures\landscape\dirt02.dds in rockcliff08_lod_1.nif for WIZ_FoscsF.esp WIZ_RockCliff08Snow_LightSN [STAT:FE10A83E]>

There are much much more...
nothing in my loadorder changed, I just deleted the old output (no clean save needed, as I start a new game either way) and installed the new alpha from ground up.

I didn't had these warnings with alpha 119, so they are new. The resources are up to date, too (they also weren't updated from your side from 119 to 120).
As soon as the run finished successfull I'll give you the logs from this run.

In the past this meant I had to update the resources or similar things, because something was outdated, but because the SE resources are the same, this can't be the case this time or am I wrong?

Edited March 19, 2023 by PRieST

[sheson]

10 minutes ago, PRieST said:

With Alpha 120 I get this kind of an issue, a lot of these warnings:

There are much much more...
nothing in my loadorder changed, I just deleted the old output (no clean save needed, as I start a new game either way) and installed the new alpha from ground up.

I didn't had these warnings with alpha 119, so they are new. The resources are up to date, too (they also weren't updated from your side from 119 to 120).
As soon as the run finished successfull I'll give you the logs from this run.

In the past this meant I had to update the resources or similar things, because something was outdated, but because the SE resources are the same, this can't be the case this time or am I wrong?

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

Read https://dyndolod.info/Messages/Textures-Do-Not-Match

Have you doublechecked which mod supplies the LOD model? It is likely a 3rd party LOD model and not from DynDOLOD Resources.

[PRieST]

They are from many different mods.
'minescaffoldtop0sided01.nif' for example is from Static Mesh Improvement Mod, which didn't changed in ages. And again, these warnings weren't there with alpha 119.

Warning: Textures do not match for "MineScaffoldTop0Sided01:13": textures\smim\dungeons\mines\smim_wood_mine_planks.dds in minescaffoldtop0sided01.nif -> textures\dungeons\mines\minewood01.dds in minescaffoldtop0sided01_lod_0.nif for Skyrim.esm MineScaffoldTop0Sided01iceLt [STAT:000DBFF5]

If I stay with that example, the mentioned record isn't overwritten by anything.

Here are the logs: Download

There are also 3rd party LODs present (Majestic Mountains for example), but I used them the same as before, without updating or changing them. The run finished successfully and I only got a summary with a whole lot of the 'Textures do not match' warnings.
Something must have changed between alpha 119 and 120 so now there are these warning which weren't there before.

Edited March 19, 2023 by PRieST

[sheson]

7 minutes ago, PRieST said:

They are from many different mods.
'minescaffoldtop0sided01.nif' for example is from Static Mesh Improvement Mod, which didn't changed in ages. And again, these warnings weren't there with alpha 119.

Warning: Textures do not match for "MineScaffoldTop0Sided01:13": textures\smim\dungeons\mines\smim_wood_mine_planks.dds in minescaffoldtop0sided01.nif -> textures\dungeons\mines\minewood01.dds in minescaffoldtop0sided01_lod_0.nif for Skyrim.esm MineScaffoldTop0Sided01iceLt [STAT:000DBFF5]

If I stay with that example, the mentioned record isn't overwritten by anything.

Here are the logs: Download

As explained, this is about the models, not records. Is the LOD model from DynDOLOD Resources? Is the full model from SMIM?

The full model defines textures\smim\dungeons\mines\smim_wood_mine_planks.dds
The LOD model defines textures\dungeons\mines\minewood01.dds

[PRieST]

The full model for this example line is from SMIM, correct. And the LOD model from DynDOLOD resources.

Maybe you are interested in these logs, this was the last successful run with alpha 119, between these two runs I only added one mod, which isn't related to LODs at all:
119 Logs
The rest is exactly the same, nothing else changed despite of the new lod texture and dyndolod generation.

Edited March 19, 2023 by PRieST

[sheson]

7 minutes ago, PRieST said:

The full model for this example line is from SMIM, correct. And the LOD model from DynDOLOD resources.

Maybe you are interested in these logs, this was the last successful run with alpha 119, between this two runs I only added one mod, which isn't related to LODs at all:
119 Logs
The rest is exactly the same, nothing else changed despite of the new lod texture and dyndolod generation.

From the debug log:
[00:09] [BuildBaseRecords] <Debug: Textures do not match for "MineScaffoldTop0Sided01:13": textures\smim\dungeons\mines\smim_wood_mine_planks.dds in minescaffoldtop0sided01.nif -> textures\dungeons\mines\minewood01.dds in minescaffoldtop0sided01_lod_0.nif for Skyrim.esm MineScaffoldTop0Sided01iceLt [STAT:000DBFF5]>

You should be good because in either case you can see Creating D:\DynDOLOD\DynDOLOD_Output\textures\lod\smim_wood_mine_plankslod.dds in the log.

I will have to readjust to which log the message is printed to.

[PRieST]

OK great, if everything will work as intended, I'm fine with it.

Was just irritated because I haven't gotten these warnings before with older alphas.

[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