sheson

2. Maybe you mean -D:"Q:\Elysium\Stock Game\Data"

9. The version information needs to be accessible and exist (virtually) in the data folder, e.g. Q:\Steam\steamapps\common\Skyrim Special Edition\Data\Meshes\DynDOLOD\lod\version.ini Check via the MO2 data tab. The OS is telling the program the file does not exist, either because the file does not exist or because access is denied.

If you have such trouble with PapyrusUtil, just switch to DynDOLOD DLL.

https://dyndolod.info/Messages/File-Not-Found-Textures File not found texture errors are solved by installing the missing file. The message tells you the mesh that uses that texture. It also tells you the plugin and thus you should be able to identify the mod. As explained in the linked help page, missing normal map textures (*_n.dds) are automatically substituted with the default flat normal map.

Moved to sticky thread for that error message... If you are using DynDOLOD 3 alpha, did the message not contain a "Click on this link for additional explanations and help for this message"? https://stepmodifications.org/forum/search/?q=system cannot find file specified

DynDOLOD does not require a specific runtime version to generate grass LOD in object LOD. https://stepmodifications.org/forum/topic/15606-dyndolod-300-alpha-58/?do=findComment&comment=254861

See https://dyndolod.info/Help/Ultra-Tree-LOD#Internal-Billboards-and-External-Billboards and https://dyndolod.info/Help/Mesh-Mask-Reference-Rules As you can see the numbers simply match the different definitions in the INI.

Looks like the vanilla ESM got updated between 2017 when the FO4LODGen-HighTrees.esp was created and now. Like any other ITM that should be removed. I will go through the plugins and records to check if there for more changes to the game files happening in the past years.

The part in question uses a different texture compared to the main part. The LOD model included in DynDOLOD Resources defines the same textures as the vanilla full model like this since 2017. In the vanilla full model the part is a decal with an alpha-property (which is not supported by LOD) so it is made to look like the full with the decal applied. It seems the vanilla texture textures\architecture\windhelm\WHruinstonedark.dds for that part is changed with one that has a different alpha channel that makes it so that the decal is barely or not visible in the full model. Use a different replacement texture with a similar alpha channel to the vanilla texture. Alternatively create a custom LOD model that uses the same texture as the main part. Rename the BSTriShape to Windhelmbridge:2 when doing so. Better yet merge the separate shape with the main part in the custom LOD model.

Really not sure what additional explanations are required for a "file does not exist" message? FAQ: Game: DynDOLOD could not read DynDOLOD_Worlds / DynDOLOD can not read data for [worldspace name] from DynDOLOD_Worlds / DynDOLOD_Worlds does not belong to these DynDOLOD plugins / DynDOLOD can not read bunchofnumbers from DynDOLOD_[worldspace name] / DynDOLOD_[worldspace name] does not belong to these DynDOLOD plugins / DynDOLOD can not read index data from DynDOLOD_[worlspace name] / DynDOLOD can not find [worldspace name] in DynDOLOD_Worlds / DynDOLOD can not find master data in DynDOLOD_[worldspace name] A: Make sure SKSE and DynDOLOD DLL or PapyrusUtil are installed correctly, see DynDOLOD requires DynDOLOD.DLL/PapyrusUtil above. A: Make sure the *.[json|txt] data files in the SKSE subfolder of the DynDOLOD output and the DynDOLOD plugins are in sync from the same generation process. Check the DynDOLOD SkyUI MCM Information page in the game that all plugins and files have the same bunch of numbers. A: Make sure the *.[json|txt] data files in the SKSE subfolder of the DynDOLOD output are in the load order and can be read. In case DynDOLOD DLL is used, check the c:\Users\[username]\Documents\My Games\[Skyrim|Skyrim Special Edition|Skyrim VR]\SKSE\DynDOLOD.log for errors.

Read https://dyndolod.info/Help/Wizard-Mode or https://dyndolod.info/Help/Advanced-Mode what it says for the Worldspace check list. DynDOLOD already filters out worldspaces by default. See https://dyndolod.info/Mods for specific mention of mods, for example https://dyndolod.info/Mods/Beyond-Skyrim-Bruma Really read the explanations for each message type in the Summary or at https://dyndolod.info/Messages. "Warning messages inform about issues that should be fixed. If they are ignored there might be visual or game play issues." "Error messages inform about issues that need to be fixed. If they are ignored the process might not be to complete successfully and/or just like with warnings, there might be visual or game play issues including CTD." Typically the warning message are either to easily and quickly spot problems with mods or the load order, or to check once a problem is noticed in the game. As https://dyndolod.info/Generation-Instructions explains, if the processes "completed successfully" and you saved the plugins, the LOD mod is typically usable then.

cgid files were "invented" by NGIO. There is no other tool that generates them at the moment.

Read https://dyndolod.info/Messages/Initially-Disabled-Large-Reference As suggest see https://dyndolod.info/Help/Large-References for further explanations. If the affected cell has visible z-fighting caused by this large reference being initially disabled, the only solutions are to not initially disable the reference or to move all the large references that have visible z-fighting underground and replace them with new reference that are not large references. Or do not use the large reference system at all by turning it off. DynDOLOD does not require NGIO, it requires the cgid files to generate grass LOD. That means, you can use the cgid files generated with NGIO using runtime 1.5.97 to generate Grass LOD with mode 1 with DynDOLOD and use it with runtime 1.6.342 without NGIO running and let the full grass be done as usual by the engine.The position of the LOD and full grass will not match perfectly. To achieve that, you could rename the all cgid files to just gid and set bAllowCreateGrass=0 and bAllowLoadGrass=1 in the Skyrim INI. However you need to make sure that all vanilla *.gid files from Skyrim - Misc.bsa are being overwritten, since they are invalid (still in the Skyrim format) and cause visual problems/CTD.

No the files is not missing. As explained in countless posts and on the help page https://dyndolod.info/Messages/Can-Not-Copy-Resource that opens when clicking on "Click on this link for additional explanations and help for this message", this means the file can not be written to the output path. Read the solutions given on https://dyndolod.info/Messages/Can-Not-Copy-Resource Find other posts https://stepmodifications.org/forum/search/?&q=system cannot find path specified No that is not required or needed. Read https://dyndolod.info/Installation-Instructions and https://dyndolod.info/Generation-Instructions. They include all the required steps. They do not include all the things that are not required.

This thread is for Skyrim/Enderal but it seems you you are using Skyrim Special Edition? FAQ: DynDOLOD can not read data for [worldspace name] from DynDOLOD_Worlds A: Make sure SKSE and DynDOLOD DLL or PapyrusUtil are installed correctly, see DynDOLOD requires DynDOLOD.DLL/PapyrusUtil above. A: Make sure the *.[json|txt] data files in the SKSE subfolder of the DynDOLOD output and the DynDOLOD plugins are in sync from the same generation process. Check the DynDOLOD SkyUI MCM Information page in the game that all plugins and files have the same bunch of numbers. A: Make sure the *.[json|txt] data files in the SKSE subfolder of the DynDOLOD output are in the load order and can be read. In case DynDOLOD DLL is used, check the c:\Users\[username]\Documents\My Games\[Skyrim|Skyrim Special Edition|Skyrim VR]\SKSE\DynDOLOD.log for errors. Make sure the DynDOLOD DLL scripts overwrite DynDOLOD Resources. Does this happen with a new game?

Billboards are complete side views of trees. https://dyndolod.info/Help/Tree-Grass-LOD-Billboards The screenshots do not show billboards. The player typically never gets close to LOD like this in normal game play. It is unclear what the problem is supposed to be. Zero information was provided. No mention which tree mod and which 3D tree LOD model, no mention about used settings, etc. To determine if a texture that is added to the texture atlas would benefit from a higher resolution, see https://dyndolod.info/Help/Texture-Resolution#Determine-Sensible-Texture-Resolutions Which exact setting to change depends on the assets being used in this case.

If the error were only generating object LOD meshes with LODGen and everything else completed successfully and you could save plugins, then it should be enough starting DynDOLOD in expert mode and select the desired worldspaces and click Execute LODGen to restart the object LOD meshes generation again. See https://dyndolod.info/Help/Expert-Mode

You probably need to set OnlyLoadFromCache = False in the NGIO GrassControl.config.txt so it is allowed to generate cgid files on demand. Once done, set it back to OnlyLoadFromCache = False

Always use the latest DynDOLOD version. You can not use the full model for ENB for static object LOD since the object LOD system does not support the ENB particlar light. They get translated to those disks. Set None for all LOD Level 4, 8, 16, 32, set VWD, set NeverfadeFull for Grid and keep Unchanged for Reference. Unfortunately that also means it can not be visible on map. You could set Level2 for LOD Level 16 to have the usual LOD model be on the map as a poor substitute.

"Error processing grass data Tamrielx-017y-036.cgid" from the LODGen log is self kind of explanatory. There is a problem with the mentioned cgid file. The contextual help for LODGen errors should have been this https://dyndolod.info/Help/LODGen page, which includes an explanation for this message and how to solve it. So does https://dyndolod.info/Help/Grass-LOD#Troubelshooting. Each entry from the Summary has explanations what they mean and what action they might require if any. If you have a specific question about a particular mod or message, then ask it. The vanilla DLC contains deleted references and everybody will have the warning messages if they are not cleaned. Everybody will have the same large reference overwriting warning from those plugins, since they were made without considering the Skyrim SE large reference bugs. And so on.

Read the first post of the DynDOLOD 3 Alpha thread where to make posts when participating in the DynDOLOD 3 alpha test. I moved the post to the thread. Read the first post what entire log file of the last meaningful generation and debug log file to upload when making posts. Also upload bugreport.txt if it exists. Make sure textures\landscape\mountains\MountainSlab01.dds resolution is power of 2.

Make sure to press low, medium or high button so the rules are loaded and then generate LOD as usual. Remember that any mesh rule matching first is used. Do not turn off any mods, especially if you want to have LOD create for it. If that does not help, provide actual information. Which game version, which install option, which DynDOLOD version. What the mesh rule looks like. What you mean by far and getting close, e.g. the distance in cells or game units.

I find it curious why after 7 years of noticing anybody would care now. There is about 200 references in Tamriel for these. The dynamic LOD are as performance friendly as possible with no particles and no ordered nodes. If a systems struggles already it will have an impact that they are always active and visible. I suggest to use reference rules to specifically target the dozen waterfalls where it would actually matter, like the Darkwater falls.

The position/rotation of references is used for all LOD types that are based on references. So if a plugin moves a references and LOD is generated then any LOD type for it will move too.

Nobody ever noticed (or cared to ask) about the current settings which originated in Skyrim LE, so there wasn't any reason to change anything about it. If you define to use the vanilla object LOD model for object LOD level 4, it will z-fight with the dynamic LOD model. A static object LOD model would need to have considerable distance behind/lower to not z-fight. If you make models that work I'll happily add them to the resources. Dynamic LOD does not affect or change static object LOD or vice versa. All different LOD types work independent of each other. Technically or programmatically there is no such thing as between Far Grid and fBlock0distance. Object LOD level 4 starts beyond uGridsToLoad or uLargeRegLODGrideSize.