LF111

Sweet, thanks. I've just made a note to remind myself to make sure that I generate after No Grass is unchecked via DynDOLOD in the event I have to reinstall again at some point in the future or if something goes wrong, as I still want to only load from the generated cache.

"No Grass" was unchecked for DynDOLOD.esp, but was checked for Occlusion.esp. I edited Occlusion to uncheck the box, saved the changes in xEdit, and redeployed all files (getting the confirmation notification that DynDOLOD_Output.zip was modified), yet the grass is still missing in-game, so unchecking it did not seem to do anything. This was done with Resources Alpha 55 and DynDOLOD Alpha 190. Edit: Never mind, unchecking the box did in xEdit did fix the issue, I just had to regen or disable NGIO (this has happened in the past, where if you generate NGIO on a freshly installed/reinstalled game before generating DynDOLOD, exterior grass won't appear; I had reinstalled when the weird form ID error was happening). NGIO was not the cause of the original issue (as I'd already tested that), but rather it appears to be something not forcing Occlusion to uncheck the box.

Same thing happening on my end with that piece of CC content, Alpha 189 is the first time it's ever been an issue. Copying from a separate post in which I mentioned the issue: As a side note (I didn't want to make this its own thread because I resolved the issue, but nevertheless think it's worth bringing up): When generating a new output on Alpha 189 and the newest Resources mod (wanted to see the new rock wall LOD), I got a notification about an unresolved form ID in cctwbsse001-puzzledungeon.esm. I went through the steps to find the errors in xEdit (there were two such errors in that plugin) and deleted the relevant properties, as both errors were for VMAD script properties. I was able to generate with no problem after doing that, but I felt I'd bring it up here since I've never gotten that warning before on past DynDOLOD versions and because that plugin is one of the AE creations/DLCs. As a test, I reinstalled the base game + AE creations and the same two form ID errors returned, which means they've probably been there all along. Just found it strange that I'm only now getting warnings about it, and I just want to make sure that it's safe to delete those properties for CC content. (Note: I am using the Unofficial CC Patch, too, and have been for a while).

I'll take you up on that explanation offer. As a side note (I didn't want to make this its own thread because I resolved the issue, but nevertheless think it's worth bringing up): When generating a new output on Alpha 189 and the newest Resources mod (wanted to see the new rock wall LOD), I got a notification about an unresolved form ID in cctwbsse001-puzzledungeon.esm. I went through the steps to find the errors in xEdit (there were two such errors in that plugin) and deleted the relevant properties, as both errors were for VMAD script properties. I was able to generate with no problem after doing that, but I felt I'd bring it up here since I've never gotten that warning before on past DynDOLOD versions and because that plugin is one of the AE creations/DLCs. As a test, I reinstalled the base game + AE creations and the same two form ID errors returned, which means they've probably been there all along. Just found it strange that I'm only now getting warnings about it, and I just want to make sure that it's safe to delete those properties for CC content. (Note: I am using the Unofficial CC Patch, too, and have been for a while). Edit: I saw some other people in the main Alpha 189 thread having the same issue with that CC content out of nowhere, so I've copied that portion of my reply there as well.

Checked out the new version, everything matches now. Many thanks.

Sorry if this isn't the right subforum for Resources reports, but: As stated in the title, exterior grass is not showing up when inside Whiterun, despite ticking the check in the FOMOD. I've tried fresh generations (though that might not be necessary), a new NGIO cache generation, reinstalling Resources, and disabling NGIO and my grass mods to test on vanilla grass; all give the same result. Pre-Alpha 54 versions worked for me, and while I've done a few generations on the current version since it released, this is the first time I've been in Whiterun and noticed it. Logs (although I don't know how relevant they are for this).

Hello once more. Now that all the previous funkiness is out of the way, I can send over the rock wall LOD stuff. The combination of mods I am using is High Poly Project + Rock-Wall Texture Patches for High Poly Project at Skyrim Special Edition Nexus - Mods and Community, using the Majestic Mountains - Main file. Interestingly enough, though, the problem has changed since I first mentioned it. Before, the LOD models would appear like sort-of white amorphous blobs, which led to me turning off the retexture during generation so that the rock wall LODs looked like Skyland's (my base texture overhaul). The thinking was that the transition would be far less jarring since the colors would mostly line up. Well, after regenerating today, the LODs match Skyland's even with the retexture mod turned on. That is, no more white blobs. Pics. This current result doesn't bother me at all, but I figured it's still worth posting here, just in case there should be a proper LOD model/texture for what I have enabled (it's worth noting that there doesn't seem to be a LOD model for the HPP rock wall at all, regardless of the retexture, hence why it's reverting to Skyland's model even though I have HPP overwriting Skyland). This may be a non-issue now. Logs.

Test version has completely fixed the issue on my end. Do you still want me to start a new thread for the rock wall LOD texture issue, or should I just continue it here?

The file in the data folder has the same modified time as the TexGen output file and is the same size. Folder has been updated with the two files. Testing the test version now.

I don't think Vortex can do what MO2 does there, but I am able to just check the files. I downloaded a texture viewer (WTV) to be able to see the .dds files, and Data\textures\dyndolod\lod\dyndolod_tamriel.dds is blank. It's telling me that the DX10 format is unknown. I tried in GIMP as well and got a similar warning about an unsupported DXGI format. I can check the files in the actual folder, I just need to know what is meant by timestamp. If it's referring to date modified, they don't match (although it might be close enough, based on what you mean by "about the same"). The .bto has a date modified of 2/17/25 at 1:15 AM, while the texture has a date modified of 2/17/25 at 1:09 AM (though the "date created" is listed as 2/17/25 at 1:17 AM... after it was modified?) Sorry if this is not at all what you mean by timestamp. In case it helps, I've uploaded the texture .dds file to the folder.

I do not use MO2, unfortunately, so I cannot check it that way. How else can I go about troubleshooting?

I've updated the photos with additional pics that I believe cover what the site asks. Pics. Based on how broad the problem here is, I didn't quite know how many pictures to actually take. Note that it's hard to get an up-close view of the purple squares that bisect that certain tree model, as they disappear when getting too close to them with tfc. Requested files and proper logs (let me know if there's an issue accessing the .bto file this way). I can confirm there is no old output overwriting the new one. There's also something funky going on with generation times. TexGen is taking the same amount of time as usual (2-3 minutes), but DynDOLOD is varying a lot. The generation time for my current load order (backed up by the three generations I did for the seam testing) is ~18 minutes. The two Alpha 187 generations I did earlier today both were around 22 minutes, and the one that I just did (that these logs are coming from) was only 9 minutes total. I have never had a DynDOLOD generation go that fast.

This is continuing on from my previous thread about the seams/Occlusion record forwarding issue. I was going to regenerate LODs so I could start a new thread on the rock wall meshes that you wanted me to report on with matching logs, and I noticed that Alpha 187 was uploaded to Nexus, so I grabbed that first. Generating on Alpha 187 is causing some... issues. There are purple LOD textures and strange terrain blocks everywhere. There is no difference in my load order between what I generated two days ago for the water seam tests (on Alpha 185); these issues appear to be tied to 187 (and I also noticed the version of TexGen that ships with Alpha 187 is still on Alpha 186, and it's giving me a "more recent version is available" line at the bottom of the window). Logs. I noticed the debug log is truncated, which is probably due to me booting up and then immediately cancelling DynDOLOD to verify that it was version 187 after I noticed that TexGen was still on 186. Let me know if you need me to do another generation in order to produce a fresh debug log. I've attempted a fresh TexGen and DynDOLOD generation twice on 187, and got the same issues both times. The second attempt was done as cleanly as possible, disabling DynDOLOD and creating a clean interior cell save. After I get this figured out, I'll start a new thread on the rock wall.

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.

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

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.

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.

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.

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.

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?

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)

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.

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.

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.

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