DynDOLOD 3.00 Alpha 173

[sheson]

30 minutes ago, Mousetick said:

Yes that's true and I agree. But since LOD uses binary alpha and we don't care about transparency, we can remove the alpha by compositing the texture with a solid background.

Before with Alpha > After compositing

Anything that is not white background is 100 alpha (full opaque). Background is 0 alpha (full transparent).

This can be combined with alpha threshold filtering, applied before compositing with the background.

The gradation in shades and saturation is retained.

You changed the color of not 100% opaque pixels to contain white. In the real world/game it does not work like that.
What you achieved is to create an image that looks similar to the alpha checkerboard background preview of the program.
Change the program to actually show the color of all pixels and the alpha channel as mask that can be turned off.
Look up premultiplied alpha and alpha blending. Maybe start with this https://developer.nvidia.com/content/alpha-blending-pre-or-not-pre

[Mousetick]

1 hour ago, Mousetick said:

To use the mipmaps of the original texture defined by the LOD model, add the term UseMipMaps to the BSTriShape/NiTriShape name. This should preferably be done for all LOD models using this texture.

'preferably' or 'absolutely'? I have edited all 5 treepineforest*passthru_lod.nif meshes but I know there is at least another one which uses the same texture. I don't see any difference in-game. Is there a way to check in the log(s) that UseMipMaps is taken into account?

If this doesn't work out, I'll drop this and move on...

---

... to the last niggling "issue" before I reach tree LOD nirvana.

The lighting effect on the branches of the 3D tree LOD crown is very nice as a whole, but is there a way to "tone it down" a bit? It looks too bright to me.

I tried to counter-balance it by darkening the crowns with

; Vertexcolor multipliers for tree LOD models used in object LOD, see https://dyndolod.info/Help/Ultra-Tree-LOD
; CrownBrightness=1
CrownBrightness=0.75

but it's not the right approach, as it makes the snowy trees branches grey for example.

Sometimes the lighting clashes with full model trees in the foreground which are not illuminated as brightly. Also it seems to affect the color?

Thanks.

[sheson]

2 hours ago, Mousetick said:

'preferably' or 'absolutely'? I have edited all 5 treepineforest*passthru_lod.nif meshes but I know there is at least another one which uses the same texture. I don't see any difference in-game. Is there a way to check in the log(s) that UseMipMaps is taken into account?

If this doesn't work out, I'll drop this and move on...

If there is one or more NIF using that texture and not settings that, it might not work consistently. It would be best to copy the texture to a unique new filename and update the NIF to use that instead.
There is no dedicated debug log message but you can check for the absence of log messages like this:
[dynGenerateMipMaps] <Debug: Textures\landscape\trees\treepineforestbranchcomp.dds

2 hours ago, Mousetick said:

The lighting effect on the branches of the 3D tree LOD crown is very nice as a whole, but is there a way to "tone it down" a bit? It looks too bright to me.

I tried to counter-balance it by darkening the crowns with

; Vertexcolor multipliers for tree LOD models used in object LOD, see https://dyndolod.info/Help/Ultra-Tree-LOD
; CrownBrightness=1
CrownBrightness=0.75

but it's not the right approach, as it makes the snowy trees branches grey for example.

Sometimes the lighting clashes with full model trees in the foreground which are not illuminated as brightly. Also it seems to affect the color?

Thanks.

The 3D tree LOD models use 1:1 copies of the full models. Whatever you see are probably effects in the game.

If you want to change brightness of individual 3D tree LOD models, you could darken the full texture directly.

[Mousetick]

On 9/19/2023 at 7:46 PM, sheson said:

If there is one or more NIF using that texture and not settings that, it might not work consistently. It would be best to copy the texture to a unique new filename and update the NIF to use that instead.
There is no dedicated debug log message but you can check for the absence of log messages like this:
[dynGenerateMipMaps] <Debug: Textures\landscape\trees\treepineforestbranchcomp.dds

After many, many tries and goof-ups I finally managed to make it work. I was about to give up but it finally dawned on me (yes, I'm slow) that UseMipMaps must be the solution: if both the full models and 3d LOD models use the same mipmaps, they should look quasi-identical at roughly the same viewing distance.

Here are some results (CrownBrightness was reverted to 1 in DynDOLOD_SSE.ini):

• Baseline: Alpha threshold 224 without UseMipMaps
• Test: Alpha threshold 112 with UseMipMaps

Atlas Texture: Baseline > Test

This shows DynDOLOD's Lanczos filter and alpha-to-coverage do an excellent job compared to the full texture's mipmap, but somehow the mipmaps of the atlas texture end up very different, as seen in the next screenshots.

In-game mid-morning: Baseline > Test

In-game afternoon: Baseline > Test

This is beautiful, I'm so happy. Thank you very much for your assistance and for bearing with me.

Notes:

• I reverted the Alpha threshold to 112 for the UseMipMaps version, because with 224 the atlas texture and mipmaps were completely decimated, there was almost nothing left  I need to tweak the alpha threshold again to correct the lushiness of the 3D LOD models and match it with the full models.
• I tried to rename the textures paths and filenames in the 3D LOD models in order to make UseMipMaps work, but it didn't work as DynDOLOD requires the same paths and filenames in both the full and 3D LOD models. I didn't want to edit the vanilla meshes, so I made sure to add UseMipMaps to all the 3D LOD models that use treepineforestbranchcomp.dds (treepineforest*passthru_lod.nif + treepineforestdead*passthru_lod.nif).
• The branches of the 3D LOD models still look rather flat, but I understand this is due to the LOD's binary alpha. There's nothing that can be done.
• Suggestion for possible future usability improvement: Since the suitability of mipmaps for use by 3D LOD models is an intrinsic property of the full texture, and does not depend on the mesh, it would make sense to specify UseMipMaps separately for specific textures (e.g. in a config file) rather than in each 3D LOD mesh.

Thanks for reading.

[z929669]

3 hours ago, Mousetick said:

After many, many tries and goof-ups I finally managed to make it work. I was about to give up but it finally dawned on me (yes, I'm slow) that UseMipMaps must be the solution: if both the full models and 3d LOD models use the same mipmaps, they should look quasi-identical at roughly the same viewing distance.

Here are some results (CrownBrightness was reverted to 1 in DynDOLOD_SSE.ini):

• Baseline: Alpha threshold 224 without UseMipMaps
• Test: Alpha threshold 112 with UseMipMaps

Atlas Texture: Baseline > Test

This shows DynDOLOD's Lanczos filter and alpha-to-coverage do an excellent job compared to the full texture's mipmap, but somehow the mipmaps of the atlas texture end up very different, as seen in the next screenshots.

In-game mid-morning: Baseline > Test

In-game afternoon: Baseline > Test

This is beautiful, I'm so happy. Thank you very much for your assistance and for bearing with me.

Notes:

• I reverted the Alpha threshold to 112 for the UseMipMaps version, because with 224 the atlas texture and mipmaps were completely decimated, there was almost nothing left  I need to tweak the alpha threshold again to correct the lushiness of the 3D LOD models and match it with the full models.
• I tried to rename the textures paths and filenames in the 3D LOD models in order to make UseMipMaps work, but it didn't work as DynDOLOD requires the same paths and filenames in both the full and 3D LOD models. I didn't want to edit the vanilla meshes, so I made sure to add UseMipMaps to all the 3D LOD models that use treepineforestbranchcomp.dds (treepineforest*passthru_lod.nif + treepineforestdead*passthru_lod.nif).
• The branches of the 3D LOD models still look rather flat, but I understand this is due to the LOD's binary alpha. There's nothing that can be done.
• Suggestion for possible future usability improvement: Since the suitability of mipmaps for use by 3D LOD models is an intrinsic property of the full texture, and does not depend on the mesh, it would make sense to specify UseMipMaps separately for specific textures (e.g. in a config file) rather than in each 3D LOD mesh.

Thanks for reading.

Just to be clear, you are talking about TexGen_SSE.ini settings for UseMipMaps and TreeMSAlphaThreshold, correct?

If so, I'd like @sheson to confirm that these settings pertain to BOTH Level# and Billboard# DynDOLOD mesh textures. I had thought that these only pertained to Billboard# mesh textures.

Perhaps this discussion is about using UseMipMaps in the string name of the crown BsTriShape of the LOD models?

In that case, I want to confirm that the DynDOLOD treatment pertains to BOTH Level# and Billboard# DynDOLOD mesh textures, regardless.

Going slightly off topic from this discussion but on-topic for DynDOLOD: It would be extremely helpful if there were a handy reference for all NIF strings keywords (e.g., ShereNormals, UseMipMaps, etc.) and exactly the NIF node types to which they pertain (and I assume only the LOD models are considered by DynDOLOD and the full model strings have no bearing on LOD treatment). I know there are more, but we lack a comprehensive listing in the documentation AFAIK.

[Mousetick]

1 hour ago, z929669 said:

Just to be clear, you are talking about TexGen_SSE.ini settings for UseMipMaps and TreeMSAlphaThreshold, correct?

No, I'm talking about UseMipMaps in the name of the BSTriShape of the crown of the 3D tree LOD mesh, and about the Threshold value of the NiAlphaProperty of that same BSTriShape. The past discussion is solely about 3D tree LOD models and their use of full model textures, TexGen and billboards are not involved at all.

1 hour ago, z929669 said:

Perhaps this discussion is about using UseMipMaps in the string name of the crown BsTriShape of the LOD models?

Correct.

[sheson]

1 hour ago, z929669 said:

Just to be clear, you are talking about TexGen_SSE.ini settings for UseMipMaps and TreeMSAlphaThreshold, correct?

No. https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-148/?do=findComment&comment=274396

1 hour ago, z929669 said:

If so, I'd like @sheson to confirm that these settings pertain to BOTH Level# and Billboard# DynDOLOD mesh textures. I had thought that these only pertained to Billboard# mesh textures.

TexGen has nothing to do with object LOD level options of DynDOLOD. TexGen generates textures (and text files).
I have no idea what "mesh textures" means. Meshes are 3D models and textures are images.

The TexGen UseMipmaps INI setting does exactly what the explanations above it says it does:
; 1 = use mipmaps of full textures for rendering, 0 = don't use mipmaps
Since there is no condition/limitation mentioned it applies to all TexGen options that are rendered.

1 hour ago, z929669 said:

Perhaps this discussion is about using UseMipMaps in the string name of the crown BsTriShape of the LOD models?

Yes. https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-148/?do=findComment&comment=274396

1 hour ago, z929669 said:

In that case, I want to confirm that the DynDOLOD treatment pertains to BOTH Level# and Billboard# DynDOLOD mesh textures, regardless.

Billboard textures (that includes trunks) generated by TexGen do not have mipmaps, so they typically have to be generated by DynDOLOD when being added to a texture atlas regardless of any UseMipMaps being set in any LOD model.
Billboard meshes like ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_flat_*_lod.nif define place holder textures, so adding UseMipMaps to them will not have any effects for any texture.

1 hour ago, z929669 said:

Going slightly off topic from this discussion but on-topic for DynDOLOD: It would be extremely helpful if there were a handy reference for all NIF strings keywords (e.g., ShereNormals, UseMipMaps, etc.) and exactly the NIF node types to which they pertain (and I assume only the LOD models are considered by DynDOLOD and the full model strings have no bearing on LOD treatment). I know there are more, but we lack a comprehensive listing in the documentation AFAIK.

https://dyndolod.info/Help/3D-Tree-LOD-Model#Shape-Names

Shape name = 3D Name https://www.creationkit.com/index.php?title=Model_Data
As explained by https://dyndolod.info/Help/3D-Tree-LOD-Model "... to the BSTriShape/NiTriShape name"
The filename of models or what they depict is irrelevant.

[z929669]

4 hours ago, sheson said:

No. https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-148/?do=findComment&comment=274396

TexGen has nothing to do with object LOD level options of DynDOLOD. TexGen generates textures (and text files).
I have no idea what "mesh textures" means. Meshes are 3D models and textures are images.

The TexGen UseMipmaps INI setting does exactly what the explanations above it says it does:
; 1 = use mipmaps of full textures for rendering, 0 = don't use mipmaps
Since there is no condition/limitation mentioned it applies to all TexGen options that are rendered.

Yes. https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-148/?do=findComment&comment=274396

Billboard textures (that includes trunks) generated by TexGen do not have mipmaps, so they typically have to be generated by DynDOLOD when being added to a texture atlas regardless of any UseMipMaps being set in any LOD model.
Billboard meshes like ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_flat_*_lod.nif define place holder textures, so adding UseMipMaps to them will not have any effects for any texture.

https://dyndolod.info/Help/3D-Tree-LOD-Model#Shape-Names

Shape name = 3D Name https://www.creationkit.com/index.php?title=Model_Data
As explained by https://dyndolod.info/Help/3D-Tree-LOD-Model "... to the BSTriShape/NiTriShape name"
The filename of models or what they depict is irrelevant.

"mesh textures" was just bad wording. I copied it from my first use of it along with other text copied in my second use of it (because I avoid typing if I can re-use something already typed). What I was attempting to convey is that I've never noticed a difference with the TexGen_SSE.ini settings for UseMipMaps and TreeMSAlphaThreshold on anything but Billboard# "2D" 3D LOD trees in game. If these settings can also thin out (or 'blobbify') Ultra Level# LOD trees, I haven't noticed. If these two settings can impact the final result of Level# tree LOD, then they could potentially skew the results of the shape-name addition (UseMipMaps) and the NiAlphaProperty change, depending on a number of factors, I would guess.

Regarding the shape names ... my bad. I haven't scanned the documentation (or at least that piece of it) since you added this info ... or I just totally forgot about it. Either one is very possible. Regardless, I won't forget going forward so thanks a ton for including it whenever it was added

[sheson]

4 hours ago, z929669 said:

"mesh textures" was just bad wording. I copied it from my first use of it along with other text copied in my second use of it (because I avoid typing if I can re-use something already typed). What I was attempting to convey is that I've never noticed a difference with the TexGen_SSE.ini settings for UseMipMaps and TreeMSAlphaThreshold on anything but Billboard# "2D" 3D LOD trees in game. If these settings can also thin out (or 'blobbify') Ultra Level# LOD trees, I haven't noticed. If these two settings can impact the final result of Level# tree LOD, then they could potentially skew the results of the shape-name addition (UseMipMaps) and the NiAlphaProperty change, depending on a number of factors, I would guess.

Regarding the shape names ... my bad. I haven't scanned the documentation (or at least that piece of it) since you added this info ... or I just totally forgot about it. Either one is very possible. Regardless, I won't forget going forward so thanks a ton for including it whenever it was added

As already explained, the TexGen INI settings apply to what TexGen does, stitching of textures or rendering textures from full models.

The settings are not affecting how DynDOLOD atlas generation works.

[Yakisumi]

[Window Title]
DynDOLOD

[Main Instruction]
Error: Load order FileID [20] can not be mapped to file FileID for file "DynDOLOD.esp"

[Content]

Click on this link for additional explanations and help for this message

For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum.

[OK] [Exit DynDOLOD]

[Footer]
Online Help | Support Forum | Copy message to clipboard

[sheson]

47 minutes ago, Yakisumi said:

[Window Title]
DynDOLOD

[Main Instruction]
Error: Load order FileID [20] can not be mapped to file FileID for file "DynDOLOD.esp"

[Content]

Click on this link for additional explanations and help for this message

For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum.

[OK] [Exit DynDOLOD]

[Footer]
Online Help | Support Forum | Copy message to clipboard

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log, debug log and bugreport.txt if it exists to upload when making posts.

Click on this link for additional explanations and help for this message
https://dyndolod.info/Messages/Exceptions#Load-order-FileID-can-not-be-mapped-to-file-FileID-for-file
Always use the latest version of DynDOLOD/TexGen as explained above.
This can be caused by errors in plugin. Finalize the load order and clean and error check the load order with xEdit as explained above.
This can be also a bug with the tools encountering unexpected situations. Make a report with the log, debug log and bugreport.txt as explained on the official DynDOLOD support forum.

[symjoy]

Hi, after completing STEP 2.2.0 for Skyrim Special/Anniversary Edition I have a problem with road side rock texture in winterhold.

With DynDOLOD:

Without DynDOLOD:

This is the settings in MCM:

I have all the logs from TexGen and DynDOLOD if you need. But there was no error and nothing related to this texture/mesh in the logs (I could be wrong).

I'll appreciate any help for fixing this issue.

[sheson]

20 minutes ago, symjoy said:

Hi, after completing STEP 2.2.0 for Skyrim Special/Anniversary Edition I have a problem with road side rock texture in winterhold.

With DynDOLOD:

Without DynDOLOD:

This is the settings in MCM:

I have all the logs from TexGen and DynDOLOD if you need. But there was no error and nothing related to this texture/mesh in the logs (I could be wrong).

I'll appreciate any help for fixing this issue.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug to upload when making posts.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make usefull in-game screenshots with more informative console.

This is a well known problem with 2 pass snow shaders and/or parallax. The load order was changed after generating the LOD patch. Generate a new LOD patch for the current load order.

If you have problems following a third party modding guide you should be asking question on its forum/discord etc.

[symjoy]

I think I found the problem. And no I didn't change the load order after generating SSELoadGen, TexGen and DynDOLOD (Except only disable "(TEMP) Cathedral Landscapes - xLODGen" after running SSELoadGen as per STEP instruction)

Note: I should've mention it before that I'm running MO2 under wine (8.13) on linux (Fedora 38 KDE).

Below is a chunk of DynDOLOD_SSE_Debug_log.txt

Spoiler

[1084534:48:11] [DynDOLODInit] <Debug: Start DynDOLODInit>
[1084534:48:11] [dynCheckPath] <Debug: Processing D:\Modding\Tools\DynDOLOD\>
[1084534:48:11] [LoadList] <Debug: Loading D:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_Summaries.txt>
DynDOLOD 3.0 Alpha-148 x64 - Skyrim Special Edition (SSE) (688DEA6C) starting session 2023-09-19 22:48:12

The Source Code Form of this program is subject to the terms of the Mozilla Public License, v. 2.0
If a copy of the MPL was not distributed with this file, You can obtain one at https://mozilla.org/MPL/2.0/.

The Source Code Form is available at https://github.com/TES5Edit/TES5Edit

Using Skyrim Special Edition Data Path: D:\GOG Games\Skyrim Special Edition\Data\
Using Scripts Path: D:\Modding\Tools\DynDOLOD\Edit Scripts\
Using Cache Path: D:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\Cache\DynDOLOD_SSE_
Using Temp Path: C:\users\gj86\Temp\DynDOLOD_SSE\
Using Output Path: D:\Modding\Tools\DynDOLOD\DynDOLOD_Output\
Using ini: C:\users\gj86\Documents\My Games\Skyrim Special Edition\Skyrim.ini
Using custom ini: C:\users\gj86\Documents\My Games\Skyrim Special Edition\SkyrimCustom.ini
Using save path: C:\users\gj86\Documents\My Games\Skyrim Special Edition\Saves\
Using Creation Club Content list: D:\GOG Games\Skyrim Special Edition\Skyrim.ccc
Using plugin list: C:\users\gj86\AppData\Local\Skyrim Special Edition\Plugins.txt
Warning: Could not find plugin list
Using settings file: D:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD.ini
Using language: English
Using general string encoding: ANSI Latin 1
Using translatable string encoding: ANSI Latin 1
Using VMAD string encoding: 65001 (UTF-8)
Loading active plugin list: C:\users\gj86\AppData\Local\Skyrim Special Edition\Plugins.txt

The problem is DynDOLOD is looking for Plugins.txt in wrong directory for my game version. The correct path is C:\users\gj86\AppData\Local\Skyrim Special Edition GOG\Plugins.txt

And because of missing Plugins.txt the load order is different from actual vs what DynDOLOD sees. As I'm running DynDOLOD through MO2 it sees all the data from Game Data folder but don't have the correct load order.

This led me to check SSELoadGen and TexGen log. Same issue there is well. Currently I'm re-generating all 3 (SSELoadGen, TexGen and DynDOLOD) after copying the Plugins.txt to the folder these apps are looking for. I think this should fix the issue as I didn't deviate from the STEP 2.2.0 guidelines.

Thanks for mentioning the loadorder, otherwise it would've never occur to me to check.

Thanks for your help.

Edited September 22, 2023 by symjoy

[sheson]

1 hour ago, symjoy said:

I think I found the problem. And no I didn't change the load order after generating SSELoadGen, TexGen and DynDOLOD (Except only disable "(TEMP) Cathedral Landscapes - xLODGen" after running SSELoadGen as per STEP instruction)

Note: I should've mention it before that I'm running MO2 under wine (8.13) on linux (Fedora 38 KDE).

Below is a chunk of DynDOLOD_SSE_Debug_log.txt

  Hide contents

[1084534:48:11] [DynDOLODInit] <Debug: Start DynDOLODInit>
[1084534:48:11] [dynCheckPath] <Debug: Processing D:\Modding\Tools\DynDOLOD\>
[1084534:48:11] [LoadList] <Debug: Loading D:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_Summaries.txt>
DynDOLOD 3.0 Alpha-148 x64 - Skyrim Special Edition (SSE) (688DEA6C) starting session 2023-09-19 22:48:12

The Source Code Form of this program is subject to the terms of the Mozilla Public License, v. 2.0
If a copy of the MPL was not distributed with this file, You can obtain one at https://mozilla.org/MPL/2.0/.

The Source Code Form is available at https://github.com/TES5Edit/TES5Edit

Using Skyrim Special Edition Data Path: D:\GOG Games\Skyrim Special Edition\Data\
Using Scripts Path: D:\Modding\Tools\DynDOLOD\Edit Scripts\
Using Cache Path: D:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\Cache\DynDOLOD_SSE_
Using Temp Path: C:\users\gj86\Temp\DynDOLOD_SSE\
Using Output Path: D:\Modding\Tools\DynDOLOD\DynDOLOD_Output\
Using ini: C:\users\gj86\Documents\My Games\Skyrim Special Edition\Skyrim.ini
Using custom ini: C:\users\gj86\Documents\My Games\Skyrim Special Edition\SkyrimCustom.ini
Using save path: C:\users\gj86\Documents\My Games\Skyrim Special Edition\Saves\
Using Creation Club Content list: D:\GOG Games\Skyrim Special Edition\Skyrim.ccc
Using plugin list: C:\users\gj86\AppData\Local\Skyrim Special Edition\Plugins.txt
Warning: Could not find plugin list
Using settings file: D:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD.ini
Using language: English
Using general string encoding: ANSI Latin 1
Using translatable string encoding: ANSI Latin 1
Using VMAD string encoding: 65001 (UTF-8)
Loading active plugin list: C:\users\gj86\AppData\Local\Skyrim Special Edition\Plugins.txt

The problem is DynDOLOD is looking for Plugins.txt in wrong directory for my game version. The correct path is C:\users\gj86\AppData\Local\Skyrim Special Edition GOG\Plugins.txt

And because of missing Plugins.txt the load order is different from actual vs what DynDOLOD sees. As I'm running DynDOLOD through MO2 it sees all the data from Game Data folder but don't have the correct load order.

This led me to check SSELoadGen and TexGen log. Same issue there is well. Currently I'm re-generating all 3 (SSELoadGen, TexGen and DynDOLOD) after copying the Plugins.txt to the folder these apps are looking for. I think this should fix the issue as I didn't deviate from the STEP 2.2.0 guidelines.

Thanks for mentioning the loadorder, otherwise it would've never occur to me to check.

Thanks for your help.

From the first post:
Questions or help request can only be answered for the information provided.

From https://stepmodifications.org/forum/topic/13451-xlodgen-terrain-lod-beta-101-for-fnv-fo3-fo4-fo4vr-tes5-sse-tes5vr-enderal-enderalse/ or the Readme.txt included in the download archive or https://dyndolod.info/Help/xLODGen#Installation:
If required, use command line arguments to set the paths to certain directories and files. For example:
-m:"c:\Users\[USERNAME]\Documents\My Games\Skyrim Special Edition GOG\"
-p:"c:\Users\[USERNAME]\AppData\Local\Skyrim Special Edition GOG\plugins.txt"
-d:"c:\GOG Games\Skyrim Special Edition GOG\Data\"

https://dyndolod.info/#Skyrim-Special-Edition-GOG-Skyrim-Anniversary-Edition-GOG or https://dyndolod.info/Mods/Skyrim-Special-Edition-GOG-Skyrim-Anniversary-Edition-GOG
Use the -m, -p and -d command line arguments to set the INI, plugins.txt and Data paths when starting the tools. For example:
-m:"c:\Users\[USERNAME]\Documents\My Games\Skyrim Special Edition GOG\"
-p:"c:\Users\[USERNAME]\AppData\Local\Skyrim Special Edition GOG\plugins.txt"
-d:"c:\GOG Games\Skyrim Special Edition GOG\Data\"

https://dyndolod.info/Help/Command-Line-Argument

You already needed to do this for xEdit which you must have used plenty of times before generating LOD with xLODGen or DynDOLOD.