Interesting Water LOD Interaction with Realistic Waters 2 on Alpha 180

[LF111]

I've noticed an interesting effect on distant water LOD after updating from 3.00 Alpha 173 to Alpha 180. I use Realistic Waters Two for my water mod and I use doodlum's Sky Reflection Fix to solve the uh... sky reflection problem, therefore allowing me to leave bReflectSky enabled in Skyrim's .ini files. Yesterday, I updated from RWT 5.6 to 5.7.1 and updated DynDOLOD to Alpha 180. Generating LOD caused the reflection bug to return; you can see the images here. The only way to get rid of this bug is to disable bReflectSky in the .ini files, but this has negative impacts on water reflections and is something that I never had to do in the past. Using Sky Reflection Fix should prevent you from having to disable bReflectSky, but when generating LOD with Alpha 180, it no longer does so. Turning DynDOLOD off (while leaving bReflectSky on and not touching the load order) solves the bug, as does reverting to my previous LOD generation from Alpha 173. The problem appears to specifically be an interaction between Alpha 180 and either RWT 5.7.1 or Sky Reflection Fix. I haven't tried generating without either of those mods on, so I cannot confirm if it is solely a DynDOLOD issue (though I'd imagine there'd be a lot more reports if that were the case). 

Summary: Alpha 180 appears to be causing a water LOD reflection bug to appear that wasn't there before, holding load order and .ini settings constant. 

I've already reached out to the authors of both of those mods, but I thought I'd make a post here to cover all my bases. 

 

 

 

Log | Debug Log (I have no idea why the debug log is so massive, and since I was unable to get it to fit on Paste.ee, I've attached the link to download it on Ufile)

Edited September 13 by LF111

[sheson]

The issue that could probably happen regarding LOD water would be an outdated worldspace record in the last plugin after changing the load order.

See https://dyndolod.info/Help/Terrain-LOD-and-Water-LOD
At the moment DynDOLOD does not create, update or otherwise change terrain LOD or water LOD.
How the LOD water looks for an entire worldspace is defined by worldspace record. How water looks in an active cell is defined by the cell record. The worldspace and cell records from the winning plugins are copied to create the DynDOLOD or Occlusion plugins. Hence the load order needs to be finalized before generating the LOD patch with DynDOLOD and/or generating Occlusion.esp.

https://dyndolod.info/Updating#New-or-Updated-Mods-or-Plugins
If a plugin is added or updated it is possible that there are new conflicts which require solving. This can either be manual conflict resolution or updating or generating LOD from scratch.

[LF111]

Update: I tested the current version of DynDOLOD on RW2 v5.6, and everything is fine. It's not a DynDOLOD issue, but an RW2 issue regarding DynDOLOD. 

 

Edited September 13 by LF111
Removing unnecessary info; didn't know replies merged

[LF111]

Apologies if I'm misunderstanding your reply, but are you saying it's a load order problem or a specific problem within the newest RWT? My load order was unchanged during testing, only switching between RWT and DynDOLOD versions to identify the culprit. Generating LOD from scratch with a finalized load order containing RWT 5.7.1 results in the reflection bug occurring no matter what, while generating LOD from scratch with a finalized load order containing RWT 5.6 does not. Since this is true regardless of DynDOLOD alpha versions (something I only found out after making my initial post), it appears that the problem is entirely within RWT 5.7.1; somehow, running it through DynDOLOD causes it to not respond to doodlum's Sky Reflection Fix mod, whereas past versions were responsive. 

I trust that the problem isn't being caused by DynDOLOD itself as, as you said, DynDOLOD doesn't generate water LOD, but since the water bug only happens after generating LOD (without DynDOLOD, Sky Reflection Fix works correctly with RWT 5.7.1), I thought I'd ask to see if there might be something weird going on regarding mod interactions. Judging by a number of DynDOLOD-related complaints on the RWT page recently, I think the problem is on their end, or SRF needs a patch. 

I re-ran LODGen as well, but that did not solve the issue. Again, I don't think that this is a LOD problem, but a RWT problem that is somehow only surfacing after running DynDOLOD. 

Let me know if I misunderstood your reply, but considering I'm generating from scratch with a finalized load order, I don't think there could be an outdated worldspace record.

Another edit: Using the tll console command to turn off LOD leaves the water problem intact (see here), so it's not just the water LOD that's messed up but the water in general, yet the bug only manifests after running DynDOLOD and enabling the output. 

Edited September 14 by LF111
new info

[z929669]

This is the location:

I'm running the Step SkyrimSE 2.3 build with ENB, including RWT 5.7.1 and DynDOLOD output generated with Alpha 178 (haven't had reason to regen LOD again yet). RWT esp is last to load before CR patches. It does edit this worldspace, and cells -4 -15, -4 -16, and -3 -15, which basically look identical to this record (Occlusion.esp is last to edit):

 

bReflectSky off:

bReflectSky on:

bReflectSky on w/Sky Reflection Fix enabled:

 

No bug for me.

In fact, I'm wondering why we are recommending bReflectSky be set to 'off' in our guide. It looks better on.

Lastly, Sky Reflection Fix does nothing in this build. I tested moving around without issues.

Summary
All I discovered is that there is no bug with RWT 5.7.1, bReflectSky should probably be 'on', and Sky Reflection Fix doesn't fix anything (unless I'm missing something obvious).

---

PS: Tested with ENB disabled just in case Boris fixed the bug:

Still no bug. Now I'm wondering if this is fixed with 1130+

---

After a sidebar with a more knowledgeable person, I've come to suspect that the bug in the OP isn't the Sky Reflection Fix bug. It looks more like a fog bug I've seen with certain weathers and ENB settings.

---

Confirmed. Here's the sky reflection bug that Sky Reflection Fix resolves (most noticeable in 3rd person with camera backed all the way off). Step will be picking up this mod and recommending bReflectSky be 'on' in next update.

SR bug:

Fixed with SRF mod:

[LF111]

Man, now I'm even more confused. I've also done some more testing with enabling/disabling stuff, and I legit can't explain what's happening right now: if I leave the "DynDOLOD_Output" mod enabled in Vortex but disable the dyndolod esm, dyndolod esp, and occlusion esp plugins, the bug remains; the bug only goes away if I disable the mod. How is this any different from disabling the three plugins individually? Sorry if that's a stupid question. 

Edited September 14 by LF111

[z929669]

9 minutes ago, LF111 said:

Man, now I'm even more confused. I've also done some more testing with enabling/disabling stuff, and I legit can't explain what's happening right now: if I leave the "DynDOLOD_Output" mod enabled in Vortex but disable the dyndolod esm, dyndolod esp, and occlusion esp plugins, the bug remains; the bug only goes away if I disable the mod. How is this any different from disabling the three plugins individually?

Not sure. sheson may know.

I suspect it's related to your weather mod though.

See the final post script on my previous for validation of Sky Reflection Fix.

[LF111]

Interesting, although it is worth noting that the bug does go away if disabling bReflectSky. I'm using Azurite Weathers and Seasons (specifically Azurite Weathers II) with Community Shaders. Nothing changed about either of those when moving from RWT 5.6 to 5.7.1. And the bug only occurs when running DynDOLOD on 5.7.1; I did a test run on 5.6 (no other load order changes) and the bug didn't surface, so if it's a weather mod issue then there's some really funky interaction going on.

[LF111]

Grabbed some more pictures showing the problem from different angles here. Might be helpful in determining whether or not this is specifically the bReflectSky bug (though I'm fairly certain it is). 

[z929669]

5 minutes ago, LF111 said:

Grabbed some more pictures showing the problem from different angles here. Might be helpful in determining whether or not this is specifically the bReflectSky bug (though I'm fairly certain it is). 

I see what you mean, but the reason I don't think it's the Reflect Sky bug is because the issue you're showing doesn't look like a cubemap problem. It's more a LOD water problem. Load one of those saves and invoke tll via the console, so we can see if this impacts only the LOD water. I went just above the standing stones here. And I think this is just the different tiling of the LOD water textures:

LOD:

bReflectSky disabled:

bReflectSky enabled w/SRF mod:

bReflectSky enabled wo/SRF mod (no perceptible diff from previous, hence not the SR bug, IMO):

The SR bug is really only apparent when you have a wide-angle view of water filling up most of the screen. Otherwise, it's really only applicable to 3rd person, which I don't play.

[LF111]

It appears to effect the distant edge of loaded water and not just LOD water, pics. 

Edit: Okay, maybe it is just LOD water (pics)

 

Edited September 14 by LF111

[LF111]

Confirmation it's the bReflectSky bug: the Riverwood watermill (pics). AFAIK, this visual error is caused specifically by the sky reflection bug. 

So, to recap, running DynDOLOD on 5.7.1 causes the bug to act up (even though Sky Reflection Fix is supposed to fix it and has for me in the past) but only when the actual "DynDOLOD_Output" mod is enabled; disabling all three plugins but not the mod does not fix the issue, only disabling the mod or setting bReflectSky to 0 (which I shouldn't have to do with SRF) fixes it. 

[z929669]

1 hour ago, LF111 said:

It appears to effect the distant edge of loaded water and not just LOD water, pics. 

Edit: Okay, maybe it is just LOD water (pics)

 

Re-read sheson's post. I think you need to look closely at the worldspace record, since that defines how water and terrain look in LOD. DynDOLOD and Occlusion are just copying the winning records into the LOD patch.

17 minutes ago, LF111 said:

Confirmation it's the bReflectSky bug: the Riverwood watermill (pics). AFAIK, this visual error is caused specifically by the sky reflection bug. 

So, to recap, running DynDOLOD on 5.7.1 causes the bug to act up (even though Sky Reflection Fix is supposed to fix it and has for me in the past) but only when the actual "DynDOLOD_Output" mod is enabled; disabling all three plugins but not the mod does not fix the issue, only disabling the mod or setting bReflectSky to 0 (which I shouldn't have to do with SRF) fixes it. 

This may be one aspect of the Sky Reflection bug, IDK, but this is different from your water LOD problem, IMO.

 

Disable your ENB to remove it from the equation and test again (assuming you are using an ENB)

This is my setup (with ENB, DynDOLOD and RWT 5.7.1, vReflectSky enabled, SRF enabled). No weird lighting on this waterwheel. This issue may be your ENB [IMAGEBASEDLIGHTING] or [SKYLIGHTING], and it may be completely different from the problem in the OP.

[z929669]

Wait, you are using CS, so never mind. It may be your CS setup in that case

So look at 00009BB5 in xEdit

[LF111]

All I know is that the watermill bug, as with the main bug I've been describing, goes away when I disable my DynDOLOD output (or disable bReflectSky), regardless of CS setup. I got a reply from one of the RWT guys and am testing regenerating LOD on a 5.7.1 version that has the DefaultWater.dds from 5.6, as that is what they wanted me to test after reading about the mod/plugin quirk. Hopefully (maybe) that works. I'll look around in xEdit if that fails.

Edited September 14 by LF111

[z929669]

6 minutes ago, LF111 said:

All I know is that the watermill bug, as with the main bug I've been describing, goes away when I disable my DynDOLOD output (or disable bReflectSky), regardless of CS setup. I got a reply from one of the RWT guys and am testing regenerating LOD on a 5.7.1 version that has the DefaultWater.dds from 5.6, as that is what they wanted me to test after reading about the mod/plugin quirk. Hopefully (maybe) that works. I'll look around in xEdit if that fails.

Maybe it will work for you, but it's unnecessary for me, so it would be useful if you could show us what you have for 00009BB5