DynDOLOD 3.00 Alpha 170

[sheson]

4 hours ago, Blackread said:

Alright I gathered up the information. Here are first the pics for the fences:

The EDID for the copy is skyrimesm_0627B3_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD. The mod swapping the fences is Fences of Skyrim and the fences are swapped by their reference IDs.

The Cidhna Mine entrance information:

Cell: -43,0, CELL: 20EED~Skyrim.esm, LAND: B2550~Skyrim.esm
Objects: Tamriel.4.-44.0.bto, Tamriel.8.-48.0.bto, Tamriel.16.-48.0.bto
Terrain: Tamriel.4.-44.0.btr, Tamriel.8.-48.0.btr, Tamriel.16.-48.0.btr, Tamriel.32.-64.0.btr

I looked at it a bit closer ingame and noticed there are three things happening. First is the underside mesh, which is visible when coming out of the mine (single-sided).

The EDID for the underside is Tamriel_Underside_DynDOLOD_NOLOD. The second is a single-sided LOD object which is visible from the outside, this is what can be seen in the first image I posted. I suspect this is the terrain LOD. The third one is a double-sided LOD object sitting behind the single-sided one, which I suspect to be a mountain from the object LOD. I suppose at least the underside is a side effect of making Markarth use the Tamriel LOD. I also looked at the terrain and object LOD files, but I'm not really sure what I should be looking for, or how to compare them to the loaded cell.

Edit: I checked the LOD files again and in the object LOD files there isn't anything in that spot in any of them, so the double-sided LOD object can't be a mountain object after all (or at least not from one of these). In the terrain LOD there obviously is the slope up the mountain, though I'm not sure how to relate it to the loaded cell.

/endEdit

Edit2: Setting Markarth to not use LOD data eliminated all the LOD objects. However, the underside is still there. But since I had the flag enabled while generating LOD maybe I just need to regenerate without the flag?

Evermore information:

Cell: 14,-4, CELL: DF8ED~arnima.esm, LAND: n/a
Objects: arnimaEvermore.4.12.-4.bto, arnimaEvermore.8.8.-8.bto, arnimaEvermore.16.0.-16.bto
Terrain: arnimaEvermore.4.12.-4.btr, arnimaEvermore.8.8.-8.btr, arnimaEvermore.16.0.-16.btr, arnimaEvermore.32.0.-32.btr

With this one I also noticed the LOD object is double sided. There are no terrain LOD files under those names in my mod list, and there are no object LOD files generated by DynDOLOD for this worldspace either. However, there are these bundled with the original mod:

But the file names don't match the ones shown by the DynDOLOD MCM. Edit: I checked the meshes but none of them seemed to match what was seen ingame. Moreover, none of the objects in those meshes are double-sided, so it doesn't look like it could be any of them seen there. Edit2: Looks like setting Evermore not to use the parent worldspace LOD also got rid of the LOD object inside the city. Of course this means that the city now just floats in the skybox, but that's not a huge issue, since the walls are tall and you can't really see over them.

Edit: Just checked the map and it looks like despite setting the AllHDLOD32 to 1 in the ini, the objects that previously had non-HD (bright) snow on them still do.

I checked the mesh in nifskope and it looks like the names of the objects are changed to HD but the shader flags aren't.

At least in the tests I conducted last time it looked like simply changing the names of the objects was not enough, the shader flags needed to be changed too to swap the snow to HD. I changed the shader flags on High Hrothgar to HD and then the snow matched the other HD snow as intended.

One more odd thing I noticed is that when first going to an exterior the DynDOLOD Successfully Initialized notification isn't printed, no matter how long one waits. It's printed only after first making a save in an exterior and loading it. Don't know if this is indicative of a problem or anything, just different than what it used to be. I attached the Papyrus log here just in case: https://mega.nz/file/tTdFHKTD#909i7u0t8DLNl0Go0A4T-I6Ks8jGr19UOuqBuf9JL0U

Regarding the Fence mod, it is not good it relies on a old mod that breaks with Bethesda convention to always use unique filenames regardless of folders, so the vanilla fence LOD will be used whenever there is a duplicate filename of fencewoven[01|02].nif being used...
In any case, next alpha version should add a accompanying SWAP.ini for those new references.

For Markarth, just unsettling the use parent LOD flag is not enough when having generated the LOD patch with the terrain underside. It will still load the underside for Tamriel. Normally Markarth has its own LOD and thus its own underside. To compare, generate LOD without that flag.
If you check the cell 0x20EED you will notice that it sets the Hide Quad 1,2,3,4 flags, which effectively disables terrain in that cell. Do the same to the cell 0x75AD in Tamriel, so no terrain LOD is generated for the cell with xLODGen and for the underside with DynDOLOD.

The MCM You Are Here not showing the parent world LOD file names correctly for evermore is a side effect of it not having dynamic LOD generated by default. Since it uses the parent world for LOD, the LOD files for it are irrelevant. To test if something is LOD, just tll to disable it. Unsetting the flag just has the same effect with more steps. The references in the child worldspace evermore used to be not properly aligned with the parent worldspace, in fact the whole city is rotated somehow. I assume that is still the case and the cause. So if object LOD peeks through because of that, find the reference in the parent worldspace and get a screenshot with More Informative Console of it.

Next alpha version will make sure the HD LOD flag is also always set with AllHD.

From the papyrus log:
[08/16/2023 - 05:14:20PM] DynDOLOD successfully initialized
The message is printed to the screen right before that as the debug.trace is right below the debug.notification command in the script. The screen message can be delayed by the engine if there are a lot in the queue, but it might as well just show while the screen is still black.

[Blackread]

On 8/16/2023 at 8:49 PM, sheson said:

Regarding the Fence mod, it is not good it relies on a old mod that breaks with Bethesda convention to always use unique filenames regardless of folders, so the vanilla fence LOD will be used whenever there is a duplicate filename of fencewoven[01|02].nif being used...
In any case, next alpha version should add a accompanying SWAP.ini for those references.

For Markarth, just unsettling the use parent LOD flag is not enough when having generated the LOD patch with the terrain underside. It will still load the underside for Tamriel. Normally Markarth has its own LOD and thus its own underside. To compare, generate LOD without that flag.
If you check the cell 0x20EED you will notice that it sets the Hide Quad 1,2,3,4 flags, which effectively disables terrain in that cell. Do the same to the cell 0x75AD in Tamriel, so no terrain LOD is generated for the cell when with xLODGen and underside with DynDOLOD.

The MCM You Are Here not showing the parent world LOD file names correctly for evermore is a side effect of it not having dynamic LOD generated by default. Since it uses the parent world for LOD, the LOD files for it are irrelevant. To test if something is LOD, just tll to disable it. Unsetting the flag just has the same effect with more steps. The references in the child worldspace evermore used to be not properly aligned with the parent worldspace, in fact the whole city is rotated somehow. I assume that is the case and the cause. So if object LOD peeks through because of that, find the reference in the parent worldspace and get a screenshot with More Informative Console of it.

Next alpha version will make sure the HD LOD flag is also always set with AllHD.

From the papyrus log:
[08/16/2023 - 05:14:20PM] DynDOLOD successfully initialized
The message is printed to the screen right before that as the debug.trace is right below the debug.notification command in the script. The screen message can be delayed by the engine if there are a lot in the queue, but it might as well just show while the screen is still black.

You are right, that is the downside of the fence mod. But even if it did rename the meshes (which I of course could do myself too), I wouldn't have matching LOD assets for the new fences, so in a way I'm content with using the same LOD models for all of them. They are close enough that I haven't noticed any discrepancies so far.

I already tried regenerating the LOD for Markarth without the flag and it did indeed solve all the issues. I'll try with your suggested edit to the cell record next.

I took some comparison pictures of the evermore location in both worldspaces, I think they are from the same camera coordinates. They are indeed quite different from each other.

In my regular setup I use Majestic Mountains and as such can't click on the mountain meshes in the console, as they have a multipass moss/dirt shader on them. Because of that the pictures below were taken with majestic mountains disabled.

I "excavated" the objects by disabling other objects around them, I believe this is the full model which the LOD is originating from.

Pasting my last edit to the previous post here in case you missed it:

Quote

Found one more problem when poking around Markarth testing things. There's this rectangular water object floating a bit above the normal water and clipping with things.

The editor ID is skyrimesm_0F6F5F_Tamriel_DynDOLOD_OBJECT

Update:

I tried hiding the landscape as you suggested, but force hiding the quads made no difference in the xLODGen terrain LOD output. I instead made a plugin with which I dug a "hole" (or a valley) into the hill where the mine entrance is, that got rid of the terrain LOD in the tunnel, and the underside too.

I also tried setting NoCellsWithNAVM=0 for Riften and Solitude. It worked a treat, the missing objects were added in without any adverse side effects as far as I could tell.

Edit: Nevermind, there are some clipping mountain meshes in Solitude. I regenerated Tamriel without Majestic Mountains so I could take screenshots and upload logs.

EDIDs for the pictured objects respectively:
thegreatcityofsolitudeesp_0147DB_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD
thegreatcityofsolitudeesp_0136D6_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD
thegreatcityofsolitudeesp_0136D4_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD
thegreatcityofsolitudeesp_00C4AE_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD

Logs: https://mega.nz/file/df1xlCja#wuri-b8_PihDzhHkFav5Mt6y6YOSF4HPGE4JVqhHEBA

Edited August 19, 2023 by Blackread

[Mousetick]

11 hours ago, Blackread said:

I also tried setting NoCellsWithNAVM=0 for Riften and Solitude. It worked a treat, the missing objects were added in without any adverse side effects as far as I could tell.

It may not be visible at a glance but a potential adverse side effect is that of breaking NPC pathing. If you blindly copy an object, e.g. a rock, from the parent worldspace's cell into the child, and it ends up in the middle of the navmesh, NPCs may get stuck on it.

Which is why NoCellsWithNAVM=1 by default for safety, I'm guessing, as there is no way to predict whether or how the copied object will conflict with the existing navmesh.

[zangdar72]

Hello, I'm using the 134 version and I noticed a mountain is  "cut" from the lod now

I Can't click on the meshes but I made a video,  Thank you

Log : https://ufile.io/smifk3gt

VIsible on the red circle screen : https://imgur.com/a/AbySSF7

VIdeo : 

I'm using majestic mountain, the parallax version and majestic lanscape 2.0 

https://www.nexusmods.com/skyrimspecialedition/mods/87547

https://www.nexusmods.com/skyrimspecialedition/mods/41857

 

Edited August 17, 2023 by zangdar72

[sheson]

1 hour ago, zangdar72 said:

Hello, I'm using the 134 version and I noticed a mountain is  "cut" from the lod now

I Can't click on the meshes but I made a video, what log should I send if needed?  Thank you

VIsible on the red circle screen : https://imgur.com/a/AbySSF7

VIdeo : 

I'm using majestic mountain, the parallax version and majestic lanscape 2.0 

https://www.nexusmods.com/skyrimspecialedition/mods/87547

https://www.nexusmods.com/skyrimspecialedition/mods/41857

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log and debug log to upload when making posts.

If you can not click full meshes for useful information in screenshots, remove the mod that is causing the problem, e.g. temporarily remove the mod that is adding multipass show shaders.

Why do you believe this has something to do with thew new alpha version and not with any changes in the load order or the settings? Did you verify with an older version and exact same setup and settings otherwise? If so, which version?

This might be related to the terrain underside. Disable LOD with tll in console so the underside remains, click it in console and disable it. Enable LOD again, to see if things look more normal in the distance.

If that is the case, increase the object LOD distances in the DynDOLOD SkyUI MCM Settings.
Consider increasing the height distance of the underside by a bit. https://dyndolod.info/Help/Terrain-Underside#Optional-Configuration and https://dyndolod.info/Help/Terrain-Underside#Updating

[Blackread]

1 hour ago, Mousetick said:

It may not be visible at a glance but a potential adverse side effect is that of breaking NPC pathing. If you blindly copy an object, e.g. a rock, from the parent worldspace's cell into the child, and it ends up in the middle of the navmesh, NPCs may get stuck on it.

Which is why NoCellsWithNAVM=1 by default for safety, I'm guessing, as there is no way to predict whether or how the copied object will conflict with the existing navmesh.

That is true, but I checked pretty much the whole of Riften and couldn't find any rogue objects anywhere.

[Mousetick]

2 hours ago, Blackread said:

That is true, but I checked pretty much the whole of Riften and couldn't find any rogue objects anywhere.

Sure. I wasn't questioning your observations They're valid for your specific load order.

I don't think they can be generalized to any arbitrary load order. So the safe default NoCellsWithNAVM=1 is justified in the absence of custom, load order-specific DynDOLOD_[GAME MODE]_childworld_[WORLDSPACE].ini configuration. It's also a shorthand to limit copying references to cells outside the city walls only (which typically don't have navmeshes in the child worldspace). Blindly copying stuff from the parent worldspace to child cells (wholly or partially) inside the city walls is more likely to produce "rogue" objects inside the walls, as demonstrated by your Solitude example.

Copying is done on an entire cell basis but city walls are not aligned on cell boundaries. Ideally and hypothetically, if only parent worldspace's references placed outside the walls were copied, while the parent areas inside the walls were ignored, this could prevent visually "rogue" objects and navmesh interferences.

It's probably simpler and more efficient to manually fix individual mods than trying to find a generic solution.

[Blackread]

30 minutes ago, Mousetick said:

Sure. I wasn't questioning your observations They're valid for your specific load order.

I don't think they can be generalized to any arbitrary load order. So the safe default NoCellsWithNAVM=1 is justified in the absence of custom, load order-specific DynDOLOD_[GAME MODE]_childworld_[WORLDSPACE].ini configuration. It's also a shorthand to limit copying references to cells outside the city walls only (which typically don't have navmeshes in the child worldspace). Blindly copying stuff from the parent worldspace to child cells (wholly or partially) inside the city walls is more likely to produce "rogue" objects inside the walls, as demonstrated by your Solitude example.

Copying is done on an entire cell basis but city walls are not aligned on cell boundaries. Ideally and hypothetically, if only parent worldspace's references placed outside the walls were copied, while the parent areas inside the walls were ignored, this could prevent visually "rogue" objects and navmesh interferences.

It's probably simpler and more efficient to manually fix individual mods than trying to find a generic solution.

Very true, and I have barely any mods modifying the exterior areas of cities, with Solitude being the exception, so my load order is fairly easy on that regard.

[Blackread]

I noticed that some dock corner pieces are rotated 90 degrees clockwise in the LOD, despite the lod and full model meshes being perfectly aligned. Here are pictures of one example:

Caption for the pictures in their order of appearance:
1. The dock copy as seen in the child worldspace (SolitudeWorld)
2. The dock LOD as seen in the child worldspace
3. The original dock as seen in the parent worldspace (Tamriel)
4. The dock LOD as seen in the parent worldspace

EDID of the dock copy: skyrimesm_01991F_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD

Logs: https://mega.nz/file/8adAyAyb#MD_N7VeQYpMyLxIRf2nGm5IlU-2YVMgbRBro4r2kWY4

The full model dock is from Static Mesh Improvement Mod, and the LOD model is from DynDOLOD Resources SE.

Edited August 17, 2023 by Blackread

[sheson]

19 hours ago, Blackread said:

Update:

I tried hiding the landscape as you suggested, but force hiding the quads made no difference in the xLODGen terrain LOD output. I instead made a plugin with which I dug a "hole" (or a valley) into the hill where the mine entrance is, that got rid of the terrain LOD in the tunnel, and the underside too.

I am going to answer to each thing in a separate posts. If there is something I haven'r replied to in say a week (and it is still present after any updates that I might release in the meantime) feel free to post a reminder for that particular issue.

So far the hide quad flag was only used for terrain under side generation. Get xLODGen beta 99 that now has a corresponding check box for LOD level 4.
Unless the hidden quads are properly covered by LOD objects, the holes might become very visible. That is probably one of the reassons CK doesn't do it for terrain LOD generation.
Hence disabled by default. If you know the exact filename of the terrain LOD mesh, just use Specific Chunk: 4, -44, 0 for example.

[sheson]

2 hours ago, Blackread said:

I noticed that some dock corner pieces are rotated 90 degrees clockwise in the LOD, despite the lod and full model meshes being perfectly aligned. Here are pictures of one example:

Caption for the pictures in their order of appearance:
1. The dock copy as seen in the child worldspace (SolitudeWorld)
2. The dock LOD as seen in the child worldspace
3. The original dock as seen in the parent worldspace (Tamriel)
4. The dock LOD as seen in the parent worldspace

EDID of the dock copy: skyrimesm_01991F_SolitudeWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD

Logs: https://mega.nz/file/8adAyAyb#MD_N7VeQYpMyLxIRf2nGm5IlU-2YVMgbRBro4r2kWY4

The full model dock is from Static Mesh Improvement Mod, and the LOD model is from DynDOLOD Resources SE.

Will be fixed next alpha version of DynDOLOD Resources.

[Mousetick]

About https://dyndolod.info/Help/Child-Parent-Worldspace-Copies

Quote

Specific Reference Matching

If the same reference is listed for both, it means it does not have a match in the other worldspace but should also be ignored for copying.

In case a mod requires manual additions to specifically match references or to ignore them for copying, make a post on the official DynDOLOD support forum so the data can be added for all users in a future update.

• Does this mean ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_[GAME MODE]_ChildworldMatches.txt is off-limit to end-users?
• How should an end-user proceed to exclude specific references from copying without requesting an official update, which may not be applicable to all users?

Thank you.

[sheson]

30 minutes ago, Mousetick said:

About https://dyndolod.info/Help/Child-Parent-Worldspace-Copies

• Does this mean ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_[GAME MODE]_ChildworldMatches.txt is off-limit to end-users?
• How should an end-user proceed to exclude specific references from copying without requesting an official update, which may not be applicable to all users?

Thank you.

Users who do not want to edit the configuration file themselves can post on the official DynDOLOD support forum with logs and useful screenshots, thus help improve the tools for everyone and themselves with the next update.

Users who can edit the configuration file with the help of the explanations can at the same time post the edits to the official DynDOLOD support forum to help improve the tools for everyone without having to wait for the update to be released. Once they install the new version, the changes are included and they won't have to remember to edit the configuration file again.

[Blackread]

3 hours ago, sheson said:

I am going to answer to each thing in a separate posts. If there is something I haven'r replied to in say a week (and it is still present after any updates that I might release in the meantime) feel free to post a reminder for that particular issue.

So far the hide quad flag was only used for terrain under side generation. Get xLODGen beta 99 that now has a corresponding check box for LOD level 4.
Unless the hidden quads are properly covered by LOD objects, the holes might become very visible. That is probably one of the reassons CK doesn't do it for terrain LOD generation.
Hence disabled by default. If you know the exact filename of the terrain LOD mesh, just use Specific Chunk: 4, -44, 0 for example.

Thank you I got the terrain LOD to work now. However, the underside is still in the way. For some reason it looks like I'm getting a hole in the cell -43, -1 where I hid quads 3 and 4, but not in the cell -43, 0 where I hid quads 1,2,3 and 4.

First picture is from inside the mine tunnel, looking towards Markarth. The last picture is from under the terrain. The black tube is the mine tunnel, which pierces the underside. The gap in the underside is visible above it.

Logs and the plugin I used to hide the terrain. It was placed dead last in my load order while generating, so shouldn't be overwritten by anything. https://mega.nz/file/RG1mAbKC#4dlXjUlkrZkNXjB_JcCYHyl3sF8TO3-MkbMMJBKOvzE

[sheson]

2 minutes ago, Blackread said:

Thank you I got the terrain LOD to work now. However, the underside is still in the way. For some reason it looks like I'm getting a hole in the cell -43, -1 where I hid quads 3 and 4, but not in the cell -43, 0 where I hid quads 1,2,3 and 4.

First picture is from inside the mine tunnel, looking towards Markarth. The last picture is from under the terrain. The black tube is the mine tunnel, which pierces the underside. The gap in the underside is visible above it.

Logs and the plugin I used to hide the terrain. It was placed dead last in my load order while generating, so shouldn't be overwritten by anything. https://mega.nz/file/RG1mAbKC#4dlXjUlkrZkNXjB_JcCYHyl3sF8TO3-MkbMMJBKOvzE

Upload the terrain BTR and the underside NIF.