Waterfall LOD Not Obscured by Fog and Other Weather

[LF111]

Hello, I've noticed that waterfall LODs appear visible at all times through weather/distance that should obscure them, seen here. Using the latest version of DynDOLOD and Realistic Water 2 (5.7.2). I've attached the main log, and the link to download the debug log is here (too large to attach; let me know if there's an issue accessing the log). 

Also, on an unrelated note, I just wanted to make sure that adding RenderTexturesSingleThread=1  to the end of the TexGen_SSE ini won't have any negative impacts on anything? Sorry if this is a very stupid question, I don't really know how a lot of that stuff works. I was having the OpenGL issue out of nowhere (I've run TexGen without issue 10+ times in the past 3 days, but only today encountered the problem - and it wouldn't go away) and adding that line in fixed it for me. 

 

 

DynDOLOD log.txt

[sheson]

1 hour ago, LF111 said:

Uploading the btos that showed up in the "you are here" window in the second pic here (let me know if this isn't close enough for the btos to be accurate/contain the waterfall).

https://drive.google.com/drive/folders/1UzoJbKxNdaosOq6pYSPDBO2EMYZWJNoW?usp=sharing (should be able to download from here)

Download this test version https://mega.nz/file/0Jwj1SbQ#hRS13oCP3Wz1_owUhBLGmy-bOa2tiC-jbHLOugVmy8E of LODGenx64Win.exe and replace the one in the Edit Scripts folder.

Then generate LOD or Execute LODGen for Tamriel in Expert Mode to just update the object LOD meshes. See https://dyndolod.info/Help/Expert-Mode

Report if it makes any difference.

[sheson]

2 hours ago, LF111 said:

Hello, I've noticed that waterfall LODs appear visible at all times through weather/distance that should obscure them, seen here. Using the latest version of DynDOLOD and Realistic Water 2 (5.7.2). I've attached the main log, and the link to download the debug log is here (too large to attach; let me know if there's an issue accessing the log). 

Also, on an unrelated note, I just wanted to make sure that adding RenderTexturesSingleThread=1  to the end of the TexGen_SSE ini won't have any negative impacts on anything? Sorry if this is a very stupid question, I don't really know how a lot of that stuff works. I was having the OpenGL issue out of nowhere (I've run TexGen without issue 10+ times in the past 3 days, but only today encountered the problem - and it wouldn't go away) and adding that line in fixed it for me. 

DynDOLOD log.txt 1011.75 kB · 0 downloads

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make a useful screenshot of the full model with more informative console.
Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt

See https://dyndolod.info/Mods/Waterfalls. Uploaded the requested screenshot and log will help to determine which NIFs are used for LOD.
Report if the waterfalls go away with tll in console. https://dyndolod.info/Official-DynDOLOD-Support-Forum#Rudimenratry-Troubleshooting

Typically this type of issue is a problem with shaders, so ENB or CS related.

See https://stepmodifications.org/forum/topic/20153-error-opengl-framebuffer-objects-unsupported, especially the post about using the TexGen test version https://stepmodifications.org/forum/topic/20153-error-opengl-framebuffer-objects-unsupported/page/2/#comment-282545
The RenderTexturesSingleThread=1 makes the creation of rendered object LOD textures single threaded instead of multithreaded, it slows down the generation.

[LF111]

Link to requested screenshots here. Apologies if this is what was being asked, but more informative console didn't return any information when using tfc to get close to the LOD model, but I included the console results for the actual model. Object log posted here. The waterfalls do indeed go away when using tll, as shown in the final two imgur photos. I disabled all CS shaders and the issue did not go away (though that might not be what you meant). 

Regarding the TexGen bit, I actually already read through that forum earlier, and that's where I got the RenderTexturesSingleThread thing from lol. I was just making sure it wouldn't somehow have negative in-game consequences, so it's all good. 

Edited December 14 by LF111

[sheson]

13 hours ago, LF111 said:

Link to requested screenshots here. Apologies if this is what was being asked, but more informative console didn't return any information when using tfc to get close to the LOD model, but I included the console results for the actual model. Object log posted here. The waterfalls do indeed go away when using tll, as shown in the final two imgur photos. I disabled all CS shaders and the issue did not go away (though that might not be what you meant). 

Regarding the TexGen bit, I actually already read through that forum earlier, and that's where I got the RenderTexturesSingleThread thing from lol. I was just making sure it wouldn't somehow have negative in-game consequences, so it's all good. 

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make a useful screenshot of the  full model with more informative console. The linked section also explains how LOD can not be clicked.

Read the post https://stepmodifications.org/forum/topic/20153-error-opengl-framebuffer-objects-unsupported/page/2/#comment-282545
If you still have a problem with the linked test version that requires setting RenderTexturesSingleThread=1, then upload the requested logs to that thread.

 

[LF111]

Apologies, but what wasn't full about the screenshots of the model I sent? I have additional pics here, but I think I've covered everything requested on the forum link. 

[sheson]

8 hours ago, LF111 said:

Apologies, but what wasn't full about the screenshots of the model I sent? I have additional pics here, but I think I've covered everything requested on the forum link. 

Indeed, there are screenshots of the full model with more informative console. My apologies.

Doublecheck :\Program Files (x86)\Steam\steamapps\common\Skyrim Special Edition\Data\textures\effects\fxwhitewater02_fallsnoalpha.dds  is indeed the one from the latest TexGen output, for example by comparing the file size and date.

Just vanilla with CS with RWT and the same LOD models as reported by DynDOLOD_SSE_Object_Report.txt I can not reproduce this switching to some vanilla foggy weather. Is a particular foggy weather required?

Do the full models not show through the fog the same way?

Have you tried also starting without CS active at all?
Any other DLLs that could be making in-game changes to NIFs?
Test with default INIs.
If all fails, try to remove as many possible related mods (anything with shader related changes, weather and fog mods) until hopefully determine what else is needed to reproduce this.

[LF111]

The two fxwhitewater02_fallsnoalpha.dds files are the same: same date and file size. 

Foggy weather is not required, any obscuring weather will do the trick (snowstorms, for example). I noticed when briefly testing Worldspace Transition Tweaks that you could see the same Skyrim waterfall issue all the way from Solstheim; it looked like distant mist produced by weather mods (in my case, Azurite Weathers 2) also triggered the issue, as did time of day, as the issue was particularly noticeable at night (even in clear weather; it appears to sort of glow a greenish color). When I was testing Azurite 3, I noticed that you could see the same problems on a bunch of waterfalls in the Reach area from High Hrothgar, even on a clear day (not noticeable in Azurite 2 due to a differing mist color that masks the issue). The issue persists when disabling Azurite, pic here (notice how it looks like the waterfall is glowing; did you see anything like this in your test with vanilla weather?) 

Full models do not have the issue. Here are some pics using the same fw command. 

Booting without CS active did not have an effect. 

I went through my DLLs and disabled anything that appeared as if it could be relevant and got no change. 

The only INIs I have modified are two custom ones for fEnvmapLODFadeEnd and FadeStart (from my previous water-related issue) and removing them does not solve the issue. I'm sure they are the only personally modified INIs as I recently fresh-installed the game on a new PC a little over a week ago and only altered the custom INI for the aforementioned LOD adjustments (the issue existed on the old machine as well).The only other INIs modified are for the snow shader and lens flare, which are done by CS 1.0+, but this issue predates that update and occurred back when I had both of those options checked. 

I'm testing disabling certain things now, but since a number of them will require regenerating LOD, it might take a bit. I'll get back to you on anything I find. I've also asked another player who has reported the same issue (only fixed by rolling back to a previous DynDOLOD version; I can confirm that I didn't have this problem in the past either, at least as late as Alpha 173, can't remember for sure about 180) to send me their modlist so I can compare and hopefully be able to more quickly find possible culprits. 

Edited December 16 by LF111

[sheson]

6 hours ago, LF111 said:

The two fxwhitewater02_fallsnoalpha.dds files are the same: same date and file size. 

Foggy weather is not required, any obscuring weather will do the trick (snowstorms, for example). I noticed when briefly testing Worldspace Transition Tweaks that you could see the same Skyrim waterfall issue all the way from Solstheim; it looked like distant mist produced by weather mods (in my case, Azurite Weathers 2) also triggered the issue, as did time of day, as the issue was particularly noticeable at night (even in clear weather; it appears to sort of glow a greenish color). When I was testing Azurite 3, I noticed that you could see the same problems on a bunch of waterfalls in the Reach area from High Hrothgar, even on a clear day (not noticeable in Azurite 2 due to a differing mist color that masks the issue). The issue persists when disabling Azurite, pic here (notice how it looks like the waterfall is glowing; did you see anything like this in your test with vanilla weather?) 

Full models do not have the issue. Here are some pics using the same fw command. 

Booting without CS active did not have an effect. 

I went through my DLLs and disabled anything that appeared as if it could be relevant and got no change. 

The only INIs I have modified are two custom ones for fEnvmapLODFadeEnd and FadeStart (from my previous water-related issue) and removing them does not solve the issue. I'm sure they are the only personally modified INIs as I recently fresh-installed the game on a new PC a little over a week ago and only altered the custom INI for the aforementioned LOD adjustments (the issue existed on the old machine as well).The only other INIs modified are for the snow shader and lens flare, which are done by CS 1.0+, but this issue predates that update and occurred back when I had both of those options checked. 

I'm testing disabling certain things now, but since a number of them will require regenerating LOD, it might take a bit. I'll get back to you on anything I find. I've also asked another player who has reported the same issue (only fixed by rolling back to a previous DynDOLOD version; I can confirm that I didn't have this problem in the past either, at least as late as Alpha 173, can't remember for sure about 180) to send me their modlist so I can compare and hopefully be able to more quickly find possible culprits. 

Upload a LOD level 4 and 8 *.BTO that has such waterfalls in them.

[LF111]

Uploading the btos that showed up in the "you are here" window in the second pic here (let me know if this isn't close enough for the btos to be accurate/contain the waterfall).

https://drive.google.com/drive/folders/1UzoJbKxNdaosOq6pYSPDBO2EMYZWJNoW?usp=sharing (should be able to download from here)

 

[LF111]

Unfortunately it didn't work, but I did notice something interesting while tfc-ing around this time. Certain waterfalls don't have the issue. Starting tfc from the WIndhelm stables, I noticed a set near Mixwater Mill that was behaving totally fine; no LOD issue, and the waterfall was remaining in-motion when I got close to it (unlike the ones displaying the issue). Pics here. Noticed that the 8 BTO is the same as the one I've already sent, but the 4 one is different. Here's the new 4 BTO: https://drive.google.com/drive/folders/10mMJdwOQD18wnQk7lKSsniF3PvS7ILYH?usp=sharing

Wait; was the new exe you sent me LODGenx64.exe or LODGenx64Win.exe? I replaced the LODGenx64.exe with the new one (since that's what the file is named), but I just now saw that you wrote it's the LODGenx64Win.exe that you sent me (even though it's not named that); did I replace the wrong thing?

Edited Monday at 09:31 PM by LF111

[LF111]

Edit: I should learn how to read lol. Renaming the file to include the Win and replacing it fixed the issue. The new exe works, problem is solved. I did notice there's a gap near the top of the tall waterfall (pics), but I think that's just how it is and it was always like that before (you could see the same thing here).

Regardless, the issue appears to be solved. Thank you.

Edited Monday at 10:06 PM by LF111

[sheson]

10 hours ago, LF111 said:

Unfortunately it didn't work, but I did notice something interesting while tfc-ing around this time. Certain waterfalls don't have the issue. Starting tfc from the WIndhelm stables, I noticed a set near Mixwater Mill that was behaving totally fine; no LOD issue, and the waterfall was remaining in-motion when I got close to it (unlike the ones displaying the issue). Pics here. Noticed that the 8 BTO is the same as the one I've already sent, but the 4 one is different. Here's the new 4 BTO: https://drive.google.com/drive/folders/10mMJdwOQD18wnQk7lKSsniF3PvS7ILYH?usp=sharing

Wait; was the new exe you sent me LODGenx64.exe or LODGenx64Win.exe? I replaced the LODGenx64.exe with the new one (since that's what the file is named), but I just now saw that you wrote it's the LODGenx64Win.exe that you sent me (even though it's not named that); did I replace the wrong thing?

https://dyndolod.info/Help/LODGen
LODGen.exe/LODGenx64.exe require .NET Framework 4.8 to be installed, which is typically included in Windows 10/11. LODGenWin.exe/LODGenx64Win.exe require .NET Desktop Runtime 6 to be installed. The .NET Desktop Runtime version is preferred over the .NET Framework version. A check at startup determines if it can be used or else automatically falls back to the .Net Framework 4.8 version. To know which version is being used, check the log for the line:
External: C:\Modding\DynDOLOD\Edit Scripts\[LODGen|LODGenx64|LODGenWin|LODGenx64Win].exe

The log you uploaded shows it was using the LODGenx64Win.exe instead of LODGenx64.exe to generate the LOD meshes.
External: C:\Skyrim DynDOLOD\DynDOLOD\Edit Scripts\LODGenx64Win.exe, Version: 3.0.31.0, Date: 2024-10-09 19:00:00

Renaming should not be needed.

[LF111]

I only renamed so it wouldn't overwrite the one in the folder (which is what happened by default the first time, leading to no change, as the other Win version was still there). Thanks again for helping to work this out.

Edited Tuesday at 11:50 PM by LF111