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]

5 hours ago, LF111 said:

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?

The last plugin to overwrite the worldspace record defines which water record is used for LOD. If you start changing the load order underneath without making sure the definition might become wrong. You need to make sure the correct record for the water LOD is defined by the winning plugin.

3 hours 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? Sorry if that's a stupid question. 

Make extra sure that disabling/enabling mods and deploying in Vortex actually has the desired effect in the physical data folder by double checking the actual files.

We encountered issues with water reflections caused by certain effect shader settings in object LOD meshes about 2 years ago. Though, that specific case didn't look like this and has been fixed.

If just hiding the meshes folder from the DynDOLOD output has an effect on the issue, then use binary search to narrow it down to a specific or a handful of files: hide half the Tamriel*.BTO files, if the error goes away, hide the other half. Continue to do so until only one or a handful files remain. Then upload those files.

[LF111]

Here's what pops up for 00009BB5. I'm extremely unfamiliar with how to actually use xEdit, but obviously something's wrong from all the red. 

Hiding all of the Tamriel BTO files worked, so I'm working on narrowing it down right now. I suspect the problem is whatever xEdit's showing me, however. Although on second glance it seems to look the same as z92's from earlier. 

Edited September 14 by LF111

[sheson]

1 hour ago, LF111 said:

Here's what pops up for 00009BB5. I'm extremely unfamiliar with how to actually use xEdit, but obviously something's wrong from all the red. 

Hiding all of the Tamriel BTO files worked, so I'm working on narrowing it down right now. I suspect the problem is whatever xEdit's showing me, however. Although on second glance it seems to look the same as z92's from earlier. 

The defined water record in cells is irrelevant for LOD. LOD water users the water record defined on the winning worldspace record.

[LF111]

I've identified three problem files causing the bug in the Tamriel BTO files:

Tamriel.4.8.-8.bto 

Tamriel.4.-24.-12.bto 

Tamriel.4.8.-4.bto

MB file size limit is preventing me from attaching the other two; let me know if they need to be attached at all or if it's enough to just name them. 

There's at least one more, but I am tired to the point of delirium right now and will find it later today. 

Tamriel.4.8.-8.bto

Edited September 14 by LF111

[sheson]

1 hour ago, LF111 said:

I've identified three problem files causing the bug in the Tamriel BTO files:

Tamriel.4.8.-8.bto 

Tamriel.4.-24.-12.bto 

Tamriel.4.8.-4.bto

MB file size limit is preventing me from attaching the other two; let me know if they need to be attached at all or if it's enough to just name them. 

There's at least one more, but I am tired to the point of delirium right now and will find it later today. 

Tamriel.4.8.-8.bto 1.79 MB · 0 downloads

Just use a free file service like you did with the debug log.

[sheson]

Replace C:\Skyrim DynDOLOD\DynDOLOD 3.00-68518-Alpha-180-1724627136\DynDOLOD\Edit Scripts\LODGenx64Win.exe with this version https://mega.nz/file/IUYk3J5C#dpWyLBQodYSaSvD3BwhBiNUxgGWtHr7UgFxv1fE4xHY

Start DynDOLOD in expert mode and select the desired worldspaces and click the Execute LODGen button to generate new object LOD meshes. See https://dyndolod.info/Help/Expert-Mode#Execute-LODGen

Replace old object LOD meshes with the new ones. Hopefully that fixes it.

[LF111]

That worked! I don't know what you tweaked, but the water LOD problem is gone, although the watermill problem remains. Here are some pictures showing what the console is telling me; turning DynDOLOD on swaps the model being used for the watermill and causes it to flicker between wet and dry based on viewing distance. The problem disappears when turning DynDOLOD off. The LOD model appears to always be loaded in.

Is this another situation where I have to go through and start disabling specific mesh files until I get the problem to disappear, or is there enough information for you to have an idea of what is wrong?

Edited September 14 by LF111

[sheson]

38 minutes ago, LF111 said:

That worked! I don't know what you tweaked, but the water LOD problem is gone, although the watermill problem remains. Here are some pictures showing what the console is telling me; turning DynDOLOD on swaps the model being used for the watermill and causes it to flicker between wet and dry based on viewing distance. The problem disappears when turning DynDOLOD off. The LOD model appears to always be loaded in.

Is this another situation where I have to go through and start disabling specific mesh files until I get the problem to disappear, or is there enough information for you to have an idea of what is wrong?

Test if making the Skyrim.INI/SkyrimCustm.INI changes to the decal and evmap fade settings as explained in https://dyndolod.info/Help/Glow-LOD make a difference.

If not check/report if any mod is replacing the lumbermill01waterwheel01.nif

[LF111]

9 hours ago, sheson said:

Test if making the Skyrim.INI/SkyrimCustm.INI changes to the decal and evmap fade settings as explained in https://dyndolod.info/Help/Glow-LOD make a difference.

If not check/report if any mod is replacing the lumbermill01waterwheel01.nif

Tweaking [LightingShader] in the .ini did not work, and as far as I can tell, SMIM is the only mod touching that .nif

 

Major edit: the water wheel bug persists regardless of whether or not bReflectSky is enabled; only disabling the DynDOLOD output fixes it. I misstated earlier that disabling ReflectSky fixed the issue. 

I checked whether testSky_e.dds was at fault, but Dynamic Cubemaps is the only mod I have that touches that and disabling it did not fix the problem. 

Also, just out of curiosity, what changed between the LODGenx64Win executables? I know I might not be versed well in all of this, but I'm curious what you found in the file I submitted. 

Edited September 15 by LF111
More info

[sheson]

10 hours ago, LF111 said:

Tweaking [LightingShader] in the .ini did not work, and as far as I can tell, SMIM is the only mod touching that .nif

 

Major edit: the water wheel bug persists regardless of whether or not bReflectSky is enabled; only disabling the DynDOLOD output fixes it. I misstated earlier that disabling ReflectSky fixed the issue. 

I checked whether testSky_e.dds was at fault, but Dynamic Cubemaps is the only mod I have that touches that and disabling it did not fix the problem. 

Also, just out of curiosity, what changed between the LODGenx64Win executables? I know I might not be versed well in all of this, but I'm curious what you found in the file I submitted. 

Do you know what mods might affect that wetness effect? If have a hard time too "see" what the screenshots are supposed to show, especially how it is supposed to look different from vanilla.

What mod changes the used textures?
textures\architecture\farmhouse\WoodWalkway01.dds
textures\architecture\farmhouse\WoodWalkway01_n.dds

Is there any difference setting iMaxDesired to 0 in console? e.g. setini "iMaxDesired:Particles" 0
Is there any difference unchecking Enable Shaders in the Community Shaders in-game UI?

The change in xLODGen is to change the base color alpha from 1.0 to 0.99 for a non-LOD passthru shape BSEffectShaderProperty.

[LF111]

I've uploaded some more thorough pictures here showing what the watermills look like at different distances with DynDOLOD on/off and CS shaders on/off. 

The only mod I have that affects the wetness effect is the Wetness Effects mod for CS. Interestingly enough, that's not what's causing the glossy effect, but it's rather the "lighting" shader in CS. As shown in the pictures, however, even with all CS shaders off, the DynDOLOD output being enabled causes the water wheel texture to change based on player distance. Up close, it's a lighter color.

It appears that the darker/non-wet wheel is being activated by DynDOLOD and doesn't shift to the lighter/wet/correct wheel until I'm very close to it, whereas when the LOD output is disabled, the lighter/wet/correct wheel always appears. 

Skyland AIO is changing the textures for WoodWalkway01.dds.

Neither adjusting the particle setting nor disabling CS shaders fixed the issue. 

56 minutes ago, sheson said:

The change in xLODGen is to change the base color alpha from 1.0 to 0.99 for a non-LOD passthru shape BSEffectShaderProperty.

I assume I'll have to forward the new executable to future versions of DynDOLOD as well, presuming RWT doesn't get an update that miraculously fixes the issue? 

I am really curious as to what's really at the root of this with RWT, because they haven't been able to find anything yet. Since I'm assuming the new LODGen executable is specifically to work around whatever weird issue I'm having, it means that there isn't an actual problem with DynDOLOD. 

Edited September 15 by LF111

[sheson]

9 hours ago, LF111 said:

I've uploaded some more thorough pictures here showing what the watermills look like at different distances with DynDOLOD on/off and CS shaders on/off. 

The only mod I have that affects the wetness effect is the Wetness Effects mod for CS. Interestingly enough, that's not what's causing the glossy effect, but it's rather the "lighting" shader in CS. As shown in the pictures, however, even with all CS shaders off, the DynDOLOD output being enabled causes the water wheel texture to change based on player distance. Up close, it's a lighter color.

It appears that the darker/non-wet wheel is being activated by DynDOLOD and doesn't shift to the lighter/wet/correct wheel until I'm very close to it, whereas when the LOD output is disabled, the lighter/wet/correct wheel always appears. 

Skyland AIO is changing the textures for WoodWalkway01.dds.

Neither adjusting the particle setting nor disabling CS shaders fixed the issue. 

I assume I'll have to forward the new executable to future versions of DynDOLOD as well, presuming RWT doesn't get an update that miraculously fixes the issue? 

I am really curious as to what's really at the root of this with RWT, because they haven't been able to find anything yet. Since I'm assuming the new LODGen executable is specifically to work around whatever weird issue I'm having, it means that there isn't an actual problem with DynDOLOD. 

DynDOLOD enables or disables references. That means, what DynDOLOD does is make the wheel show or not show.
It always the same full NIF and full textures regardless of distance. There is no darker/wet/correct or incorrect wheel being switched.
This can be verified with more informative console always showing the same formd ID and NIF.

Any lighting changes based on the distance or viewing angles are typically from shaders and their (fade) settings. Sometimes also mipmaps.  None of which are directly affected or changed by DynDOLOD. 
What we know from the past is that more models using certain effects active at the same can affect the fade distances of those effects.

Doublecheck in the game with console getini the already mentioned [LightingShader] settings. https://stepmodifications.org/wiki/Guide:Skyrim_INI/LightingShader
Also test the other 2, fRefraction and fSpecular. See if setting those both start/end to 1.0 in the Skyrim.INI or SkyrimCustom.INI makes a difference. Wetness effects might affected by the Specular settings. If setting 1.0 to everything does not make a difference, try 5.0 or 10.0.

Obviously the updated LODGen version will be included in the next release version, as practiced since a decade.
RWT has obviously no direct affect on object LOD meshes since it does not include any LOD models. https://dyndolod.info/Mods/Waterfalls

[LF111]

Played around adjusting all of the LightingShader settings, nothing worked. 

10 hours ago, sheson said:

RWT has obviously no direct affect on object LOD meshes since it does not include any LOD mode

I was just curious as to what could've changed such that I could run Alpha 180 with the original LODGen executable on RWT 5.6 and get no issues whatsoever but running it on 5.7.1 - with no change in load order - gives me an issue. 

Edited September 15 by LF111

[sheson]

1 hour ago, LF111 said:

Played around adjusting all of the LightingShader settings, nothing worked. 

Verify via console getini  that the settings (just do 10.0 then) make it into the game.

If no change, without any DynDOLOD output active, install the the test.esp. Go to Anga's mill. There should be 2 wheels, a second one above the other.
Compare how they look at different distances.

test.esp

[LF111]

I was testing the ini settings in-game with getini and setini, so they were making it in.

The new water wheel created by the test esp shows up as wet much further out, see here. It still fades into the "dry" look at further distances, but it is significantly less noticeable. If you were in-game and actually running through Anga's Mill, you probably wouldn't notice the fade at all.