Weird Water Seam (Non-LOD) at Docks, Only Appears When DynDOLOD Output is Enabled

[LF111]

Back again I am with some water stuff, only this time I'm unsure of how exactly DynDOLOD could be the issue, although the problem completely disappears when disabling DynDOLOD. 

I am getting a hard water seam at the Riften Docks, seen in pictures here. (Note: the second picture has both RW2 and DynDOLOD disabled, as I originally reported this on the RW2 page, but I can confirm that there is still no seam when enabling RW2 but keeping DynDOLOD disabled). This seam is basically a big square under the docks where water flows directly toward Riften, while water outside the seam flows as it usually does in lakes. 

Logs are here. Let me know if there are any access issues (files were too large to submit through other means). 

Again, I don't quite know how DynDOLOD could be at fault here since the seam isn't with LOD water, but I figured I'd ask anyway. Again, the problem only disappears when disabling the DynDOLOD output. 

Edit: I tried generating my outputs again with the Better Big Boat LOD mod (Better Big Boat LOD at Skyrim Special Edition Nexus - Mods and Community) disabled, as I noticed that I was having the same issue at the Solitude docks, specifically next to the large ship (pics here), which led me to think that perhaps that was the issue (since it overwrites DynDOLOD Resources). Unfortunately, disabling that mod and regenerating did not solve the issue, so that mod does not appear to be the culprit. 

Edited February 13 by LF111

[sheson]

  On 2/14/2025 at 9:51 PM, LF111 said:

xEdit Results

Occlusion.esp is not matching the preceding RW2 record in the cell at the Riften Docks, and is instead matching the records of the mods that precede RW2, which I believe is what's causing the seam. 

Every LOD generation has been done with RW2 enabled, so I don't know why DynDOLOD isn't matching it. I can confirm the three generations done over the last two days have all been on the exact same load order, with no mod being added or subtracted after enabling the TexGen and DynDOLOD outputs, other than an High Poly Project rock wall retexture I only enable after generation, as generating with it enabled results in white LOD textures for the walls (and just to be safe, I did a generation with it enabled the whole time, and predictably it had nothing to do with the water issue). 

Expand  

Thanks.

Test generating a LOD patch with occlusion with this test version of DynDOLOD https://mega.nz/file/4UgGCZyS#fUL-ZguHbBj6LNufacgzEeUkD4hfIeSo7izaXxuzVak

Then check the cell record again if it contains the expected water record and check visuals in the game are as expected.

If not, upload new logs.

[sheson]

  On 2/13/2025 at 3:49 AM, LF111 said:

Back again I am with some water stuff, only this time I'm unsure of how exactly DynDOLOD could be the issue, although the problem completely disappears when disabling DynDOLOD. 

I am getting a hard water seam at the Riften Docks, seen in pictures here. (Note: the second picture has both RW2 and DynDOLOD disabled, as I originally reported this on the RW2 page, but I can confirm that there is still no seam when enabling RW2 but keeping DynDOLOD disabled). This seam is basically a big square under the docks where water flows directly toward Riften, while water outside the seam flows as it usually does in lakes. 

Logs are here. Let me know if there are any access issues (files were too large to submit through other means). 

Again, I don't quite know how DynDOLOD could be at fault here since the seam isn't with LOD water, but I figured I'd ask anyway. Again, the problem only disappears when disabling the DynDOLOD output. 

Edit: I tried generating my outputs again with the Better Big Boat LOD mod (Better Big Boat LOD at Skyrim Special Edition Nexus - Mods and Community) disabled, as I noticed that I was having the same issue at the Solitude docks, specifically next to the large ship (pics here), which led me to think that perhaps that was the issue (since it overwrites DynDOLOD Resources). Unfortunately, disabling that mod and regenerating did not solve the issue, so that mod does not appear to be the culprit. 

Expand  

If the problem happens only with the DynDOLOD output disabled, it typically means the current output and active DynDOLOD plugins were for a different load order.

DynDOLOD copies wordspace and cell records - which are define the water - from the winning plugins.
If you are certain everything looks correct without the output active, generate new output from scratch and it should look the same.
If that is not the case, check an affected cell record in xEdit, that DynDOLOD indeed contains the same water record definition as the plugin before it. If you need help how to do that, just ask.

[LF111]

I can confirm that the outputs match the load order. I tested again with the Alpha 185 release from today and got the same issue, so that's 3 fresh generations at this point. Everything looks normal until the output is enabled.

Edit: Found an additional seam that covers basically the entire area underneath the Solitude arch. Interestingly enough, though, the docks at Dawnstar, Windhelm, and Raven Rock aren't affected at all. Here are some pics of underneath the arch. An entirely different type of water flow is being activated, hard seaming with areas flowing correctly. 

Another interesting thing I've noticed is that there is no seam when viewing that same spot (from the first pics I sent, of the Riften Docks) from within the Riften child worldspace (pic). The seam only exists when in the parent Tamriel worldspace (apologies if I'm using terminology wrong).  

Would you mind walking me through how to check this in xEdit? I'm used to just entering the ID names, but neither of the IDs returned to me by the console for the water (ff000ea6 and ff000e94) give me any results in xEdit. Could be those IDs aren't for water (although no other IDs pop up when I attempt to scroll through the More Informative Console results), or that you can't search for water like that? I don't really know. 

Edited February 14 by LF111

[sheson]

  On 2/13/2025 at 8:11 PM, LF111 said:

I can confirm that the outputs match the load order. I tested again with the Alpha 185 release from today and got the same issue, so that's 3 fresh generations at this point. Everything looks normal until the output is enabled.

Edit: Found an additional seam that covers basically the entire area underneath the Solitude arch. Interestingly enough, though, the docks at Dawnstar, Windhelm, and Raven Rock aren't affected at all. Here are some pics of underneath the arch. An entirely different type of water flow is being activated, hard seaming with areas flowing correctly. 

Another interesting thing I've noticed is that there is no seam when viewing that same spot (from the first pics I sent, of the Riften Docks) from within the Riften child worldspace (pic). The seam only exists when in the parent Tamriel worldspace (apologies if I'm using terminology wrong).  

Would you mind walking me through how to check this in xEdit? I'm used to just entering the ID names, but neither of the IDs returned to me by the console for the water (ff000ea6 and ff000e94) give me any results in xEdit. Could be those IDs aren't for water (although no other IDs pop up when I attempt to scroll through the More Informative Console results), or that you can't search for water like that? I don't really know. 

Expand  

Go with the player to the cell that as the problem.

Open the DynDOLOD SkyUI MCM - You Are Here page. https://dyndolod.info/Help/Mod-Configuration-Menu-NG#You-Are-Here

Take note of the reported Cell coordinates.

Load the load order in xEdit. Start the Cell Browser with CTRL + SHIFT + F

Enter the cell coordinates and select the worldspace Tamriel and click OK.

Once it loaded the cell record, in the right window check that the last DynDOLOD and Occlusion plugin are identical to the last plugin before them.
If they are not and you are sure that the last plugin before them was the last plugin when the LOD was generated, make a screenshot and upload it.
https://dyndolod.info/Official-DynDOLOD-Support-Forum#xEdit-Screenshots

[LF111]

xEdit Results

Occlusion.esp is not matching the preceding RW2 record in the cell at the Riften Docks, and is instead matching the records of the mods that precede RW2, which I believe is what's causing the seam. 

Every LOD generation has been done with RW2 enabled, so I don't know why DynDOLOD isn't matching it. I can confirm the three generations done over the last two days have all been on the exact same load order, with no mod being added or subtracted after enabling the TexGen and DynDOLOD outputs, other than an High Poly Project rock wall retexture I only enable after generation, as generating with it enabled results in white LOD textures for the walls (and just to be safe, I did a generation with it enabled the whole time, and predictably it had nothing to do with the water issue). 

Edited February 14 by LF111

[LF111]

The new exe fixed the issue. The xEdit records match and the seams have been eliminated everywhere in the game that I was aware of them. Many thanks. 

 

[ra2phoenix]

Ran a basic test with just USSEP and Water for ENB enabled, on the current release version.

Some cells that are broken:

x9712, 9713, 9732, 963A, 97A0

I see in the logs that's it's copying the esm data on the affected cells. Logs attached: https://www.dropbox.com/scl/fi/l3iymffwkb39y50jcjps8/OcclusionLogs.7z?rlkey=1wg3l4n7htww7oa51a9dirtoh&dl=0

Reran the test with the beta exe linked above, and all of the issues appear to be fixed.  I'll give my full load order a test with the exe to see if the various Encounter Zones, EdIDs, etc. are also correct but it looks like it should be good now.

[ra2phoenix]

Ran the test exe on my full load order and confirmed all problems forwarding into Occlusion.esp are resolved.

[sheson]

  On 2/15/2025 at 8:00 PM, LF111 said:

The new exe fixed the issue. The xEdit records match and the seams have been eliminated everywhere in the game that I was aware of them. Many thanks. 

Expand  

Thanks for letting us know the test version fixed the issue.

Now with that solved, I suggest to make a new issue report about the "High Poly Project rock wall retexture". There should be no reason to temporality disable mods or for LOD having white textures if the full model doesn't.