sheson

Nowadays either will work. \ at the end it doesn't matter really anymore.

So the vanilla has 2D tree LOD and static object LOD (and Terrain LOD that DynDOLOD not yet touches). These pre-computed LODs are just many static supermeshes/texture files that are loaded and displayed at fixed positions. To change them they need to be generated again. They basically have no features/functionality. They are just really large models that have idea about the models or their properties that were used to create them. Then there is this setting (Is Full LOD / Neverfade) that allows to show full models with all their function/features in the LOD area past the loaded cells. Typically used for clouds/fog in the mountains. References using this feature are always active and culled by the pre-computed occlusion, which means having a lot of them to improve the distance quickly becomes a resource and performance problem. So I "invented" dynamic LOD, which is explained in the manual in the section "DynDOLOD Mod". So with the definition of the Near / Far Grid those models are disabled when at certain distances, allowing for more of them to be used overall in the entire world. For exactly the waterfalls, windmills, the whiterun tree, fires etc. being the main purpose. The dynamic LOD is also used for what could have been static LOD, but is an object in the game, that enables/disables based on quests. There are like a few buildings and landscape features that change over time when playing the game. Helgen for example, everything is fine and all the buidlings are broken. The vast majority of landscape features and buildings etc is static LOD, though. If you leave the dynamic options blank than those meshes/reference that can not (by definition) be in static LOD because they are quest enabled/disabled will not get dynamic LOD either (which is mostly how vanilla LOD treats them).

I tested these mods a long time ago. Will retest with latest versions of everything and see if I can find anything.

yes, you could say it that way. LOD typically is defined on the base record level, so it equally affects all references using that base record. If MNAM data is used and a LOD level is not defined for a LOD level, there will be no LOD for this object in that level. With the default settings of DynDOLOD, the MNAM - Distant LOD definitions of base records typically are ignored and do not matter unless they are used for fallback, because a filename match was not possible. Setting a LOD level for a mesh mask/reference formid rule means it should use the defined LOD model for that level if such a LOD model exists. See DynDOLOD_Mod_Authors.html for how the filename of the LOD models define to which LOD Level they belong to. Generally, the engine does not use single LOD models directly for LOD. The engine uses pre-computed supermeshes. The MNAMs is just data for CK/TES5LODGen, while DynDOLOD uses rules and filename conventions before falling back on MNAM data. Because of how Bethesda setup LOD in the first place you will find similar LOD models with just different textures. mountaincliffslope_lod_0.nif mountaincliffslopegreen_lod_0.nif mountaincliffslopesnow_lod_0.nif mountaincliffslopeyellow_lod_0.nif These were then manually assigned through NMANs. DynDOLOD mimics that idea by having a list DynDOLOD_TES5_textures_names.txt which matches texture sets to those names green, snow, yellow and many more. You will then find a lot of models in DynDOLOD Resources using these names. Thus my notion if a mod uses new/undefined texture sets I might need to add the required data for it to make textures match - if falls back to the default model instead, typically brown / dirt but not always. TexGen updates all these. In addition, DynDOLOD can also automatically apply texture set replacements to LOD models, however, this only works with LOD models I created specifically for this purpose. The default method mostly just works fine but requires manual additions for new mods that require them - that is typically just new lands mods. I might add that Fallout4 does this better, because its material sets also define LOD textures replacements. There are just LOD textures. They do not really have levels. Different quality LOD models intended for different LOD levels typically share all the same LOD texture. All supermeshes for all LOD levels share the same atlas texture. TexGen uses text files with its own type rules how to copy/resize/paste single hi-res textures into single/mini atlas LOD textures which are then later used for the atlas creation. See "How to add LOD textures creation rules to TexGen" in DynDOLOD_Mod_Authors.html DynDOLOD/TexGen does not create LOD meshes - if you mean taking a full model and decimate it. Creating LOD meshes requires specialized software and manual labor. DynDOLOD + LODGen.exe use LOD models found in the load order and creates supermeshes "Static Object LOD" *.BTO 1. Entirely depends on the rule which applies in this case. 2. _FAR is for LOD models used in Oblivion. It is a xLODGen setting required for Skyblivion worldspaces. Billboard means to use a billboard texture with an automatically created 2D flat meshes X in static LOD. It is kind of explained in file:///C:/Skyrim/DynDOLOD/Docs/trees.ultra/DynDOLOD-Trees.html 3. the DynDOLOD options are nicely explained in the edit window after double clicking a rule and hopefully somewhat in the Configuration section of DynDOLOD_Manual.html

3. DynDOLOD does not change how LOD works in the engine. Everything past the loaded cells is LOD area, which typically means the full models are replaced by lower quality LOD models. Since the engine simply switches between models instead of morphing there is always a visual change when that switch happens. You can use DynDOLOD mesh rules to set base records of objects or specific reference to use the full model in LOD level 4. Then the shape and texture are identical when the switch happens and only lighting/shadow/decals/snow shader are different. This can have the worse side effect that the is even more obvious because both full and LOD model exist at the same time for a second and cover each other perfectly in 3D space causing flicker. Skryim SE switch has slightly better fading in this regard. 4. If no LOD model is assigned to LOD level 8, then those objects will not have LOD in that level. However it sounds like you are looking up default LOD assignment of the base record in CK, xEdit. DynDOLO overwrites those with its mesh rules, unless you check the box "Use orginal LOD assignments" In regards to texture, the are two things that can happen. Either a LOD model use pre-rendered LOD textures - like Windmills (but not the Riverwood style Farmhouses) or that a replacement texture on a base record has no specific LOD model for the replaced texture. The first requires manually updated/crafted LOD textures. The last can only happen with mods using yet undefined replacement textures. It is a bit more complicated to explain. For example, if you happen to have a full model landscape texture being snow white change to brown dirt LOD. It is a crutch I need to keep from vanilla LOD for now. If I ever could find the time to update all suitable vanilla LOD models that could be more automated, but the crutch typically works good enough and is quickly updated for new mods. There is no way the engine can support full models for LOD4 for everything mesh rule. LOD models are typically What you could try is creating a mesh rule for the folders "landscape\mountains\" and "landscape\unique\" with LOD4 set to full model, then either LOD8 set to static LOD4 and LOD16 set to static LOD8, or just keep 8/8 and 16/16, VWD checked, Far LOD etc. That can work, but you need to get used to a different type of flicker/transition because of lighting/shadows/decals/snow shaders as explained above.

Adjust ReservedMemorySizeMb in the ENB overlay while running around in the game. Turn off all LOD with console command tll, that allows better seeing the moment new cells are loaded. You can adjust values live using the mouse controlling the spinner, while using WASD to move. Use BethINIs. Set CustomMemoryBlockTotalSizeMb so that memory report in console shows none of the buffers at 100%, but just slightly below it. Alternatively test performance by using default heap memory adjusted with memory blocks log (UseOsAllocators=0), then a third test with AlignHeapAllocate=1 Lower overall demand of generated LODs by using low, medium presets. See the manual Performance section for more.

You can easily test if tree LOD is causing anything by changing tree LOD distance to zero either in the SkyrimPrefs.INI [TerrainManager] fTreeLoadDistance=0 or using the DynDOLOD MCM Settings page. If on the other hand the loading of full objects causes hitches, try default BethINIs and adjusting ReservedMemorySizeMb while in-game in ENB overlay directly in ReservedMemorySizeMb. Start with values 0, 32, 64 and increment in small steps. If you use crash fixes UseOSAllocators use the Custom Memory and check non of it is not hitting 100% in console.

This happens with a new game like coc windhelm from main menu for example? The second image shows an object from ELFX, is that what the first reference Editor ID in DynDOLOD points to? If not can you check the Editor ID of e90043af, which is pluginname+formid. If pluginname is DynDOLOD.esp, check that records Editor ID until you find a plugin that is not DynDOLOD.esp, e.g. the full source object. Let me know the version and install options you used for ELFX so I can try to replicate.

good to know, thx

I am not sure what loading of full models has to do with DynDOLOD. Why do you believe it is only trees, it loads 5 or more entire cells that moment, terrain and trees are one of the first thing.

As long as DynDOLOD is loading after mods altering tree records it will be fine. That should automatically be the case if after generating LOD for the load order you let LOOT sort it out.

This is how the engine works. Static LOD is only unloaded once the full 3D models are loaded, until then both models show. The flicker happens because of lighting/shadow differences between full models and LOD. The flicker time will be longer if DynDOLOD.esp is not loaded or its tree base records overwrites are overwritten. It unsets the Has Tree LOD flag and replaces it with Has Distant LOD.

The current version does not read the billboards *.txt OR *.ini files in BSA. This just came up a couple weeks ago. The next version will.

You need to generate tree LOD for the current load order and make sure it is not overwritten by other mods.

You could try the latest version and see if it makes a difference. If this only happens in one worldspace, maybe there is a uniquely used (full?) model causing this, though then it should always happen.

Both DynDOLOD and LODGen are multithreaded programs. DynDOLOD has a few routines that can max out CPU. LODGen alone typically does not do 100% CPU for me. The only way I know LODGen seems to freeze/wait is when it can not read or write files because another process is blocking them. MO, UAC, anti virus etc.

Yes unknown flag errors are fine and can be ignored. DynDOLOD is using some undocumented tricks to do certain things.

While the install order of billboards seems correct, generally it is better to sort their priority directly after each tree mod they belong to. Sometimes mods may contain billboards in their main download and not as an extra installation. The only thing DynDOLOD can do with them is to make them darker or brighter in the advanced option. The texture resolution is not changed when generating vanilla 2D tree LOD. For anything visual other than brightness, you may need to check with the billboard creators.

Next version will deal with that file format properly. It can be done without error or otherwise bothering the user. Thanks a lot for the help.

Could be a while. I will just have to go over code that deals with merge mods. If you still have all the map files that could help actually. They are in ..\data\merge\*_map.txt for each of the merges. If you could upload/paste them somewhere.

Thanks for letting me know. It gives me an idea where to look for that error.

The log you pasted lists [00:00:21.741] Found 52 merged mods [00:00:21.766] Found 892 merged form ids Can you try to disable all those merges until those log lines do not show anymore, to see if the error message goes away? Regarding the LOD in game, as example, Dragonsreach is supposed static LOD, not dynamic near/far LOD. Upload/paste the log from the medium generation that worked. Also upload/paste ..\DynDOLOD\Logs\LODGen_TES5_Tamriel_log.txt and..\DynDOLOD\Edit Scripts\Export\LODGen_TES5_Tamriel.txt, maybe I can determine what is going on from that angle.

Regarding the error message when clicking low, medium, high. If you can still replicate it, please test if temporarily removing the bashed patch or any/all of the merged plugins changes the number 539 or even prevents the error from happening.

Sorry, but the error reporting makes no sense to me. Maybe you can post a picture or two?

I am not sure what you mean by LOD is gone. LOD can be turned off with tll in console. Maybe the LOD distance settings in the INI are really low - which means LOD detail is really low as it uses the highest LOD level for everything for example. If object LOD generation is incomplete it should fall back to vanilla LOD for all or parts of the LOD. Check the end of the log of the generation that there are lines for each worldspace looking like LODGen.exe completed succesfully C:\Skyrim\DynDOLOD\Logs\LODGen_TES5_Tamriel_log.txt