sheson

Try UseGrassCache=True, OnlyLoadFromCache=True, RayCast=False (after cache has been generated), ExtendGrassDistance=False, DynDOLODGrassMode=1 Do performance tests with vanilla game and vanilla INI settings. There won't be any stutter loading the full grass from the cache. If loading gid files does not stutter, then loading cgid files should not stutter either.

Check/Upload the TexGen debug log as explained in the first post. All files in the ..\Render\Billboard\ and ..\Render\Objects should be found and processed. Base records or bounds for these files are irrelevant. If combining trunks and crowns has errors about missing trunk.txt, it means that there are no such trunk NIF for TexGen to create the billboard texture and txt or there were problems reported in the log and/or debug log generating them.

The DynDOLOD Resource SE archive on Nexus has been uploaded in January and downloaded over a 114,000 times. If the files actually had an issue it would have been long reported and fixed. Files uploaded Nexus are exactly the same files as uploaded to Nexus. In particular the DynDOLOD Resource SE for Skyrim Special Edition does not contain files from DynDOLOD Resources for Skyrim as found by the error check and message.

Unpack the DynDOLOD Standalone archive into a new empty 'DynDOLOD' directory.

Great.

It seems TexGen tries to use an Internal Intel graphics card. Try setting the NVIDIA card to be the preferred graphics processor in the Manage 3D Settings / Program Settings of the NVIDIA Control Panel.

Read the first post what log files to upload when encountering errors or problems using the latest DynDOLOD 3 Alpha version. Otherwise pay attention to how how often DynDOLOD updates, the changelog ( improved worldspace bounds warning/error settings) and the version number. The current version is Alpha-37, not Alpha-33 anymore. Even back then, the error message about the worldspace bounds has a link to a help page how to rectify the issue.

What graphics card(s) are installed and what is their physical VRAM size?

No screenshots needed. Yes, using meshes rules the easiest most compatible and preferred method to use the full model for LOD. If there are trees on the world map depends on ultra tree LOD and if the tree mesh rule(s) assigned billboards to the object LOD level (16 by default) that is used for the map as explained in the "Trees on the Map" section of ..\DynDOLOD\docs\trees.ultra\DynDOLOD-Trees.html Nothing should have changed in that regard if you didn't change any settings.

Read the first post what logfiles to upload and where to post when participating in the DynDOLOD 3 alpha test and reporting problems. Unpack the DynDOLOD Standalone archive into a new empty 'DynDOLOD' directory. Sounds like unpacking into a new and empty folder the second time had the desired result. In case the new alpha version was unpacked into an older DynDOLOD 3 alpha version, unpack the DynDOLOD Standalone archive into a new empty 'DynDOLOD' directory. Can you delete the bugreport txt and start TexGen again to see if it writes a new one in case the out of memory error happens again?

Read the first post carefully. Also read what log files to include when making posts. If there are so "many" other reports about the "same" problem, then whatever was answered to those still applies. What else is a program supposed to do after the OS tells it the requested memory is not available. More memory is required to continue the work. Without the memory the work can not continue.

This bug is hopefully fixed in Alpha-37

Thanks, that is the information I need to fix this bug.

If More Informative Console shows a reference FormID to be defined in a plugin, the record exists in that plugin. Note that I messed up the load order ID and it is actually 24 instead of BB. It is the number reported in front of the plugin name [24] DynDOLOD.esp

The screenshots shows a normal file header record. The FormID of the file header record is always zero/NULL. The first two digits of a FormID are the load order ID of the plugin. The screenshot shows DynDOLOD.esp being currently loaded a load order ID 24 in xEdit. Change the first two digits of the FormIDs from D6 to 24 in order to look up the FormIDs defined in the DynDOLOD.esp plugin at its current load order ID.

What is the EditorID of the reference with the FormID D6063741 defined in the DynDOLOD plugin? Everything else is irrelevant. What is the EditorID of the references with the FormID D606385B and D6063743 defined in the DynDOLOD plugin? What record (reference?) is defining a Null reference (for the NAME Base record or which element?)?

Look up the form IDs of the references which are defined in the DynDOLOD plugins to find out their EditorIDs to see which plugin and formID are the source for the LOD objects.

First line of the post says: xLODGen beta (47 or newer) and DynDOLOD (2.70 or newer) can be used to update or generate TVDT Occlusion culling data on cell records, which is famously wrong for some cells in Tamriel causing rectangular holes in the distant LOD. The occlusion specific settings in the DynDOLOD INI exist since DynDOLOD 2.70 which was released almost 2 years ago. Look up the form IDs of the references which are defined in the DynDOLOD plugins to find out their EditorIDs to see which plugin and formID are the source for the LOD objects. The full models added by some plugin right next to the LOD models are usually irrelevant.

Read the log messages from the xEdit plugin loader. They typically explain what the problem is and often also what to do.

As the DynDOLOD manual installation instructions explain, do not mix with old versions or xEdit/xLODGen installation.

As the error says, do not install DynDOLOD Resources. Install DynDOLOD Resources SE for Skyrim Special Edition. There is at least one file from DynDOLOD Resources installed / overwriting DynDOLOD Resources SE.

Read ..\DynDOLOD\docs\help\Terminology.html and/or the section Terminology in ..\DynDOLOD\docs\DynDOLOD_Manual.html to find some explanations what things mean. The screen shots you posted list the ref(erence) form ID of the reference records defined in a DynDOLOD plugin. Enter the reference form id into the FormID field top left of xEdit to look up the record and to find out its EditorID which tells you the source plugin name and source form ID the LOD representation is for. Typically we would expect them to reference in the Solitude child worldspace.

Read the thread Skyrim TVDT - Occlusion Culling Data and/or the section TVDT - Occlusion Data in ..\DynDOLOD\docs\DynDOLOD_Manual.html or ..\DynDOLOD3\docs\help\OcclusionCulling.html Thanks.

Read the first post what logfiles to include when making reports. Test with a new game to make sure this not a botched clean save update. If you find references defined by DynDOLOD.esm or DynDOLOD .esp open the reference FormID in xEdit to check the EditorID to learn which pluginesp_formid is the source. If it points to another reference in DynDOLOD.esp check its EditorID. The next steps depend on what plugin and reference the source is. Remove DynDOLOD Bright LOD Waterfall Fix. It is not required since many months.

If there is a normal log file there also should be debug log!? The third time also didn't create a debug log?