sheson

Interesting. I could not begin to speculate how the DirectX9 4GB VRAM limit could play into this. Other factors may be at work. Also I am wondering if it may be possible that just reinstalling everything (probably with slight differences) made a change as well. Since it seems you have a busy load order, I suggest make sure not to run into default heap max settings by double checking the max usage with Memory Blocks Log. Alternatively try Crash Fixes default heap replacement UseOSAllocators=1 with the our pre-loader. It can result in faster loading times as well, though the difference between mechanical disk and SSD is huge anyways.

When you do more tests, turn on debugging in Lanterns MCM and enable payrus logging. I would be interested to see if/what is writes to the log.

yes, the new DynDOLOD.esp in the output folder will have the everything from the first one in the load order plus the new data combined.

W You should "install" everything from the output including the DYnDOLOD.esp from the first run. So for the second run the DynDOLOD.esp is part of the load order when starting DynDOLOD.exe again. Then install all new files in the output folder overwriting everything including the DynDOLOD.esp and the JSON files from the first run. Repeat for as many worldspaces as required.

3.6 seems high for 32 bit. Are you using DynDOLODx64.exe? That was exactly my thinking as well at first in the linked thread. But then the user fixed his problems by reinstalling resources. So I am not ruling out either possibility. The fact that it requires several worldspaces to happen suggest some kind of memory corruption, though. Hard to find if it doesn't happen to me. I guess I need to install more mods and stuff for test.

Have you seen this discussion? https://forum.step-project.com/topic/12183-error-out-of-memory/ It seem related. Check billboards or other textures used for creating the LOD textures atlas. Maybe you can narrow it down by doing single worldspaces and then checking the textures listed in DynDOLOD_TES5_*_textures_used.txt and DynDOLOD_TES5_*_flat_textures_used.txt files in the ..\DynDOLOD\Edit Scripts\DynDOLOD\cache\ folder. Blackreach seems like a good test case since it small with only a few textures. Though it is possible the problem is triggered in an earlier creation and then only manifest itself later. Maybe there is a texture on a new format that can not be converted properly. If you happen to find it I would be interested in it obviously, so I can test myself.

Which atlas did it try to create when that happened?

FAQ: Exception in unit xxx line xxx: FormID [xxx] references a master which is not available in file [xx] xxx.esp A: Check the load order for errors in xEdit.exe before generating LOD. Fix all errors. See this video for help. Could be a plugin revolving around ETAC

Does it still do this when you set "always on"?

So, there is something going on with the scripts of Lanterns Of Skyrim executing repeatedly? If I remember right, the lanterns script should only run after changing settings and twice an in-game day based on the MCM settings. I am not sure what could prompt it to run continuously. See if changing "Checking every x seconds in its MCM changes the interval of the other objects switching. Maybe turn on debug mode and check the papyrus log for clues. uStaticNeverFade, bForceFullLOD and bRunHighLevelProcess are settings that do not exist in TESV.exe, so they will have no effect. I can not really say anything about the usefulness about the others.

Hmmm, but DynDOLOD doesn't change that reference. DynDOLOD scripts for dynamic LOD only run when the character crosses cell borders. However thy can only enable/disable objects for which a DynDOLOD created or updated a reference. For a test, disable the DynDOLOD patches script(s), maybe the lantern mod is continuously executing the DynDOLOD scripts. Other than that, DynDOLOD may be just the one thing that puts the load order over the top of some resource issue. I suggest to test with default or BethINIs since the INIs have some questionable or non existing settings. Then follow through with your idea that maybe VRAM or RAM limits play a major role. To test further into resource issues, generate only tree/static LOD, or vice versa temporarily disable tree/static LOD by hiding meshes/texture folder from the output.

The screenshot shows a base record. DynDOLOD updating LOD flags does not cause references to enable/disable. Can you show a screenshot of a reference record in xEdit? The placement in the world itself, the form id you see in console when clicking on an object.

Lets focus on the problem. Exhausting VRAM *should* only affect textures and performance, but not entire models. To double check, by object flickering, you mean an object actually springs into existing and then disappears again. We are not talking about two models occupying the same space and texture z-fighting? Does it happen with a new game like coc whiterun? What is the frequency? Does that happens when the character/camera stands still or do you have to move for it to occur? Look up the reference form id of such an object in xEdit and see which plugins adds it in the first place, and which plugins overwrite it. For DynDOLOD to have an affect on it it needs to be the last overwrite obviously. Make a screenshot of the xEdit window for such an object.

xEdit/DynDOLOD use the game registry keys to know where the game is installed. Run the games launcher once to generate/update the registry keys. Make sure to start DynDOLOD/TexGen in the correct game mode. It defaults to TES5 (Skyrim). If you want to to use the tools with SSE (Skryim SE) add the -sse command line parameter to the shortcut as explained in the manual.

What are these objects that are appearing and disappearing exactly? Full models? LOD models? What mod(s) they belong to? When do they appear when do they disappear. You making it sound like it is a common issue. What's the connection to DynDOLOD? DynDOLOD typically works the same if other plugins are are merged beforehand or not. Make sure to read Dealing with merged Mods in the manual. Obviously do not merge plugins after generating LOD that are used as masters by DynDOLOD.esp. You should not merge or rename DynDOLOD.esp The game supports a max of 256 plugins. Changing the load order after generating LOD can require having to generating LOD anew depending on circumstances.

I have no idea what Flickering of Death is supposed to be. What is flickering? If you installed DynDOLOD and generated LOD first before doing merges, you are doing something wrong.

Thanks for letting me know.

If it can not fit billboards anymore than they are too large. The tree LOD texture atlas can not to be split into several files unlike the object LOD texture atlas. The max is 8192x8192 and the billboards for the wordspace can not all be placed into that dimension. If billboards have lots of different heights that are not multiples of 32 or 64 the packing routine may have a hard time placing them efficiently. Try resizing some billboards.

Something is going really wrong there. That is not really normal. Memory usage should go down again after each worldspace before starting the next. 3.1GB is sure the max a 32 bit application can use. Consider restarting Windows. Since we never had such severe memory problems in the past I am not entirely sure about external influences... Aside of hardware problem (overclocking, CPU temps, memory timings, disk read errors) I can not imagine any third party program like an anti virus causing such troubles. It is also likely there is a memory leak or corruption in DynDOLOD (xEdit) that requires very specific circumstances. If you like you could try to use DynDOLODx64.exe as it can it as much memory as Windows can supply. However that would require some work on your end, since you can not start it from within 32 bit MO. Either you would need to re-create a manual installation or use MO2. See if not changing LOD brightness changes anything.

That is about the same max what I see too. Which is plenty below what can be used by DynDOLOD. If the worldspaces work by themselves we can rule out corrupt source texture files I guess. It probably is because of something in my sloppy code. There is not really anything else I can think off you could test for me at the moment. I will try to do some debugging here. If you also want to generate LOD for these worldspace, I suggest to first generate anew for all other worldspaces. Then install the output as usual. Then update the existing DynDOLOD.esp keeping it in the load order while starting DynDOLOD.exe and then just select the worldspaces from Dreamborne Islands (either repeat one by one or try all 4) and then merge the new output with the existing one from the first generation overwriting all older files.

DynDOLODs max tile does not need to match TexGen size. That's fine. I am just trying to understand what settings you used. The DynDOLOD max tile setting defines the size/quality of the resulting texture atlas. Default is typically fine (for me). It's settings rather depends on available VRAM / performance requirement than anything else. Yes, you can just not check those worldspaces (the mods ships with decent static/tree LOD generated by DynDOLOD anyways) and skip them. For a test I am going to ask you to try the opposite: Try generating a single of its worldspaces and see if the memory error still happens. Then upload/post ..\DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_TES5_*_flat_textures_used.txt ..\DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_TES5_*_textures_used.txt ..\DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_TES5_*_textures_used.txt ..\DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_TES5_atlas_map_*.txt ..\DynDOLOD\Edit Scripts\DynDOLOD\cache\DynDOLOD_TES5_flat_atlas_map_*.txt for whichever worldspace you have the error first with? What Windows version (32/64 bit) do you have? How much RAM is installed? Can you try to track DynDOLOD.exe memory usage in Task Manager. Just the ballpark max number you see when the error happens.

Both :)

Did you run TexGen beforehand? With what settings? Did you change MAx Tile Size on the advanced option?

The partial log you uploaded shows the error. So its good enough. I see it happens on a worldspace of Dreamborne Islands. I will do some tests with that one myself and see if there is a general problem with something.

The log may contain all runs so far. Just truncate it to the last generation with the error. Post it to paste bin or use a file service.