DynDOLOD 3.00 Alpha 182

[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

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