DynDOLOD 3.00 Alpha 180

[sheson]

17 minutes ago, DarkladyLexy said:

Shouldn't i have deleted the old version, installed the new purged the logs and cache, and generated a fresh version of texgen with Alpha 134

Each new DynDOLOD release should be unpacked to a new empty folder.

https://dyndolod.info/Updating#New-DynDOLOD-Version
Always install DynDOLOD Standalone into a new or empty folder. Always replace old DynDOLOD Resources.

DynDOLOD 3 Alpha-134 has this as the first logline:
DynDOLOD 3.0 Alpha-134 x64 - Skyrim Special Edition (SSE) (B365340B) starting session YYYY-MM-DD HH:MM:SS

However, the missing billboard error is unrelated to which version is being used. It is about required LOD assets not being found in the data folder.

[Blackread]

I would like to know more about the new heighmap options added in the INI. I tried looking on the website and doing a search in this thread but couldn't find where they were explained.

; Set to 1 to create terrain heightmap textures
DoTerrainHeightMap=0

Does the heightmap in this context mean the heightmap used by things like the parallax shader, or something else?

Edited August 15, 2023 by Blackread

[sheson]

1 hour ago, Blackread said:

I would like to know more about the new heighmap options added in the INI. I tried looking on the website and doing a search in this thread but couldn't find where they were explained.

; Set to 1 to create terrain heightmap textures
DoTerrainHeightMap=0

Does the heightmap in this context mean the heightmap used by things like the parallax shader, or something else?

I added export of the native terrain height data to a texture/image for doodlum for a test. It is also part of not yet released xLODGen terrain LOD beta.

The readme has a bit of information.

Terrain-Heightmap-Readme.txt

[Blackread]

I've been testing the new parent/child copy feature, and so far looking great, thank you so much for adding this in. There were a couple things I wanted to ask about though.

In some places objects seem to be missing. The places I found where this is visible without console hacking are the Dragonborn Museum Safehouse balcony in Solitude and in front of the Honorhall Orphanage looking towards the Riften fishery in Riften. I assume this is because cells containing refs in the child world don't receive any refs from the parent world, or something along those lines?

Another thing I noticed is that refs in the parent world that have had their base objects swapped with Base Object Swapper use their original base records in the child world. Here are two pictures from the Whiterun stables to demonstrate. The first one shows the fences as they appear in the parent world (Tamriel) having been swapped with BOS, the second shows them in the child world (WhiterunWorld) using the original base record. This is of course quite minor and barely noticeable, but just wanted to make sure whether it's because Base Object Swapper is not supported for this feature, or if there is a bug of some sort.

Lastly, at least in MarkarthWorld there seem to be some issues with large references. The first picture is taken with uLargeRefLODGridSize=5, the second with uLargeRefLODGridSize=9. The bridge and some other large objects disappear when they enter the large ref grid. I have added the "Use LOD Data" flag to the Parent worldspace field of MarkarthWorld so that Markarth uses the Tamriel LOD instead of its own LOD.

Here's a link to the logs: https://mega.nz/file/RWFHgJ4C#3_wi91qevRJLXpEbAIXO57E_XrgJsTemNRkq1jOFxOo

 

Almost forgot, there were also these things:

The first picture is from Evermore in Beyond Reach, the second is the entrance to Cidhna Mine in Markarth. To my eyes it looks like either LOD or the underside mesh, but I wasn't able to target it in console so I assume it's the former, unless things have changed.

Edit: Remembered the tll command. Using it made the low res objects disappear, so they indeed are LOD.

Edited August 16, 2023 by Blackread

[sheson]

10 hours ago, Blackread said:

I've been testing the new parent/child copy feature, and so far looking great, thank you so much for adding this in. There were a couple things I wanted to ask about though.

In some places objects seem to be missing. The places I found where this is visible without console hacking are the Dragonborn Museum Safehouse balcony in Solitude and in front of the Honorhall Orphanage looking towards the Riften fishery in Riften. I assume this is because cells containing refs in the child world don't receive any refs from the parent world, or something along those lines?

Another thing I noticed is that refs in the parent world that have had their base objects swapped with Base Object Swapper use their original base records in the child world. Here are two pictures from the Whiterun stables to demonstrate. The first one shows the fences as they appear in the parent world (Tamriel) having been swapped with BOS, the second shows them in the child world (WhiterunWorld) using the original base record. This is of course quite minor and barely noticeable, but just wanted to make sure whether it's because Base Object Swapper is not supported for this feature, or if there is a bug of some sort.

Lastly, at least in MarkarthWorld there seem to be some issues with large references. The first picture is taken with uLargeRefLODGridSize=5, the second with uLargeRefLODGridSize=9. The bridge and some other large objects disappear when they enter the large ref grid. I have added the "Use LOD Data" flag to the Parent worldspace field of MarkarthWorld so that Markarth uses the Tamriel LOD instead of its own LOD.

Here's a link to the logs: https://mega.nz/file/RWFHgJ4C#3_wi91qevRJLXpEbAIXO57E_XrgJsTemNRkq1jOFxOo

 

Almost forgot, there were also these things:

The first picture is from Evermore in Beyond Reach, the second is the entrance to Cidhna Mine in Markarth. To my eyes it looks like either LOD or the underside mesh, but I wasn't able to target it in console so I assume it's the former, unless things have changed.

Edit: Remembered the tll command. Using it made the low res objects disappear, so they indeed are LOD.

Cells with navmeshes are ignored by default for some child worldspaces atm.

https://dyndolod.info/Help/Child-Parent-Worldspace-Copies#Settings-for-Parent-gt-Child
NoCellsWithNAVM - set to 1 to not copy references from the parent worldspace if the child worldspace cell contains a nav mesh. Use to only copy reference that are really outside the walled cities.
Settin NoCellsWithNAVM=0 for Solitude, Riften should address the views. 

For copies, not all possible conditional features of BOS are supported yet. I assume the fences are using locational swaps. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make screenshots of objects showing usefull information with the More Informative Console mod. Provide a link to the mod adding the swaps.

Regarding Markarth, parent child worldspace copies are made after LOD is generated for a worldspace. By default Markarth does not use the Tamriel parent worldspace for LOD. When its own LOD is generated, there is no reference adding the bridge, hence it has no LOD. If you set ScanParent=1 for Markarth and you also want LOD to match, edit the Markarth worldspace record and set the flag to use the LOD of Tamriel.

Get the cell coordinates and terrain LOD filename from DynDOLOD SkyUI MCM - You are here to check the CELL and LAND records and the terrain LOD meshes. Make sure terrain LOD is generated for the load order in high enough quality. If necessary also check the object LOD meshes for culprits.

[xbk123]

Hi. Is it normal that every time I start the game and load last save the message appears `dyndolod initialized successfully`? Maybe not every time but quite often. It already initialized with success when I first start new game. But now Im lvl 10 and it still happens. Never had it with earlier versions like 128/129/130 etc. Im using version 133 now. Everything seems to work fine but thought I will ask here in case thats indication something is not right. Thanks. 

[Blackread]

10 hours ago, sheson said:

Cells with navmeshes are ignored by default for some child worldspaces atm.

https://dyndolod.info/Help/Child-Parent-Worldspace-Copies#Settings-for-Parent-gt-Child
NoCellsWithNAVM - set to 1 to not copy references from the parent worldspace if the child worldspace cell contains a nav mesh. Use to only copy reference that are really outside the walled cities.
Settin NoCellsWithNAVM=0 for Solitude, Riften should address the views. 

For copies, not all possible conditional features of BOS are supported yet. I assume the fences are using locational swaps. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make screenshots of objects showing usefull information with the More Informative Console mod. Provide a link to the mod adding the swaps.

Regarding Markarth, parent child worldspace copies are made after LOD is generated for a worldspace. By default Markarth does not use the Tamriel parent worldspace for LOD. When its own LOD is generated, there is no reference adding the bridge, hence it has no LOD. If you set ScanParent=1 for Markarth and you also want LOD to match, edit the Markarth worldspace record and set the flag to use the LOD of Tamriel.

Get the cell coordinates and terrain LOD filename from DynDOLOD SkyUI MCM - You are here to check the CELL and LAND records and the terrain LOD meshes. Make sure terrain LOD is generated for the load order in high enough quality. If necessary also check the object LOD meshes for culprits.

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

Another edit:

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

Edited August 16, 2023 by Blackread

[sheson]

1 hour ago, xbk123 said:

Hi. Is it normal that every time I start the game and load last save the message appears `dyndolod initialized successfully`? Maybe not every time but quite often. It already initialized with success when I first start new game. But now Im lvl 10 and it still happens. Never had it with earlier versions like 128/129/130 etc. Im using version 133 now. Everything seems to work fine but thought I will ask here in case thats indication something is not right. Thanks. 

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

As explained, this is in ALPHA test to find and report bugs. If you using the experimental large reference bugs workarounds DynDOLOD DLL NG and Scripts, also an ALPHA test, then the message is expected to show after loading a save as well. Also see https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Testing

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