sheson

Never :) It will be out of beta once nobody reports any errors anymore for a while when running the DynDOLOD World.pas TES5Edit script. LOD meshes will never be complete or done... Watch the DynDOLOD Guide video. Seems safe to me :) Static LOD is always safe. You do not have to use the dynamic component that uses papyrus scripting. Uncheck the box when generating and/or just do not load it when starting Skyrim.

Updated first post. No point in writing much texts. There is LOTS of documentation in the archive already. Also, unlike any other project I actually documented some of the code, if you are so inclined.

It will not change the underlying mechanics of static LOD. So in the case of multibound objects that span across cell borders they will still load the same time as before. However you could add rules to make the particular mesh in question to use a full model for the nearest LOD level 4. Lets talk custom settings like this once the new beta is out.

It scans load order and anything that there is a lod mesh for will have lod. But wait there is more: you can also use full models either for LODgen static LOD, or for the dynamic LOD switcher. The cool part: it scans the meshes folder for LOD files (or unpack them from BSA first) and thus uses all LOD models that come with mods. For example Unofficial Dragonborn Patch has some. I also uploaded a how-to video to accompany the multi-page manual that virtually no one is going to read anyhow. for a glimpse of what is to come:

Fixing remaining bugs actually. The TES5Edit script kind of grew very complex, it took an life of its own. Not much longer, though :)

Before and after video

Next beta coming soon! Don't like em waterfalls? Use SkyFalls, almost the same thing really :)

Yes, this is alive and hard being worked on in the past months. There are now over 800 new lod models from rocks, cliffs, roads to Skyhaven Temple, Orc strongholds, you name it. I even did a few things in Solstheim already. The whole process of creating LODGen LOD and DynDOLOD for Tamriel takes about 15 minutes right now. I kind of have the hope to release the same time a new/fixed version of LODGen.exe is released as I found quite a few visual glitches and other things to optimize. While it can produce OK looking LOD, it takes some extra hacking to produce the look in the screen shot below. This is all vanilla settings, no enb, the only extra assets is stuff from DynDOLOD and this tree LOD texture I still have. No other mods in this image. I admit, this one was pushing limits in terms of main memory usage because it uses LOD4 in LOD8 as well. The graphics card is not the problem, GPU memory use is just a couple hundred MB more, GPU may be from 30% to 50% on my GTX680 4GB, but I had to use my memory patch to the limit to load the assets, it seems the LOD bto go into block 1... doh. Anyhow, a more sensible setting of what goes in LOD4, LOD8 this is totally playable even when the number of LOD objects goes from 15,000 or so to 70,000 It will be coming, soonish :)

this one is more of a traditional mod than manipulating the exe, so yes... start tes5edit from MO and then do things, though manual copying of files from one directory to the other maybe required. before after, WIP

Right now performance is less than SDO with its esp. But since you run TES5Edit LODGen and DynDOLOD Generator yourself for your setup you can also adjust which models to use or not and thus control visuals and performance yourself. It will be a while until it all has a nice interface and stuff with fancy checkboxes. Generating the needed resources comes first :)

For comparison this it how it looks in the vanilla game And yes, TES5Edit LODGen with my resources replaces SDO, Object LOD BTO files and will create native object LOD for things added by mods, like new ships or buildings, rocks... DynDOLOD replaces/modifies the full model neverfades from SDO esp and other mods and makes other dynamic objects like fire, waterfx or objects that appear or disappear based on quests/progress visible at distance.

Adding more polygons will always put more demand on graphics :) The full models neverfades add a lot of stress. The less of them active at any time the better. I spent the last 2 weeks working with LODGen, creating LOD nifs for rocks and nordic buildings much like SDO did. In the process I discovered a couple things that need to be addressed by LODGen, so I am discussing that over at afkmods as well. So there is progress on a complementing process and result between LODGen and DynDOLOD. It will take a bit of time, but I really like the results I have so far.

@fireundubh I have your firstborn already, address me any way you want :) LODGen replaces SDO premade BTOs. Given enough time I can write up a detailed explanation about it and the process for optimal LODs between all the tools/mods. For example, default Skyrim comes with lod meshes for bridges, but has most disabled, so even LODGen doesn't do them unless you do a small esp fixing this. SDO has them already in addition to custom meshes Grieche used and didn't release when he did it. Right now I need to focus on the DynDOLOD persistent objects and papyrus scripts and safe games/quests. I guess it is a rather novel approach to use papyrus scripting and trigger boxes to do such things, I am still not sure about it... :) The less objects we have to handle this way the better. @z929669 1. Eventually sure - if we deem this to be a safe thing overall. It might be a while though. 2. DynDOLOD already covers all objects from the SDO esp, and most likely almost all objects done by Distant Detail / Distant Detail Hearthfires. We can make sure it does, it is as simple as adding the objects as statics to it and let the generator do its thing. I really need to work on the options of DynDOLOD generator... the whole thing turns out to be a bit more complex :) 3. LODGen generates the BTO files, the vanilla way of doing static object LOD from LOD meshes. (there is land BTR, objects BTO and trees BTT) It can add high polygon models too but that quickly destroys performance. Overall having LODGen produce the static object LOD files with true LOD meshes and then DynDOLOD cover only the models which turn on/off, are animated and certain trees should be the best mix between the two performance wise. DynDOLOD doing certain trees is because the BTT lod trees created by CK can only be straight up. Fallen or otherwise tilted trees do not work when generating tree lod BTT and the couple trees added by mods are no big deal to be done by DynDOLOD. Unless Flora overhaul maybe... In fact DynDOLOD Generator script could start LODGen and control how it does its thing, though I am not sure if that is a good idea overall. Also DynDOLOD takes other neverfades from other mods like SkyFalls for example and turns them off when they are further away. This means better performance compared to before while they are always active across the entire map.

If you are happy with ugrids 9 I would not check the 'high poly' box for skyrim.esm With default settings this add lots of high poly models into a grid of 11, so you do not really gain anything, only 1 cells each direction. It will still add a few select high poly models (and LOD models) into the large grid of 21 for everything fire and Katariah, and the HearthFires (check both boxes) homes. See readme for how to change the grid sizes and how to add select full models to the large grid. My hope is that with the spread of LODGen we see more true LOD meshes becomes available for rocks/dirtcliffs/tents/roads/etc which are missing now. Grieche should have released his from SDO really. Then DynDOLOD takes care mostly of the animated things and things that turn on or off.

LOL error handling is overrated. The box checks itself when the file is there.I assume you have memory blocks covered with SKSE, maybe you exceed block1 ...If you crash again, keep mini dump from SKSEEventually check at https://www.osronline.com/page.cfm?name=analyzeLater compare dumps if the faulting IP and commands are the same.It is adding A LOT of objects with the roads, dirtcliffs and rocks. I assume a filter for each class of objects is needed to fine tune for preference and performance. Not everybody wants roads for example.Oh and keep ugrids default/low.

15MB mod and 79MB Data txt looks correct :)Made a post about the slowness of things at https://www.afkmods.com/index.php?/topic/3750-wipz-tes5edit/&do=findComment&comment=151249

That is insane :) Do the same run in 3.0.31 and you will be amazed at the speed even though it still may need an hour or so ...Updated to 0.13 beta, make sure to get it for the papyrus scripts updates.

Something seems off, adding objects into the esp never took that long for me. Try tes5edit 3.0.31 next time to see if it is faster. Edit: Wow 3.0.32 [00:47:22.880] Adding 38358 LOD objects .. 3.0.32 [01:34:03.293] 7672 of 38358 records done .. I give up 3.0.31 [00:26:48.685] Adding 38358 LOD objects ... 3.0.31 [00:36:37.408] 34524 of 38358 records done ... [Apply Script done] Processed Records: 2400, Elapsed Time: 47:48 no clue why 3.0.32 slows down like this when adding objects... will do some deeper probing and then post in the official tes5edit forum/thread about it.

If you did skyrim.esm yes... but I think there is room for optimization :)If you have SDO, or if we had the lod nifs from it, it would easily safe 20,000 rocks and things that could be done by TES5LODGen instead.Remember, the priority is to see if this is viable solution at all, the papyrus part with storage util, all these REFS in the game etc.I could swear 3.0.31 was faster than 3.0.32. In any case making this faster will be one of the next things to do.

single thread scripting :(

True, I think it will work to just add "Bashed Patch," into the DynDOLOD_IgnoreFiles.txt as well and then it will ignore them all.Either way, it wont fall over commas in filenames anymore. It will create a zero size cache files which on later runs means the file wont show up in the selectable file list anyhow.

I wish you all the best and good luck with that. I have seen those fire up close too once. Scary. Anyhow turns out the problem was as simple as the comma in Bashed Patch, 0.esp filename. I fixed a related function and added it to the ignore list, since it never should have anything related to objects or lod in it. The rest of the mods worked fine here and it ran through. DynDOLOD will do ALL fires, all creeks, all waterfall effects and the dead trees from the swamp if you process skyrim.esm, not just the select few SDO did.In case I missed a model you could always add more yourself if you feel like or suggest them to be added. Since the creeks and waterfall effects are full models they are defaulted to be in the small Grid of 11 cells. The trees in the Mortal Swamp SDO did are done as flat LOD instead - on the complete map and are by default placed in the large grid of 21 cells. The fires are full models but set to be in the large grid as well. You can control which models go into what grid and/or the grid sizes themselves to fit your needs.

Only the esp mod files that come with SDO use neverfades and those becomes obsolete when using DynDOLOD. Details in the readme in the zip file. Bleak Fall Burrow is not in those esp as neverfade, BUT the campfires and creeks in the tundra behind that mountain are. I guess the quickest way to find out is to test your frame rate without the SDO esps. DynDOLOD will add the creeks and campfires and many more things again - if you choose to let to let it do skyrim.esm in addition to other mods. However, only the objects much much closer to you are active and everything in the tundra will be off at that point, so the end result should be a better frame rate. @Citizen working on your loadorder, I got it almost replicated - couldn't find a couple mods anymore but I doubt they matter. Will post again when I know more

Can you let me know your mod load order? I assume it did create cache files for each mod and then threw this error in the routines after that, most likely when adding LOD objects after the "xxx cells done".

Thanks for testing and feedbackDoh :) updated first post with new version. Cache files now have their own folder.