sheson

Whatever happens with long outdated versions is meaningless. The issue is that the OS told the program can not have anymore memory when it requests some. Error messages are that plain and straight forward. Obviously available memory and memory requirements are different every time. Unless there is an repeatable issue with a specific file. Unfortunately so far you have only mentioned it happened more than one time, but not if it happens with the same BTO or different BTOs specifically. Also I have not yet seen any log of the last generation with the error message. If the BTOs contain 3D tree LOD or grass LOD they require much more memory to be loaded.

Use xEdit error check before hand and pay attention to its warning messages and finalize the load order before generating LOD. There really shouldn't be (m)any errors after that.

It is means system memory. What matters is how much system memory is available and how much memory the program wants to use and if the OS grants the request. The OS controls system memory and the OS is what tells the program it can not have any more. If it is always reporting an out of memory error with the exact same BTO even after restarting the PC or closing other programs, then there is an issue with the file and the xEdit nif reader, even if NifSkope is able to load it.

Error when loading "meshes\terrain\Tamriel\objects\Tamriel.4.-8.20.bto": Error reading NIF block 24 BSSubindex TriShape: Out of Memory Do not post screenshots of text. Post the entire log as text into spoilers or to pastebin. If the mentioned NIF is not corrupt and loads without error with NifSkope, then the program needs more memory as the message says.

Post entire log to pastebin or upload to a file service. Post bugreport.txt if it exists. There might a problem with the mentioned textures. Obviously make sure both textures are valid DDS file and can be accessed by xLODGen without problem. It is possible there is invalid alpha layer data on the LAND record 0000DE02. Check if a plugin overwrites it.

Read the included manual, like the FAQ answers for DynDOLOD.exe: Not seeing all worlds in the selection box. A: Some worlds added by plugins are filtered out by default, because generating LOD for them might not be useful or requires special attention. Remove the worldspace name from the filter file ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAMEMODE]_worldspace_ignore.txt. Search for the mod, plugin or the worldspace name on https://stepmodifications.org/forum/forum/223-shesons-dyndolod-xlodgen/ for more information. This was already explained and discussed years ago as Beyond Bruma came out in 2017 and DynDOLOD 2.30 or so.

Disabling plugins is a troubleshooting step. Read FAQ: Game: Out of place objects / floating objects / flickering full models Read the first post what to include when making a bug report post. Also include how to reproduce the problem. Additional information to provide would be the name of the plugin and form id mentioned by the EditorID of the LOD window reference in the DynDOLOD plugin.

TexGen generates textures. It's settings are explained in the included documentation. Read docs/help/TexGen.html As mentioned before, the folder sizes of the output is a meaningless value. It varies depending on load order, source textures resolutions and settings etc. What is important is that the resolutions of textures are not unnecessarily larger than they have to be for each individual texture and that (only) the required textures are generated that are needed for the load order and your preference. The logs and reports print out what is generated. The tree report lists what tree uses what LOD assets for which LOD asset. Read my previous posts and the manual. Billboard1 or Billboard4 are the best suited for HD billboards with normal maps. From docs/help/Billboards.html: HD Tree LOD billboards are diffuse and normalmap *.DDS textures that show the rendered tree/grass from a front and a side view. They can only be used with ultra tree LOD. From docs/help/TexGen.html: HD Tree billboards are for the optional ultra tree LOD generation. If HD billboards exist for a tree, they take precedence over standard billboards. Read docs\trees.ultra\DynDOLOD-Trees.html for principle explanations of ultra tree LOD

By default shack pieces only have LOD in the the first LOD level 4. If you see LOD again extremely far away the LOD level distances are probably messed up, like maybe higher level 16 has shorter distance than lower level 4. That is assuming the shack has static object LOD. See How LOD works in docs\DynDOLOD_Manual.html

From docs/help/Billboards.html: Tree and Grass LOD billboards are diffuse *.DDS textures that show the rendered tree/grass from a front view and a *.TXT file with additional information about the width, height etc. HD Tree LOD billboards are diffuse and normalmap *.DDS textures that show the rendered tree/grass from a front and a side view. They can only be used with ultra tree LOD. The tree/grass LOD billboards are used for a simple 2 plane model crossing like an X if viewed from top. AFAIK the little tree mod does not include 3D tree LOD models so far. So if a LOD level has Level0 defined, DynDOLOD will fall back to the billboard defined by TreeFullFallBack in the DynDOLOD INI settings and explained in docs/trees.ultra/DynDOLOD-Trees.html and/or above the INI setting. If you prefer Billboard4 for example, set TreeFullFallBack=4 As explained plenty of times before, when participating in the DynDOLOD 3 alpha test, do not install any billboards from mods (they are for xLODGen/DynDOLOD 2.x). They should all be generated by TexGen for the current load order and will always take current overwrite order of plugins/models/textures into account.

This is how things look with vanilla Sktim and DynDOLOD 3 alpha 33: Full models of the cabin in the active cell. Vanilla references and base records not overwritten by any plugin: Object LOD for the cabin generated by DynDOLOD 3 alpha 33: To verify that we see static object LOD that goes away when all LOD is disabled: Consequently, in a vanilla game, the full models in the loaded cells are unmodified and they have correct static object LOD generated. You posted screenshots that show wooden beams instead of the cabin and reported that those are references/base records defined in the Skyrim plugin that are not overwritten. That only leaves something overwriting the full models as explanation why shack pieces are all of sudden wooden beams. In the LOD generation process DynDOLOD overwrites base records setting the HasDistantLOD after object LOD has been long generated. Setting the flag does not affect LOD generation, it is rather the other way around. The overwrite/flag does not change the full model. DynDOLOD 2.x sets the flag on too many base records unnecessarily, DynDOLOD 3.x is just smarter about it. So what I am saying is, generate LOD for the vanilla game without any other mods/plugins to test.

Read "Tree/Grass LOD Billboards" in docs/help/TexGenConfiguration.html to find out how TREE base records are selected for tree LOD billboard generation. TexGen scans the currently installed plugins, and then uses the currently installed full model and the referenced full textures to generate the tree LOD billboards. Check the log and especially the debug log for message regarding errors or skipped base records. The logs are the most important tool to understand the what and the why. If you believe the output is missing billboards it should have generated, adjust the plugin data, fix any errors if there are any or force billboard generation as explained in the manual. Using output that was generated for a different load order might not match with the current load order, e.g. different models/texture CRC32 will be reported by DynDOLOD.

Setting that flag does not change the full model, the LOD model or if something has object LOD generated or not. Generate LOD for the vanilla game with DynDOLOD 3 as is to test.

There are probably no LOD models for the wooden beams, that is why they have no LOD. You reported that the wooden beams are all vanilla records. You need to find out why in one load order those vanilla records show cabin models with walls and why in the other load order the same? vanilla records show wooden beams. You reported that none of those vanilla records are being changed by DynDOLOD. When I generate LOD for vanilla Skryim with DynDOLOD 3, I see the the usual cabin close up and for LOD. The memory question is somewhat vague. See the first post, changelog and the included manual to learn about the changes and feature updates between versions. It is very likely there are more or higher resolution object LOD and billboard textures with the default settings. For example, rendered object LOD textures can have up to 2k resolution compared to the 256 vanilla textures.

DynDOLOD 3 is an alpha version to test settings and to find and report bugs or problems. Which billboard type you use for which LOD level depends on your preference. Billboard1 or Billboard4 are the best suited for HD billboards with normal maps. If you define to 3D tree LOD models for LOD level 4 depends on your preference. The path and file name of LOD billboards are defined by the master plugin and form id that adds the tree base record and the model filename defined by the winning overwrite. The size of files in a folder is not really a meaningful metric for anything. The log tells you which object LOD textures and which LOD billboards are being created. TexGen generates textures for the current load order. If the load order changes and depending on the TexGen settings it might generate more or less files. As docs/help/TexGenConfiguration.html explains, the bounds defined on the base record define if a tree/grass is suitable for automatic billboard generation. Billboards can be forced to be generated or not via config files, too.

TexGen uses the installed full textures when it generates LOD billboards. The preview can be used to check the visuals. DynDOLOD uses the installed LOD billboards when creating the object LOD atlas. The INI grass brightness settings are applied when generating object LOD meshes. If the RGB values are equal the color tone does not change. The second post explains how to update textures or how to update one object LOD mesh for quicker tests.

The HasDistantLOD flag does not change models/textures. The way plugins can change things is either by updating/replacing the references to use different base records, base records are updated to define different models or models themselves are being replaced. If you see references/base records from vanilla Skyrim, how is what you see a problem with DynDOLOD?

If you use tfc to fly close, then LOD does not get replaced by the full model. It should be easy to make a close up screenshot of the LOD with TFC. Check if what looks like scaffolding actually is static object LOD by disabling LOD with tll in console. If the wooden beams remain it means they might dynamic LOD or just full models. In either case they should have reference form ids. In case they do and they are in a DynDOLOD login, look up the form IDs in xEdit. The reference have an EditiorID that typically starts with pluginname_formid. If they have static object LOD that goes away with tll, then check what mods overwrite DynDOLOD Resources. This almost looks like there is mod that replaces the cabin with different stages of rebuilding it.

Child world spaces like the walled cities replace the temporary content of CELLs in the parent world that have the same coordinates. To see an object in the child world in such a replaced CELL a reference needs to be added for it. This can either be done by adding them in the plugin with CK/xEdit or by creating a patch file for DynDOLOD similar to the Whiterun/Solitude Exterior patches that are applied when DynDOLOD is generating its plugins. If you are using DynDOLOD 3 alpha, then it might be good enough to just update the rule to LODGen1=sky_seagull,None,None,None,None,FarLOD,KeepChild,0

If there are no LOD files, VWD should be unchecked, e.g. the 1 at the end should be 0 This could be simplified into one rule in its own file data\DynDOLOD\DynDOLOD_SeagullsofSkyrim.ini [Skyrim LODGen] LODGen1=sky_seagull,,,,Far LOD,Replace,0 Using Replace instead of Unchanged makes it so that the animation doesn't restart when switching from LOD to full model. AFAIK the latest version already includes a DynDOLOD rule file.

woodcut01.dds is not a valid DDS texture. TexGen/DynDOLOD reporting errors or problems is not a TexGen/DynDOLOD issue. It means there is a problem with the texture. Questions regarding third party software should be asked on its support forums.

Use tfc to make a better screenshot of the full model and LOD cabin. Have you checked if a plugin changes the references or the base records of the cabin?

Read the first post carefully. AFAIK Green Tundra Patch affects textures used by grass (and thus by grass LOD) and terrain and thus terrain LOD. If only textures are changed there is no need to updated grass cache. If only grass textures are changed there is no change to any grass NIF. Just running TexGen to update grass billboards and stitched object LOD textures, then running DynDOLOD in expert mode to updated the texture atlas might be enough. If then object LOD in the game looks to be using wrong textures, then Executing LODGen in DynDOLOD expert mode should be enough to update LOD meshes with the new object LOD texture atlas positions. You will also have to update terrain LOD for the changed landscape textures to take effect, unless you are using the pre-made terrain LOD textures I suppose.

Check if a mod replaces textures\dungeons\ships\shiproof01.dds textures\dungeons\ships\shipwoodside01.dds Use xEdit Asset Browser (CTRL+F3) to find all containers for a file including BSA. Make sure TexGen generated stitched object LOD textures without errors. Especially textures\lod\shiproof01lod.dds textures\lod\shiplod.dds Make sure nothing overwrites the output of TexGen. Check if a mod overwrites the references or any of their base records of the (wall?) pieces that seem to be missing or might have transparent LOD textures. Permanently delete whatever "dyndolod glowing double windows fix attempt.esp" is. Fix or permanently remove Blacksmith Chests.esp that has all the HITMEs errors. HITME stands for HIgher Than Master Entry. This message is printed by the internal xEdit error check. The first two bytes of the internal FormID refer to a non existing index of the Master Files list on the File Header record for the plugin. This means it can not be determined if the record is an overwrite (and which master plugin it belongs to) or if the record is added as a master record by the plugin itself. This can happen when entries are forcible removed from the Master Files list for example. In case the plugin is a the result of using a merge tool, it might be possible to fix it by loading and saving the plugin in CK or xEdit. In most other cases the plugin is most likely broken beyond automatic repair. DynDOLOD 2.x/3.x does not change how the engine or LOD works. Typically the game loads all full models first and then unloads object LOD. If memory is tight it is possible that the displaying of full models coming into view is delayed and they obviously fade in way after the fact. If problem persists make a screenshot of the LOD for the cabin area.

Truncate large logs to last meaningful session(s). Split large logs into several pastebins or zip logfiles and upload to a file service, like google drive, dropbox, mega etc.