sheson

Read the first post. It has a link to a file and a text service. It explains which log files to upload. It explains which log files can be truncated to the last meaningful session. If you actually look at the DynDOLOD log - which is printed to the message window and then saved - it has lines which worldspace(s) generated successfully and which had errors and the full path to the LODGen log file(s) to check. For example: <Error: LODGenx64.exe failed to generate object LOD for Tamriel. Check C:\DynDOLOD\Logs\LODGen_SSE_Tamriel_log.txt> If help is required to interpret log messages people can upload them. It is as easy as zipping the files and uploading them to a file service as explained on the first post.

The word "file" in the post links to a file service, while the word "text" links to a paste text service. Doesn't get any easier than this. Truncate large log files to the last meaningful session. A session starts with DynDOLOD .... starting session 2021-11-07... which is the first line you see in the message window when DynDOLOD is started. Check the DynDOLOD log which is printed to the message window while the tool run and saved to the log file when the program is closed. There is at least one log message tell you which worldspace failed and which LODGen logfile to check. That is what the error prompt reports so users do not miss the error message in the log. The Help for this message says the same thing. "In case LODGen failed to generate object LOD for one or more worlds, check the log messages (click OK, then click Check log). Typically the log message will already show which worlds failed and which specific LODGen log file to check for additional information about the error." It is all very straight forward and plain. All you have to do is read everything verbatim. If you do not know what a term/expression means, check ..\DynDOLOD\docs\help\Terminology.html, google it or ask in the forum.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log and which LODGen logs to upload. It also mentions using a file service. Truncate large logs to the last meaningful session. If you watch the log messages while the tools run, you should have no problem to determine the first lines how the logs start. Which is where you truncate. Also do what the error message says "Check for error messages in the listed LODGen log(s)" and check the LODGen log for details. That log should be uploaded as well in case you need help with its messages. Also click the "Help for this message" link to open https://dyndolod.info/Help/LODGen. The bugreport.txt seems to be showing a completely different error which typically would prevent DynDOLOD to reach the point where it report errors in the LODGen log. Missing textures in TexGen are a problem in TexGen. These missing textures prevent successful billboard generation. There is NEVER a need to empty the cache. it is pointless.

Read the included documentation: ..\DynDOLOD\docs\help\Underside.html "placed slightly under the full terrain" ..\DynDOLOD\docs\help\Advanced.html "The Height sets the negative distance to the actual terrain. Lower numbers mean better better blocking at a higher risk of the terrain underside mesh visually peaking through the actual terrain or terrain LOD." As already explained, use xLODGen to generate terrain LOD. As you know form the DynDOLOD manual, terrain is the ground. You also already generated terrain LOD meshes with protect cell border to fix the weird drops in the terrain LOD meshes. As already explained, Read the manual which explains what the Near and FarGrid is and that they are a concept of dynamic LOD. Terrain underside, terrain LOD, Grass LOD etc. typically does not change anything in the loaded cells.

"... the more distant cells are potentially disabled." xLODGen readme: "The data is used to disable LOD meshes that are occluded by terrain. For example a big mountain hides any LOD behind it. Disabling hidden LOD meshes frees up draw calls and reduces poly count of a scene." DynDOLOD_Manual.html/OcclusionCulling.html: "Occlusion Data defines the visibility of terrain and object LOD for a cell. For example a big mountain hides any LOD behind it. Disabling occluded LOD meshes helps performance." The more LOD is disabled the better for performance "The data is used to disable LOD meshes that are occluded by terrain." Of course it does not change the quality of LOD meshes/textures.

As explained in the manual or while hovering the mouse over the Ultra checkbox, ultra tree LOD means LOD for trees in done in object LOD.

As explained before, read the included documentations of xLODGen/DynDOLOD. They explain each setting. Quality - samples per cell. The more samples are used the more distant cells are potentially disabled.

The files you uploaded show that the Grass checkbox under Tree/grass LOD Billboard options was not checked when TexGen was run. Hence it creates no grass LOD billboards.

As explained on the second post and answered to the earlier question, grass LOD billboards need to be generated with TexGen and installed in the load order in order to be able to generate grass LOD. DynDOLODGrassMode in NGIO does not affect the pre-caching of grass. It is a distance setting that defines how far full grass renders.

Use xLODGen to generate terrain LOD meshes and textures to improve terrain LOD in the LOD area. Generate grass LOD with DynDOLOD to have grass LOD in the LOD area. See the first and second post to see the requirements and instructions how to generate grass LOD.

If there are no grass LOD billboards generated, then you found the problem. There obviously is no point to do any checks beyond that point until that requirement has been met. To generate grass LOD billboards with TexGen, check the Grass checkbox in the Tree/Grass LOD Billboards options. See ..\DynDOLOD\docs\help\TexGen.html Read ..\DynDOLOD\docs\help\LogMessages.html to learn what log messages mean.

Read the second post of the DynDOLOD 3 alpha thread / ..\DynDOLOD\docs\help\GrassLOD.html how to generate grass LOD. It explains everything you need to know how to fill those areas with grass LOD, including tips for performance.

The answer about unresolved form IDs is to a quote of another user. The forum software sometimes combines posts from the same user into one. It does not apply to the problem that the game is not loading scripts from mods. Sorry for the confusion.

No idea what thread from 2020 you refer to, but the object bounds and to recalc them is explained in this thread and in the included documentation. For that grass mod, too IIRC. Limit the max threads to reduce memory consumption as explained in these post or the INI. Start with 1: https://stepmodifications.org/forum/topic/15606-dyndolod-300-alpha-53/page/124/?tab=comments#comment-250521 https://stepmodifications.org/forum/topic/15606-dyndolod-300-alpha-53/page/15/?tab=comments#comment-244301 https://www.take-a-screenshot.org/windows.html

Only thins that have dynamic LOD objects or rules will they have dynamic LOD. If they large references and are assigned to FarGrid or are assigned to NearGrid and the Upgrade NearGrid large references to FarGrid is checked. Full models are always full models. Large references are full models in the LOD area just like IsFullLOD/Persistent references that are disabled and unloaded at the uLargeRefLODGridSize, which has no levels. Dynamic LOD models included in DynDOLOD often have particles removed for optimization.

If you just need to move something, just move it via the ESM. If the reference is using different base record / NIF then adding a new reference might be better to avoid trigger large references bugs because the "volume" or the base record type is different. If you want the newly added references to be large references, then they need to be in the ESM and the large reference data needs to be genrated. If you believe you owe users who do not mod properly anything, that is up to you.

Sounds like an issue with the OS not scaling things correctly. Is this Windows 10? If I can replicate I might be able to add a pixel or two to prevent that. If you do not want Initial Disabled large references to trigger visible large reference bugs, then maybe change those records in the plugin. However, DynDOLOD fixes those anyways. In the release version it will only report records that it couldn't fix, like DynDOLOD 2.x does. If you have an ESM flagged plugin and want its references to be large reference, then you can use the script. Make sure to use this version: https://github.com/TES5Edit/TES5Edit/blob/sheson-create-large-ref-script-updates/Build/Edit Scripts/Skyrim SE - Generate Large References.pas Or better, add rules for DynDOLOD so the full model (or a special dynamic LOD model) gets dynamic LOD in the NearGrid. Large references do not show in an object LOD Level. They are full models that are loaded already in the LOD area beyond the uGridsToLoad. Similar to IsFullLOD/Persistent references.

Not quite sure what is confusing about unresolved form ID? The record that is being linked to does not exist. It is an error that has been forever reported by xEdit error check already.

Fix the unresolved error in the broken patch plugin. Click the "Help for this message" link for further explanations and instructions.

Large reference bugs cause the LOD for all large references in the same cell to stay loaded. It does not matter if the large reference causing the bug itself has LOD. DynDOLOD 3.x reports many more problems and issues than DynDOLOD 2.x. The end of process summary about issues is not finished yet. DynDOLOD 2.x/3.x fixes the UDR in ESM flagged plugins by removing the Initially Disabled flag and removing the enable parent to the player. The first two screenshots do not show if the DynDOLOD Resources are actually enabled and if the scripts are actually available in the ..\Data\Scripts\ folder and accessible by the game when it runs. Whatever problems causing the game not loading scripts from other mods and DynDOLOD Resources is outside of DynDOLOD control. Assuming the files are at the correct location and have the correct file names and the game is started from MO2, it could be permission problems, anti-vir etc.

This thread is for the DynDOLOD 3 alpha test. DynDOLOD does not change grass in loaded cells. DynDOLOD does nothing with landscape. Use xEdit cell browser with CTRL+SHIFT+F.

These error messages in the papyrus log mean scripts files are missing: 'Cannot open store for class "...", missing file?' As I already wrote in the earlier answer, the scripts are part of DynDOLOD Resources Core Files which needs to be installed completely. Scripts from other mods seem to be missing, too.

You yourself referred to the INI settings which object/terrain LOD level is used for the map: "Which means we don't have to change the lod settings to 16 in his ini." Occlusion data does not cause lag spikes. It determine which LOD quads are rendered for a cell. Read ..\DynDOLOD\docs\help\OcclusionCulling.html Read ..\DynDOLOD\docs\help\Advanced.html and hover the mouse pointer above a setting for hints. Read ..\DynDOLOD\docs\DynDOLOD_Manual.html "TVDT - Occlusion Data" They all explain the quality setting determines how many samples are used for the calculations to generate the occlusion data. Read ..\DynDOLOD\docs\DynDOLOD_Manual.html "DynDOLOD Mod", which explains what the Near and Far Grid is and that they are concepts of dynamic LOD. It goes without saying that the further or the more stuff is shown the more resources it uses. Regardless of LOD type/method. Read ..\DynDOLOD\docs\help\GrassLOD.html which explains that grass LOD is done in object LOD level 4. No idea what hints you are expecting for showing grass in all countrysides as you do not explain what the problem is. Refer to the troubleshooting section in case grass LOD is incomplete. If you want to see how different settings affect your unique load order and setup, take a before and after screenshots or refer to guides that do these things for their particular load order. The performance impact of the setting will be negligible with grass or 3D tree LOD, too high INI settings or 8k apple textures.

Read the first post. You did not upload any logs. In this case the entire papyrus log also would be of interest. "Unable to bind script" points to a an (incomplete) LOD generation or an installation problem (like DynDOLOD Resources missing or not installed completely). Read ..\DynDOLOD\docs\help\LogMessages.html for explanations what log messages mean. As the readme explains, install .NET Script Framework for Skyrim Special Edition and check its crash log for clues. Upload the crash log if help is required.

Initially Disabled references can cause large reference bugs. The plugin type does not matter. If they have an enable parent they most likely do. If they do not have an enable parent they might. It happens a few times in the vanilla game with references only defined in Skyrim.esm for example. It seems only the one at the Winterhold college bridge affects full and LOD models that occupy the same 3D space. In all other cases the LOD models in the cell are smaller so it isn't that obvious that full models and LOD models are loaded. Typically the report is meant for reverse troubleshooting. If there is texture flicker because of full and LOD models being loaded at the same time, test if it is caused by the large reference bugs by disabling them. If they are the cause, search for the cell coordinates in the log if they are being reported. In case there are no log entries, search the debug log, too.