Blackread

Hello sheson, I am once again looking for support with LOD issues. This time I'm having problems with some glow lods not unloading properly. Here are some examples: Saving and reloading from the main menu does not clear them up. Going to an interior cell, or in the case of the Solitude dock area, to the city worldspace and back does fix them. I haven't seen them when arriving to a cell directly with fast travel or through other means. Here are the logs: https://mega.nz/file/9P9lEZbD#HSgYOmOMDybs-vF0drYsXSFEY1bH1OmwhSgBDTi15NI There were some errors originating from DynDOLOD in some of the Papyrus logs so I attached them too, but I'm not sure if they are related, as the glow lods were always there, but the Papyrus logs were sometimes clean.

Thinking back on the occlusion issue, it's possible the plugins were in the wrong order, with DynDOLOD.esp overwriting Occlusion.esp. I didn't check it, so can't know for sure, but sounds like a plausible explanation to me. Setting the original x and y coordinates works well, thank you. No rogue buildings in Winterhold anymore either.

The Occlusion.esp is from the same generation as the rest of the LOD. But I noticed that I forgot to set OcclusionMaxThreadsObjectLOD to 1 when I last updated DynDOLOD, so I corrected that and regenerated occlusion, which fixed the issue. Yes, the building would be (and is) far underground. But as I explained in my post about moved large references which used Cities of the North - Falkreath as the test setup, it doesn't matter where the large ref is moved or how the record is altered (base object swapped or anything), if the ref is moved outside the original cell, it will warp back using the last overwrite that did not move the ref outside its original cell, which in this case is Skyrim.esm. Here's my plugin for TGC Winterhold v4 if you want to test it yourself. The original has a z coordinate of around -29600 for this ref, so it probably will register as a moved large reference even if ESM flagged. Obviously I can fix this one manually by moving the ref to its original cell though.

I noticed a couple LOD related issues in my game again. The first one is that LOD for the Winterhold College tower is flickering in and out of existence. You should see it next to the mountain on the right side. To my eyes it looks like it could be occlusion not fully working as intended. Looking at the footage I also noticed there's something strange happening with the horizon line on the left. There's also a hole in the sea LOD that appears and disappears as you move around, this is just outside the main gate of Winterhold: Not sure if these are related though. The second is that there's a building in the middle of Winterhold that's not supposed the be there. The reference 62eb6 is overwritten by The Great City of Winterhold v4.esp which makes it into a UDR, and then DynDOLOD.esm which swaps it with the fix activator. The base 9307d is last (and only) overwritten by Better Dynamic Snow SE.esp changing the directional material, as reported by console. Just as with moved large references I reported some months ago (which, as it happens, this also is), you need to approach the city from afar by foot to see the building. COCing or fast traveling straight inside it's not there. Looking at the logs it looks like the reference for the inn is not reported as being a moved large reference, so that could be the reason for this happening.

Okay I think I found it! I thought I checked I had the latest version of Majestic Mountains but turns out I didn't. From the changelog of 4.01: Edit: Just to be clear, some objects in the moss esp had their object bounds set to all 0, including one of the ones that were present in the cell we were checking.

Yes, all the refs are tagged with -LargeRef. But, it looks like MajesticMountains_Moss.esp is the culprit. I disabled it in my load order, regenerated the LODs and all the bugs were gone. I don't know if it makes any sense from a technical standpoint, but it is logical looking at it from a troubleshooting standpoint. All the affected cells had at least one rock object with the new dirt shader (the moss plugin was changed from moss to dirt in the latest MM update). It is also one of the mods I updated before this latest LOD refresh I did. I'll do a few more tests to see if I can get more info out of this.

None of the references are overwritten. 0003ACCD and 0003ABE3 are overwritten by MajesticMountains_Moss.esp 0003ACCD, 0003925C, 00042A88 and 0003ABE3 are overwritten by DynDOLOD.esp. No overwrites on 00077773. I reinstalled USSEP to make sure the plugin is unchanged, and like you said, MM Landscape only edits landscape records. I checked that neither plugin adds new large references to Tamriel. I'm using the test version you gave me a few posts before.

Everything is up to date. Update.esm has been cleaned with xEdit QAC. USSEP, not sure, I may have done some small edits. LaWF should be as is except for generating large refs. LFfGM should be unchanged, as is MM Landscape. In Lux Orbis I have done some minor fixing, at least on the floating embers in Windhelm. I'll make sure all those plugins are in their original state and regenerate to be sure.

Yes, with uLargeRefLODGridSize=5 there are only the LOD models visible (and only one model, no z-fighting). Here are the overwrites: 000095DE: Update.esm, Unofficial Skyrim Special Edition Patch.esp, Landscape and Water Fixes.esp, Landscape Fixes For Grass Mods.esp 00009A8A: Update.esm, Unofficial Skyrim Special Edition Patch.esp, MajesticMountains_Landscape.esm, DynDOLOD.esm, Lux Orbis.esp 00009A6A: Unofficial Skyrim Special Edition Patch.esp, MajesticMountains_Landscape.esm

I did several runs with this version without getting stuck, so likely the issue was fixed, thank you. I found some large ref bugs in the area around the western watchtower. Here are a few examples: https://i.imgur.com/aEHKPMU.png ref 1a482 https://i.imgur.com/PCxDWWF.png ref 6ea15 https://i.imgur.com/itAuhLY.png ref 1a370 https://i.imgur.com/3DyFU69.png ref 1a494 https://i.imgur.com/lG6zdhJ.png ref 3abbf For some reason I couldn't find a debug log for the latest run, so here are the logs for the run before. The only difference is that I had realtimelogging active for the run these logs are from, the bugs were present in both. Papyrus logs didn't contain anything dyndolod related.

Should RealTimeLog=1 go under [frmMain] or [Init]? The test version gives an Item not found error on startup Logs

I've been having an issue with the latest Alpha 102 version where DynDOLOD will often get stuck processing references for a worldspace. It doesn't seem to be related to any particular mod, as the worldspace this happens at looks to be completely random. No matter how long I leave the program it will never proceed from that point. The Elapsed time counters at the top will also freeze, but otherwise the window remains responsive, and I can close the program normally, though if I do that there will still be a process in the background left running that I will have to kill with the taskmanager. Here are the logs for one run where this happened: https://mega.nz/file/cf1hza7Q#l31nq1otgSvNiH5IqbomBw2OszVMFU6W8bhOLFi2NOI

Of course, that is a perfectly valid workaround, why didn't I think of it before Thank you, the test build fixed the Item not found bug.

Debug log reported that only one thread was used. I was inspecting the latest run I did with Process Explorer to get a better grasp of what is going on, and as soon as DynDOLOD started updating the height map the number of Private Bytes spiked up sharply, staying above 20 GB for the majority of the time and peaking at 28 GB. Process Explorer also reported over a dozen active threads for DynDOLOD during that and the number of active threads correlated pretty well with the memory usage, so I was wondering if it's possible, that Windows or something else circumvents the thread limit somehow? Although I'm not sure how reliable Process Explorer actually is for these things. Do I need to have an Occlusion.esp already in my LO when doing the occlusion? I tried first generating LODs with Occlusion unticked, and then running again with only Occlusion data and Plugin ticked, but when I hit ok to start the process DynDOLOD asked me whether I want to update my plugins, and a few seconds after hitting Yes I got an Item not found error.

Yes, it fixed it indeed, thank you. Looks like the one run that was successful without Out of memory errors was a random occurrence, haven't been able to repeat it since. It seems that HD Grass was the last straw. I was able to generate occlusion without 3D trees, without a grass LOD, or with 3D trees and a grass LOD using regular grass, but using 3D trees and an HD grass LOD tips it over the edge. Maybe I just need to get more RAM. I tried generating Occlusion with xLODGen afterwards, but that failed too. I couldn't figure out how to do it with DynDOLOD. The mentioned BTO files open in Nifskope without problems, although some of them take several seconds to load. Not all though, some open near instantly. It's the ones with a lot of grass that take the longest. The sizes of the reported files range from 4.95 MB to 59.39 MB, with most of them falling in the 10-30 MB territory. There are larger bto files in there though, the largest being around 80 MB. Generating just Tamriel with 3D trees and HD grass with 20 density takes around 40 minutes.

Updating to Alpha 100 seems to have solved the memory issues, at least I didn't get any Out of memory errors during my latest run. 03010F54 is overwritten by Lux Orbis - Master plugin.esm only, it changes the emittance in addition to adding the location value. 03016DF1 is overwritten by Lux.esp, it adds an emittance value and a location value. The form IDs of the LOD reference are 380A258F (base, DynDOLOD.esm) and 6E67B45B (ref, DynDOLOD.esp), assuming this is what you meant https://i.imgur.com/E3EWJyH.png DynDOLOD_Tamriel_Objects.txt from the output Logs in case they are needed

Thank you for the LOD Level explanation, I understand it better now. I tried to solve the out of memory issue by setting the OcclusionMaxThreadsObjectLOD to 1, but it didn't help. This time there was an access violation. I forgot to copy the error window, but here are the logs along with the bugreport. I looked into other possible solutions too, but the grass LOD is already quite low density, and the 3D trees are from Happy Little Trees which should be adequately optimized I believe. When it comes to other full models in object LOD I'm not entirely sure, the only mod I definitely know to use full models is More Wooden Bridges. I feel like something has maybe changed in the way the height data is calculated from object LOD, because back in the beginning of August I successfully generated a grass LOD with 100 density (with the same grass mod and settings). It took at least 15 minutes for the height data for Tamriel to be calculated and maybe 1.5 hours for the whole generation (Tamriel only), but there were no errors. The HearthFires building should not be there, I was straight out of the alternate start room. I ran from Honningbrew Meadery along the east side of Whiterun to the whitewatch tower, where I first noticed the misplaced building. It is fully replicable on that LOD generation (I haven't successfully completed another one yet). I hadn't altered my speed mult, it was vanilla (or very close to it at least). Edit: Forgot to mention, nothing in Papyrus logs. Edit2: Did another DynDOLOD run without Occlusion just to see if the HearthFires building is still there, and it looks like it is. Logs Seems it is replicable at least on this mod list. Still nothing in Papyrus logs. I'll root out the memory issues when I have the time.

While I was running around the Whiterun area doing some testing I came across this: Looks like it's a part of the Pale Hearthfire house. It stayed visible in the large ref grid but disappeared when the cell loaded in. Here are the logs: https://mega.nz/file/xX0TBJAQ#-L1jMJHERaUd7bimCeaqP5xQ1y6TyXxoGf50SVlLUoA I noticed there were some Out of memory errors, maybe they are related. I also had some trouble with my LOD 4 distance. It seems that there is some lower limit under which it won't go no matter what I set in the ini. Using the sliders in the DynDOLOD MCM I estimated the distance the LOD 4 is displayed at to be somewhere around 40 000 units. Increasing the distance above that will extend the LOD 4, but dropping it below 40k has no effect. Is there some other setting I also need to adjust to drop it further, or is it somehow tied to near / far grid or the large ref grid size?

Yeah, MaxStdio is set to 8192. Unfortunately it looks like after packing the Missives mod to an archive and unpacking it I am no longer able to reproduce this issue. Maybe it was some random fluke or some obscure yet undiscovered bug. I'll update this if it returns and I'm able to perform more testing. Edit: Here's a quick video of the same LODs now: https://www.youtube.com/watch?v=4DGjMtBSnvs

Thank you for the tips. It is indeed a case of z-fighting between object LOD and object LOD. The youtube compression ruins the image so it's not so clear, but here's another video that should display it better: https://www.youtube.com/watch?v=piHXL1DE9CM I also found a solution: remove ini files from the data folder for an amount that adds up to at least 8 lines of text. Commenting out lines of settings with a semicolon (;) works too. It doesn't matter what settings they are or which mod they are from, or whether the settings are overridden by another ini file from a later loading plugin. As long as at least 8 lines are removed the z-fighting is gone. It also looks like ini files intended to be read by various SKSE plugins (KID, SWAP, DISTR, LID, FLM, etc.) are included in this count. Removing any of these files that have at least 8 lines of text removes the z-fighting. The file I remove can also be in a subfolder. It doesn't even have to be an ini file at all, it can be a json file or a txt file such as a changelog, or a readme. Script source files (.psc) also work. Reseting my base inis to default also fixes the z-fighting. I would imagine this is because it effectively removes at least 8 lines of text from them, as the BethINI Tweaks add several new settings to the files. I also tried packing one of my mods that had loose script files into a bsa, and this too removed the z-fighting. Putting all of the above together seems to suggest that there is some sort of engine limitation on the number of lines there can be in loose files with text content in the data folder. Or something along those lines.

With a few of my recent DynDOLOD generations I've had issues with flickering distant LOD. Here's a video with a couple clips that demonstrate the problem: https://www.youtube.com/watch?v=U9o7jh5UYUI I don't think this is a large reference issue, as the affected cells are way too far to be included in the uLargeRefLODGridSize range, which I have set to 11. Also it often affects trees, which can never be large references anyway. To my eyes it looks like two different LOD levels are fighting in the affected cells, rapidly switching between LOD4 and LOD8 or similar. The issue is quite sporadic. With each LOD generation the affected cells are different. Sometimes I don't find any affected cells at all. When I tried approaching the bugged cells some of the LOD in the cells failed to properly unload. All non-bugged cells always unload without a hitch. Here are some logs. Logs 1 should correspond to the first clip on the video, and Logs 2 to the second clip. What kind of troubleshooting steps would you recommend? Is there a chance this is related to the large ref workarounds? Should I try generating LODs without them active? I tried setting uLargeRefLODGridSize to 5 just in case, but it had no effect on this as expected. Edit: Checked Papyrus logs, no DynDOLOD related messages.

https://mega.nz/file/oat2xDAL#3NTc17b6JZDCJd4V1huBohZTubFeAeFiTvMrK4_NAIg Here's a plugin with just that one large ref changed. I did a test having only that plugin active in addition to the base game files, and at least on my setup that was enough to trigger the bugs. But I haven't tested with the latest alpha 99 yet. Update: Tested with Alpha 99, no change. Here are the logs for that run.

There is no Tamriel_Disciple_%38_2 in -38,2, only Tamriel_Worshipper_%38_2. Yes, I've done the standard fix for the moved reference in Update.esm: moved the original one back to its original position and disabled it, and created a new duplicate where the original was moved to by Update.esm. However, I've been meaning to remove all the plugins that fix moved large references and custom updates to stuff like lighting mods in favor of the new workarounds and see how things work out, just haven't found the time to do it yet. I'll let you know of the results when I do. Thanks for looking into the Rorikstead situation! Completely missed that there was another model on top of the large ref one.

Just finished doing the tests. After converting the records to proper UDRs and generating the LOD there were no bugs, disabling the spire reference showed no LOD underneath. However, after generating large refs and LOD the bugs returned. I checked all the added large references in that cell but couldn't find any obvious causes of this. Here's the plugin if you want to look into it further. I'm personally satisfied with using the workarounds though as they seem to be working well, so if you have other things demanding your time there's no need to spend it on this, at least not on my account.

I did a bit of further testing and found out, that disabling and enabling one of the affected objects in cell -38, 2 will unload the LOD for all of them. The same did not happen for the rock cliff near rorikstead. I had Papyrus logging enabled during this. I did not notice anything LOD related in the log, but then again I don't really know what I should be looking for. Here's the log: https://mega.nz/file/hK0ABS4R#Cbd0-QnDBGndefdG_p6iBfP0bhm_6bYvoIt8Lda4Urk