sheson

From the log that was uploaded: Fatal: Error loading plugin list: <EDirectoryNotFoundException: The specified path was not found Moved to the appropriate thread for this error message, which can be found by searching this forum for the message as explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search Searching the official DynDOLOD website finds https://dyndolod.info/Messages/Windows-Registry-Key which explains how to fix the cause of the error by updating the registry information by running the game launcher once. It also has a link to https://dyndolod.info/Help/Command-Line-Argument, which also explains: Since TexGen/DynDOLOD are based on xEdit, they support the same Command Line Switches of xEdit.

Own Emit is removed because the color is black. Vertex Alpha is not properly supported by LOD - it becomes transparency with a threshold of 128. Env map is not suported by LOD.

Report if generating LOD with this test version changes anything https://mega.nz/file/oAAilC5D#WQ5ctzD9xwd8B4FjSYWsHYpEo3BQ2wmntk3Y5BLNask

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts. As explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text, use the Copy message to clipboard link to copy and paste the message. As explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages, read the message and its explanation. The message states a fact: The plugin mentioned in the message already exists in the data folder but is not activated in the used plugins.txt.

Without logs it is unclear if the settings have been applied correctly or what is happening. If Texconv does not finish, then it means Texconv hangs and not that TexGen hangs.

Will be fixed next DynDOLOD Resources SE version.

From MO2 right window data tab find the billboards and make sure they are from TexGen output and upload them: ..\Textures\terrain\lodgen\skyrim.esm\reachtree02_000b8a74_1.dds ..\Textures\terrain\lodgen\skyrim.esm\reachtree02_000b8a74_2.dds from DynDOLOD output upload ..\Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds Also upload C:\Modding\Modlist Wabba\Tools\DynDOLOD 3 Alpha 128\Edit Scripts\Export\LODGen_SSE_ObjectAtlasMap_Tamriel.txt

In programming x *= y is shorthand for new-x = old-x * y and */ is always done before +-, so 1 + x * y is the same as 1 + (x * y) for mipmapl level 1 it would be: new-alpha-pixel = old-alpha-pixel * 1 + (1 * 0.25), so new-alpha-pixel = old-alpha-pixel * 1.25 Since I do not use NTT, I can not say what this value means for texture/mipmap creation. The alpha threshold defined in a NIF is used by the shader to determine if a pixel shows or not when it is set to do alpha testing. The NiAlphaProperty can also change the function (less than, greater than etc.) or it can change it from alpha testing to blending. You can play around with these things in NifSkope. The default threshold of object LOD is 128 and it always does alpha testing with greater than. If you set an alpha threshold in the LOD model of 129, then the alpha channel of the texture that is added to the atlas is adjusted to reflect that difference. For consistency it is best to set all full and LOD NIFs to an alpha threshold of 128 so there is no need to adjust textures. Then do whatever you need to in the texture tools so its alpha/transparency/mipmaps looks like whatever you want them to.

As suspected the bugreport also points to a decompression problem. It might be a problem with the last BA2 that contains Textures\Architecture\Unique\WaterTowerDetails01_s.dds You can check which BA2 with the xEdit Asset Browser (CTRL + F3)

DynDOLOD uses Texconv to convert compression formats only. The formula for scaled alpha coverage for a mipmap is alpha *= 1 + MipMapLevel * AlphaFactor. MipMapLevel is 0 for the largest mipmap, so no change. DynDOLOD_SSE.INI sets AlphaFactor=0.25 because each mipmap is 1/4 of the resolution of the one before it. A texture has an alpha channel. The game uses alpha testing, the alpha test threshold value is used together with the alpha test function (greater than) to determine if a pixel shows or not. So, whenever the alpha value of a pixel is greater than the default 128 threshold, it is opaque. The best value for the NiAlphaProperty of full/LOD models would be 128, because that matches the hardcoded LOD threshold and no adjustment of the texture alpha channel is required if it is added to the texture atlas. So I assume the alpha channel of the texture should probably be made with the default threshold of > 128 (0.50196) in mind.

Also upload the normal TexGen log and the bugreport.txt if it exists. "data error" looks like an error message from the zlib decompression, so there might be a problem with a BA2 archive.

Checking the source code of Texconv it is value * 255 + 0.5 so 0.5 * 255 + 0.5 = 128. Shaders typically do not switch between mipmaps but blend/filter.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which debug log to also upload when making posts. It is unclear what TexGen_SSE.INI you actually tried. The debug log contains that information. https://dyndolod.info/FAQ#TexGen-DynDOLOD-stuck-while-creating-textures BC7 uses Texconv to convert the compression, while BC3 does not. So most likely TexGen is waiting on a stuck Texconv.

Unfortunately the logs archive does not contain the log and debug log from DynDOLOD but the ones from TexGen. See the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload.

Based on that information I doublechecked that the source the texture and its mipmaps are used as is. The problem is the original source texture is being replaced by a full texture with mipmaps that do not have alpha-to -coverage. While the full model fades into nothingness until it switches to LOD, the LOD has a texture that doesn't. This can quickly be mitigated by adjusting the alpha threshold of the LOD model, so that the two texture roughly match when they switch, with is not a constant distance/mipmap or with more work by using the same texture unmodified texture for both. Which you achieved. You mean this? In any case, people posting about LOD related problems anywhere else but here might as well be yelling at clouds. You have problems with a full texture with bad mipmaps that do not have alpha-to-coverage. Changing full textures or its mipmaps to your satisfaction is outside my purview and somewhat off-topic for the DynDOLOD 3 Alpha test since the build-in options/features are disabled to give you full control. The mipmap fading happens with or without the texture being used for LOD.

https://dyndolod.info/Help/3D-Tree-LOD-Model Note that by default mipmaps of textures that are added to the tree LOD or object LOD texture atlas are ignored and instead are generated from the largest resolution with an alpha-to-coverage algorithm so that small details do not fade into full transparency the further away they are. Textures/mipmaps fading into full transparency typically means the mipmaps were not generated with any alpha-to-coverage. If you instructed DynDOLOD to use the mipmaps of the texture, the texture is used as is. If the threshold is the default 128, then there also is no threshold adjustment done by DynDOLOD. DynDOLOD uses its own algorithm to adjust alpha. It is based on the principle that each mipmap is 1/4 of the one before it. Texconv uses a different method. That was programmed before xLODGen/DynDOLOD needed to use Texconv because of BC5/6/7 compression - in fact I believe Texconv didn't have alpha-to-coverage function when we started using it. I tested it a bit but never achieved better results that would have warranted going through external command line program for each texture added to the atlas. I would expect a texture artist knows what programs and settings achieve the desired/best results.

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.

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.

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.

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.

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://ck.uesp.net/wiki/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.

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 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.

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

You are comparing a resize without alpha change to a resize with alpha change. https://dyndolod.info/Help/3D-Tree-LOD-Model Note that LOD only has binary alpha with a fixed threshold of 128. It does not really matter how nice an alpha channel looks when looking at a texture in program. In LOD a pixel either shows 100% or not. If mipmaps do not fade into full transparency it is because they have been generated with alpha-to-coverage. Yes, you added the term UseMipMaps to a shape name as explained by the instructions.

Lanczos in "myfilter" ..\DynDOLOD\Edit Scripts\DynDOLOD\Shaders\stitched.frag If you want to replicate/compare the mipmap generation, also change the alpha of the largest resolution and then of every mipmap that is used. https://dyndolod.info/Help/3D-Tree-LOD-Model Note that by default mipmaps of textures that are added to the tree LOD or object LOD texture atlas are ignored and instead are generated from the largest resolution with an alpha-to-coverage algorithm so that small details do not fade into full transparency the further away they are. 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. Use an unique filename for such textures, so there are no problems with other mods modifying the same vanilla filenames.