sheson

Less demand on certain resources so the situation with the error is avoided. Probably happened before trying to troubleshoot TexGen being terminated IIRC.

As explained in https://dyndolod.info/Generation-Instructions pay attention to log messages, in particular these ones: <Error: Game runtime version 1.6.659 does not support plugin Resources - The Great Cities.esp version 1.71 with form ID < 0x800. Install Backported Extended ESL Support> <Error: Game runtime version 1.6.659 does not support plugin The Great City of Winterhold v4.esp version 1.71 with form ID < 0x800. Install Backported Extended ESL Support> <Error: Game runtime version 1.6.659 does not support plugin The Great Town of Ivarstead.esp version 1.71 with form ID < 0x800. Install Backported Extended ESL Support> Make sure Backported Extended ESL Support is installed, activated and works. The logs verify that you generated standard tree LOD. If just installing Backported Extended ESL Support does not fix the tree LOD not unloading because the game didn't load any plugins with version 1.71 without it, see answers for the already linked https://dyndolod.info/FAQ#Billboard-tree-LOD-shows-in-active-exterior-cells and make sure to generate LOD for the current load order of plugins. This is not caused by DynDOLOD or the order of its Resources. See https://dyndolod.info/Help/Load-Overwrite-Orders. Also see https://dyndolod.info/Messages/Max-Tree-LOD-Billboard-Count-Of-256-On-Atlas-Exceeded

Requested logs and useful screenshots were not provided. DynDOLOD does not really create those billboards close-by. This is a game engine issue with LOD not unloading. https://dyndolod.info/How-LOD-Works

Moved to an appropriate thread for the reported issue. Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts. It also explains: The log and the debug log are often sufficient regarding information about the load order, used mods and plugins. Consider uploading load order information to modwat.ch or loadorderlibrary.com and link it to provide additional information. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make useful screenshots in the game with more informative console. https://dyndolod.info/Generation-Instructions Activate the plugins(s). In case Occlusion.esp was generated, it should be the last plugin to load right after DynDOLOD.esp. If a DynDOLOD.esm was generated it should be the ESM with the highest priority possible or just before the first non-ESM. ESM can not load after non ESMs. See https://dyndolod.info/FAQ#Billboard-tree-LOD-shows-in-active-exterior-cells

The DynDOLOD.log shows what happens when starting the game to the main menu only. The one that is recorded with whatever was done to produce Papyrus.1.log above would be of intertest. If you do not care about the save, then test what happens when starting a new game (from main menu with coc riverwood for example) and in case there are issues, upload the corresponding Papyrus log and DynDOLOD.log from DynDOLOD.DLL.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen log and debug log to also upload when making posts. The ParallaxGen_Diff.json created by ParallaxGen seems to have an issue. Use a tool to check if it validates. For example https://jsonlint.com/. In case it validates, upload it. If it fails, check the ParallaxGen log for hints, rerun it, check with its developer.

The also requsted DynDOLOD.log from DynDOLOD.DLL was not provided. Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs how to uplaod the DynDOLOD.log from the DynDOLOD.DLL. If a DynDOLOD.DLL is being used or installed, also upload the entire DynDOLOD.log: c:\Users\[USERNAME]\Documents\My Games\Skyrim Special Edition\SKSE\DynDOLOD.log. The linked logs only contain a DynDOLOD_SSE_Debug_log.txt and DynDOLOD_SSE_log_truncated.txt. So I also requsted the papyrus log and DynDOLOD.log from DynDOLOD.DLL afterwards. That request was ignored. I checked the uploaded logs from the DynDOLOD generation as I wrote: The uploaded DynDOLOD logs show that DynDOLOD output was generated with DynDOLOD DLL NG and Scripts installed. Still not clear if an existing save game or new game was started when those message shows. The Papyrus.0.log does not show much seems like main menu only, no message related to DynDOLOD. The Papyrus.1.log looks like what happens when a save that is not cleaned is being loaded. Load whatever save that needs cleaning without any DynDOLOD output, Resources, DLLs etc. files whatsoever active in the load oder. Go into an interior if not in one. Save the game. Make a backup. Use the Clean option Remove unattached instances and Remove undefined elements for Scripts and Script Instances starting with #SHESON_DynDOLOD_* with Resaver from FallrimTools - Script cleaner and more on that save. Then load that save and save again. Then enable DynDOLOD Resources, DynDOLOD DLL NG and Scripts and the DynODLOD output make for it. Load the last save.

Requested logs were not uploaded. It is still unclear if a new game was started or a save was loaded. The plugins generated with DynDOLOD DLL NG and Scripts active do not use any papyrus scripts that print messages like "DynDOLOD can not find * in DynDOLOD_Worlds" and "DynDOLOD can not find master data in". Only plugins that were generated without DynDOLOD DLL NG and Scripts in the load order use a papyrus script that prints those messages. If there was no old plugin in the data folder, then maybe another tool made copies of records from an old DynDOLOD plugin. Do not create patches after generating LOD, make them beforehand as explained in the generation instructions. Since you gave up troubleshooting and deleted the data folder, I suggest to follow a modding guide that explains how to properly setup the game and how to use a mod manager like MO2.

Writing the realtime log means the tool is using a bit less CPU and the entire process to take a bit longer. It will generate everything just the same, so the output is perfectly usable.

Generating better higher resolution terrain LOD meshes with xLODGen should fix that. https://dyndolod.info/Generation-Instructions#Prerequisites Typically generate and install terrain LOD meshes and textures with xLODGen before generating the LOD mod with DynDOLOD https://dyndolod.info/Help/xLODGen

https://dyndolod.info/Mods/Base-Object-Swapper#Chance Any randomized swaps defined with Chance are ignored by default. Any LOD will be generated for the original reference or base record. Set SwapsChance=1 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini in case all these references or base records should be ignored for LOD. https://dyndolod.info/How-LOD-Works These LOD types are basically discrete combined super meshes that each cover a large number of cells that are loaded at fixed positions. These super meshes are a fixed snapshot of the load order at LOD generation time. It is technically not possible to generate matching LOD meshes for things that are changing once the game loads. Simplified, the size of everything is hardcoded into the LOD meshes.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs how to also enable and upload the papyrus and the DynDOLOD.log from the DynDOLOD.DLL. It is unclear if you are starting a new game or loading an existing save. Test with a new game, like coc riverwood from main menu console. The uploaded DynDOLOD logs show that DynDOLOD output was generated with DynDOLOD DLL NG and Scripts installed. However, the message most likely means there are old DynDOLOD plugins are active in the load order that were generated without DynDOLOD DLL NG and Scripts being active. This message can not really show when starting a new game with the plugins from the generation shown in the log. Make sure there are no old DynDOLOD plugins in the load order, also not renamed ones and that the output from the log is overwriting everything. I suggest to follow a modding guide to learn how to mod properly with a mod manager like MO2.

No DynDOLOD logs and no papyrus logs were provided. Read the first post and https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs. As explained before, the message can not load DynDOLOD_NG_Worlds.txt typically means that DynDOLOD DLL NG and Scripts was installed after generated the LOD patch. You can not use DynDOLOD output that was generated without DynDOLOD DLL NG and Scripts present at generation time and then just install DynDOLOD DLL NG and Scripts. Install all requirements and finalize the load order before generating LOD. Generate a LOD patch from scratch for the current load order. Do not change the load order after generating LOD or follow the instructions how to update properly. Read and follow https://dyndolod.info/Installation-Instructions how top properly install DynDOLOD and its requirements and https://dyndolod.info/Generation-Instructions how to generate TexGen and DynDOLOD output.

No logs or an actual problem description has been provided. it is not clear what "DynDOLOD is disabled (somehow)" is means. Disabling/Removing the DynDOLOD output in the mod manager is typically a straight forward thing to do. The game will typically report that the plugins are missing and ask to load anyways. It is no clear what "doesn't result in a clean save" means. In this context a clean save means it was made without any DynDOLOD plugins and scripts being loaded. The save will be extra clean from every old DynDOLOD data after removing unattached instances and undefined elements as explained in https://dyndolod.info/Help/Clean-Save.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages which DynDOLOD debug log to also upload when making posts. Copy and post the message text instead of making a screenshot as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text Download this test version https://mega.nz/file/MRxBBTjL#267jsRwyeejQ7rpMn3I2jE55WMvGT97FmsR2P6Yn90Q of DynDOLODx64.exe, delete all old logs and bugreports.txt and generate LOD for DLC2SolstheimWorld to see if that makes a difference. If there still is an error upload new log, debug log and bugreport.txt. Check with xEdit if there are any plugins overwriting the cell 0400FFCD. If the zip archive has CRC errors, then there might be some kind of problem with the hardware like CPU, memory, disk or the tool used to decompress the archive. Do not create the archive at the end and instead copy/move the output to the mod folder with a file manager like Windows Explorer.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen and DynDOLOD logs, debug logs and which LODGen log to upload when making posts. Ask specific questions for anything that needs more detailed explanations for. I assume your post means that after generating grass cache, parts of the full grass still fades out while other parts of full grass still remain inside the uLargeRefLODGRidSize. That typically means the diffuse texture of that grass type is badly generated mipmap that fades to fully transparent. In that case I would try different grass mods with better textures, try to fix the mipmaps of the texture with Texconv --keep-coverage command line argument. Generating grass LOD is not going to affect problems with full grass.

If DynDOLOD can not write other logs files while running but not the realtime log, then the wrong INI file is being edited or the setting is not added correctly. Copy and paste the line RealTimeLog=1 to bottom of DynDOLOD_SSE.ini Once the wizard/advanced options window shows, there should be a DynDOLOD_SSE_realtime_log.txt in the logs folder.

Requested logs were provided. If you disable all LOD with tll, then whatever remains is not LOD. That probably means you set NGIO to render full grass render beyond the active cells to the large reference grid distance and generated grass LOD with mode 2 accordingly. Whatever happens with full grass is not affected by DynDOLOD. Maybe the grass cache is outdated and if you have no set NGIO to only load full grass from cache, then when the cell attaches, the missing full grass is generated. In that case, grass LOD will be also not show anything for that patch. Or the full grass is using a full texture with badly generated mipmaps that fade to transparent. In that case using tfc to fly closer to the patch missing the full grass will fade in. In that case grass LOD should probably show for the patch.

Requested logs were provided. https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots Note that terrain LOD, tree LOD or object LOD does not have a form ID. To determine if something is LOD, toggle LOD on/off with tll in console. In that case, also walk close to an object, so its reference with the full model is loaded in order to get its form ID and provide that screenshot of the full model in addition to the screenshot of the LOD. Hence clicking in the LOD area will often select either cloud references or the terrain underside reference which is placed below terrain LOD. "This" is not a problem description. "This" still refers to a patch not having grass LOD? When the area loads as active cell, does this patch have full grass? https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots A screenshot alone does not substitute describing the issue with text. "This" is not a problem description. The screenshot shows vanilla terrain LOD without any optional grass LOD generated by DynDOLOD, so it is unclear what "this" refers to now. If "this" refers to the wired terrain LOD gap, then generate terrain LOD meshes with xLODGen with the Protect cell border checkbox checked. https://dyndolod.info/How-LOD-Works, https://dyndolod.info/Generation-Instructions#Prerequisites, https://dyndolod.info/Help/xLODGen

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen and DynDOLOD logs and debug logs to upload when making posts. Changing a diffuse textures appearance is not really going to change how the engine/shaders light things at different times of day. https://dyndolod.info/Help/Grass-LOD#Settings Especially the image based lighting effect from ENB has a big impact on the brightness and color tone of the grass LOD. Additional complex grass lighting and time of day settings will obviously not apply to object LOD, as they are separate meshes and shaders. Do not use them so full grass and grass LOD match better for all weathers/times. If the engine/shader can not affect (grass) LOD the same way it affects full LOD, then you might have to turn off or reduce effects that change full grass lighting to keep consistency with LOD. https://dyndolod.info/Help/Grass-LOD#Internal-Billboards-and-External-Billboards You might want to experiment with the normal vector direction of whatever NIF is used for the grass LOD billboard. Compare the double sided 4 triangles ones used for "normal" full grass to the single sided ones used for complex grass with Nifkope. It might help bending the normal vector straight upwards so they receive more light when the duirect light/sun is above.

Moved to the appropriate thread for the message. Typically this error happens with TexGen, but it still is probably the same issue in DynDOLOD. Download the test version of DynDLODx64.exe from this post https://stepmodifications.org/forum/topic/20153-error-opengl-framebuffer-objects-unsupported/page/2/#findComment-282545 and try again. Delete all old logs beforehand. Upload new logs if there still is a problem.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs whichTexGen log and debug log to upload when making posts. https://dyndolod.info/Generation-Instructions#1-Generate-The-Required-LOD-Assets-with-TexGen TexGen should not take more than a couple minutes to run. Time is not a good metric to know if something worked correctly or not. The logs are.

Add "passthru" to the filename (for example mountainpeak02BRpassthru_lod_0.nif) so the shaders settings (as much as possible) for all shapes of a NIF are left intact or add "passthru" to the BSTriShape Name (for example MountainPeak02:1 PassThru) to target a specific shape only in a NIF. The "auto passthru" gets overruled for LOD Level 4 because of reasons. Since the LOD model has only one shape, either way is fine, but in case you decide to separate the glow like in the full model, then keep the filename and just add "passthru" to the appropriate BSTriShape. Do it for all LOD models equally. See intro of https://dyndolod.info/Help/3D-Tree-LOD-Model and then "Shape Names" near the bottom. Let me know in case this still does not work or causes unforseen issues.

The uploaded logs are from the "release" version and not the test version from https://stepmodifications.org/forum/topic/20153-error-opengl-framebuffer-objects-unsupported/page/2/#comment-282545 Also, it is RenderTexturesSingleThread - note the s after texture, use copy and paste in case the settings are needed.

Moved to the appropriate thread for the error message. Use search as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search. See posts above. Try the test version from https://stepmodifications.org/forum/topic/20153-error-opengl-framebuffer-objects-unsupported/?do=findComment&comment=282545 and if there is an error upload the new logs. If still has some kind of an opengl error, try setting RenderTexturesSingleThread=1 in C:\apps\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.ini and if that makes no difference set RenderSingle=1 and if that makes no difference set RenderBillboardsSingleThread=1