sheson

Do not post obvious nonsense from "AI" that does not have any "I". Read the first post and https://dyndolod.info/Official-DynDOLOD-Support-Forum how to make a useful post in case you have a problem that requires help. Report the actual problem or error message without making unverified assumptions or asking leading questions. LOD billboards are a tree LOD resource. See https://dyndolod.info/Help/Tree-Grass-LOD-Billboards DynDOLOD does add tree LOD for something that is not a "tree". DynDOLOD never replaces full models with LOD billboards. DynDOLOD does not convert everything that looks like "static clutter" to LOD - whatever "static clutter" is supposed to mean. How DynDOLOD actually works is explained in the documentation. In this case, DynDOLOD does, what the mesh rule config file shipping with the mod instructs DynDOLOD to do: Replace the crow references that only show in the active cells with dynamic LOD reference so that the crows show further up to the far grid distance. The dynamic LOD references use the full models. The scripts in the mod enable/disable markers and not the crow references. The crow references or their dynamic LOD replacements use the state of the unchanged markers to determine if crows should show or not. When installing the mod properly with its requirements and then follow the instructions of DynDOLOD, the crows show further away then they do without DynDOLOD. If you remove the mesh rules config file that is shipping with the mod, then DynDOLOD would do nothing to the crow references. They will just show in the active cells. I suggest to read the description/sticky comments of the mod. It requires DynDOLOD 3 for the crows to have LOD. If you have problems with that, then report the problem as explained instead of this nonsense.

Unfortunately there is no bugreport.txt in the DynDOLOD Logs.zip You changed Debug=1 instead of adding GLDebug=1 in C:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini The driver version is reported as 582.16. Is there no newer for you card? I doubt it makes a difference, but update to 591.74 if possible just to be sure if nothing else speaks against it. Download the latest test version from https://dyndolod.info/Downloads/Test-Versions Set Debug=0 and add GLDebug=1 under [DynDOLOD] in C:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini Delete all old logs and old bugreport.txt. Then run the test version and upload new logs and bugreport.txt (if it exists).

See https://dyndolod.info/Help/Texture-Resolution. The higher the texture resolution, the more mipmap levels exist. The hardware, driver and settings can control antialiasing techniques, their strength or quality, mipmap bias and whatnot that all affect image quality. The NIF sets the SphereNormals shape name to change the direction of the normal vectors. Basically, the planes receive more light from above than the actual direction it faces. See https://dyndolod.info/Help/3D-Tree-LOD-Model#Shape-Names and the last paragraph and image of https://dyndolod.info/Help/Ultra-Tree-LOD#Internal-Billboards-and-External-Billboards

The provided links both show SSELODGen being started without any generation log messages. SSELODGen, which is typically used to generate terrain LOD, is not relevant in this context. Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log, debug log and bugreport.txt (if it exists) to upload when making posts. The error message should have a link Click on this link for additional explanations and help for this message of the message as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages that opens https://dyndolod.info/Messages/Exceptions and scroll to the OpenGL section: This can be also a bug with the tools encountering unexpected situations. Add GLDebug=1 under [TexGen|DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\[TexGen|DynDOLOD]_[GAME MODE].INI and make a report with the log, debug log and bugreport.txt as explained on the official DynDOLOD support forum. Delete old logs. Add GLDebug=1 to DynDOLOD_SSE.ini, then run again and also upload the new log, debug and bugreport.txt please.

Grass LOD generation is not affected by any worldspace/weather settings and always the same. Not sure how grass LOD is different in the 2 screenshots. Next time use tfc to get closer to LOD. Great. For future posterity, this is with ENB and complex grasses right? By tree tweak you mean changing the AlphaFactor to 0.5 or something else?

I requested the files to verify if the result is matches what was reported about the assets in the logs. There are 2 versions of spruce03_summer.dds on texture atlas, one with alpha channel unchanged for the LOD models that still set a threshold of 110 (left) and one with the alpha channel adjusted for the LOD models that set a threshold of 1 (right). As you can see the right image is "thicker". Here is how it looks 2 mipmap levels smaller: The difference becomes less obvious. However, it is also not really thin either way. You could try to increase the AlphaFactor in the L:\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini. See what happens if you use 0.5 for example. Otherwise you could create a custom LOD texture in your preferred image program and update the LOD models to use it directly. Though before doing that you might want to experiment using the full texture by adding either "usemipmaps" or "noatlas" to the Name of the BSTriShape "crown" - for example "crown noatlas" to see if it fades better without any alpha adjustment. See https://dyndolod.info/Help/3D-Tree-LOD-Model#Shape-Names I also colored the two texture red and green in the atlas texture to verify that the BTO in fact uses them both depending on the different LOD models: To summarize, not all 3D tree LOD have a threshold of 1. The threshold of 1 causes the alpha channel of the texture to be adjusted and to be added to the texture atlas and used. It might simply be not thick enough for your taste for this particular texture. Make sure that the output is really used in the game and not overwritten or wrong paths etc. https://dyndolod.info/Help/Grass-LOD#Settings When using complex grass and the side facing away from the light direction is too dark it can be brightened with the backlightmask. In the ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini set ComplexGrassBillboard=5 and set ComplexGrassBacklightMask to a value like 25, which means 25% of the light is applied to the side facing away from the light source. If the result is too dark, raise the value. If the result is too bright, lower the value. If brightness of the grass billboard sides is fine when the sun is low, then backlighting must be working. Otherwise the grass billboard side facing the sun will be bright and its opposite side facing the other way would be too dark. So you would end up with a mix of bright and dark planes instead of a more uniform brightness. If you do not see any differences in the game between 0 and 100, then the NIF with the backlight is not used - no complex grass billboards or the output is not active or being overwritten. See this post https://stepmodifications.org/forum/topic/19903-dyndolod-300-alpha-198/page/717/#findComment-288563 how to verify backlighting is set/used. This is the users follow up post: https://stepmodifications.org/forum/topic/19903-dyndolod-300-alpha-198/page/719/#findComment-288593 Since you set ComplexGrassBillboard=5, you could also test if this ..\DynDOLOD\Edit Scripts\DynDOLOD\ DynDOLOD_flat_4x2alt2_lod.nif works better with changing sun positions. Use expert mode to just Execute LODGen again to update object LOD meshes. See https://dyndolod.info/Help/Grass-LOD#Updating

The useful screenshots with more informative console show 3 different tree base record. The uploaded logs reports this: xx01516E, spruce_forest_bigest01_summer.nif, uses unmodified spruce_forest_bigest01_summer_1b80523fpassthru_lod.nif with alpha threshold of 110 xx357AAC, spruce_common_big02_summer.nif, seems to use a modified version of spruce_common_big02_summer_lod_0.nif, it seems to set an alpha threshold of 1 xx408AC0, pruce_forest_slim01_summer.nif, uses unmodified spruce_forest_slim01_summer_16985565passthru_lod.nif with alpha threshold of 110 All of these trees seem to use the same spruce03_summer.dds for the crown. The object LOD atlas should have one version of spruce03_summer.dds adjusted to alpha threshold 1 and a second adjusted to 110. Also upload L:\DynDOLOD\Edit Scripts\Export\LODGen_SSE_ObjectAtlasMap_Tamriel.lst and LODGen_SSE_ObjectAtlasMap_Tamriel.txt From the generated output, upload ..\meshes\Terrain\Tamriel\Objects\Tamriel.4.4.-8.bto, ..\textures\DynDOLOD\LOD\DynDOLOD_Tamriel_Alpha.dds and DynDOLOD_Tamriel_Alpha_n.dds

See https://dyndolod.info/Changelog which lists the changes between versions. https://dyndolod.info/Official-DynDOLOD-Support-Forum Report the actual problem or error message without making unverified assumptions or asking leading questions. This script should work https://www.afkmods.com/index.php?/topic/5155-fnvedit-editing-alpha-flags-in-nif-files/#findComment-171206

Disabling something is a troubleshooting step and not really a fix. Whatever mod(s) replace tree full models should also include updated 3D tree LOD models with matching CRC32 in their filenames so everything works as intended.

Moved to the DynDOLOD 3 Alpha thread. Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log, debug log and bugreport.txt (if it exists) to upload when making posts. Use the task manager to find and close any hidden TexGen, DynDOLOD, LODGen, Texconv, mod manager or other processes that might access files. Try rebooting the OS. Could be Antvir etc. or similar blocking access, try adding exceptions

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs wich which DynDOLOD debug log to also upload. Use the Copy message to clipboard link to copy/paste the text of the message instead of posting a screenshot as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text. It also explains that the debug log contains the selected settings and thus not to post screenshots of the tools. You seem to believe that there is a problem with the SKSE co-save, maybe because of how SKSE or PapyrusUtil works. How does data being stored into it by DynDOLOD via PapyrusUtil affect its healthiness or its speed? What speeds exactly? Is seems you believe there is some kind of problem with PapyrusUtil or SKSE? Why do you believe storing/reading data into the co-save is somehow deterioration over years? If you install DynDOLOD DLL and Scripts, then dynamic LOD does not use PapyrusUtil and the SKSE co-save to store data. So any actual or imagined problems with the co-save can be avoided while still being able to use dynamic LOD. z-figting between different LOD types are an inherit game engine issue. There might be INI settings that can lessen its effects. To get rid of it, use mods that add more of the mountain object meshes to cover up the areas where terrain and object LOD intersect.

Object and tree LOD are always static. Not generating dynamic LOD simply means no additional LODs. If no dynamic LOD is generated there is not need for the DynDOLOD SkyUI MCM. You are using DynDOLOD 2.x which hasn't been updated in years. Consider using DynDOLOD 3.x Alpha. It should have even better matching tree and object LODs. Dynamic LOD works the same in TES5 in principle with PapyrusUtil or DynDOLOD DLL. The first generation done on 2026-01-03 generated dynamic LOD: Setting up 13662 cells with 699 active cells for 835 dynamic LOD objects for DynDOLOD Setting up 3654 cells with 27 active cells for 89 dynamic LOD objects for DynDOLOD Setting up 1020 cells with 10 active cells for 44 dynamic LOD objects for DynDOLOD etc. While there are over 10,000s of cells, there only seems to be 1,000s dynamic LOD objects. The last session done 2026-01-08 at 13:30:25 was done without dynamic LOD being generated. Your reason to not generate dynamic LOD still seems to be irrational to me, sine you did not report any actual issues one way or the other. You just looked at a number that shows the size of a save file, which only seems to show that everything works as one would expect for now.

Requested log files were not provided. The log files collects log and debug messages required to answer questions or make factual based statements about what was generated or not.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug to upload when making posts. You seem to be asking how a post processing feature of a third party mod is supposed to look in the game. You will have to ask their creator(s) or check on their comments, forum or discord with other users. https://dyndolod.info/Mods/Community-Shaders#Terrain-Shadows ... (see Terrain-Heightmap-Readme.txt included in its download archive) ... Terrain-Heightmap-Readme.txt The texture is a direct 1:1 export of the plugin(s) landscape vertex height data for a cell: A cell has 32 x 32 height data points. For example a worldspace that is -64 to +63 = 128 cells wide, results in 32 x 128 = 4096 pixels. The resolution of 32x32 data points (pixels) per cells does not increase when adding object LOD height to the terrain height map. The heightmap has very, very low resolution compared to other things. You can use tb in console to show cell borders. Then mentally divide the space between the yellow by 32 to get an idea.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts. As explained above, it is dynamic LOD which stores state data either in the co-save if PapyrusUtil is used or on the game save if DynDOLOD DLL is used. If the co-save increases when exploring more and more of the game, it not because of the DynDOLOD scripts, since they are not really running beyond being able to change game settings via the SkyUI MCM.

Yes, somehow the version number in the exe did not get updated to 198. You know you have the currently latest version if the DynDOLODx64.exe timestamp is January 5th instead of the 3rd (could be one day different due to timezone). If you like, you can download the latest test version from https://dyndolod.info/Downloads/Test-Versions. It currently reports as 198. Delete all old logs.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen log and debug log to upload when making posts. Use the Copy message to clipboard link to copy/paste the text of the error message instead of a screenshot as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text Record [STAT:00000001] in file Skyrim.esm is being overridden by record [REFR:00000001] in file FlyingCrowsSSE.esp. Click the link Click on this link for additional explanations and help for this message as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages to open https://dyndolod.info/Messages/Record-Is-Being-Overridden: Starting with runtime version 1.6.1130, plugins with the version 1.71 can use form ID in the range 0x000 to 0x800. If the reported form ID is less than 0x800, use xEdit to make sure the plugin defines version 1.71. Install Backported Extended ESL Support to use such plugins with older runtime versions or Skyrim VR ESL Support for Skyrim VR. Install the Skyrim VR ESL support. The unofficial patch works the same regardless of the vanilla game plugins being cleaned or not. There will be many game/quests issues without it. I suggest to follow a modern modding guide that explains how to setup Skyrim VR properly with the current Skyrim SE/AE game file if you want to use mods made for Skyrim SE/AE.

You do not have to check the Dynamic LOD ceckbox in the https://dyndolod.info/Help/Advanced-Mode. https://dyndolod.info/Help/Dynamic-LOD Optional means it does not have to be generated.

Remember that the full model of vanilla references that are overwritten by a non ESM flagged plugin and any new reference typically do not load outside the active cells as they stop or can not be large references. So the transition from full to LOD model or nothing if no LOD model exists happens closer than in the vanilla game. Since large reference usually showing further out, some things not having LOD models is not that obvious. You could also test how things look in the vanilla game with large refs disabled. See https://dyndolod.info/Help/Large-References Use the base record form IDs to look up what LOD models if any where found for that particular full model in C:\Games\Tools\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt Not finding a base record form id means no LOD models were found. Here is the quick run down: All Markarth LOD models included in DynDOLOD Resources are derived from the combined vanilla LOD models. They use textures\lod\MrkBuildingsLOD03.dds for the rock texture, with a rendered LOD texture that TexGen generates. If it was rendered for the current load order and still seems to dark, you could edit ..\DynDOLOD\Edit Scripts\DynDOLOD\Render\Skyrim\Objects\lod\mrkbuildingslod03.nif in NifSkope and adjust the 4 vertex colors entries for block 5 to make it a bit ligher. Then run TexGen and DynDOLOD in expert mode to "Rebuild Atlas". See https://dyndolod.info/Help/Expert-Mode riften_1dyn.png, 000F795B, no LOD model exists for RTPlayerHouseDeck01.nif. riften_2dyn.png and riften_3_dyn.png, FE015844, no LOD model exists for sr_rtcanallock01.nif, or the vanilla rtcanallock01.nif. riften_4.png, riften_5.png, 000EF2FE, 000EF2DF the LOD models included in DynDOLOD Resources for rtcanalsbridge* inside the city only have the walkway without the railing. They were derived from the vanilla LOD models like rtcanalsl01_lod.nif, rtcanalsl02_lod.nif etc. for example that combine them into a single mesh. riften_6.png, 000F0EC2, no LOD model exists for RTSnowShodDeck01.nif. In the vanilla game, the are no upper decks in the Tamriel worldspace version of Riften IIRC. solitude.png, FE0159EF, the "LOD" model srexsolitudegatehouse_lod4.nif and srexsolitudegatehouse_lod8.nif shipping with SR Exterior Cities. To be frank, whoever made them does not really know how to make LOD models. I check how copying the (already renamed) vanilla LOD model meshes\LOD\Solitude\new_smaingate_sr_lod.nif from DynDOLOD Resources to srexsolitudegatehouse_lod4.nif and srexsolitudegatehouse_lod8.nif to replace it looks in the game. Or use the full model for LOD Level 4. In case of missing LOD models, you could add a mesh mask rule to use the full model for LOD. See https://dyndolod.info/Help/Mesh-Mask-Reference-Rules I suggest to not worry too much about how LOD looks close up or when using tcl or tfc with camera positions/angles that are typically not reached when playing the game.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log, debug log and bugreport.txt to upload when making posts. https://dyndolod.info/Official-DynDOLOD-Support-Forum Disabling something is typically a troubleshooting step and not a fix, especially when trying to circumvent errors or problems. Research the issue and report problems to the official DynDOLOD support forum, so they can be properly troubleshooted and fixed, whatever their reasons are. The error message has a link Click on this link for additional explanations and help for this message as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages that opens https://dyndolod.info/Messages/Exceptions. Scroll to the OpenGL section and read it, especially: Always use the latest version of DynDOLOD/TexGen as explained above. This can be also a bug with the tools encountering unexpected situations. Add GLDebug=1 under [TexGen|DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\[TexGen|DynDOLOD]_[GAME MODE].INI and make a report with the log, debug log and bugreport.txt as explained on the official DynDOLOD support forum. https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-the-Latest-Versions and https://dyndolod.info/Changelog: Version 3.00 Alpha 198 DynDOLOD.exe - added a work-around for an invalid operation with AMD drivers If you are still on an older version, update to the latest version. If there are still problems or errors then, copy and paste the entire error message by using the Copy message to clipboard link as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text and upload the logs as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload. Dynamic LOD using PapyrusUtil stores state data for every encountered cell and dynamic LOD object in the co-save. Dynamic LOD using DynDOLOD stores state data for every encountered cell and dynamic LOD object in the save. Those are the mentioned script instances. The data can be removed by following the https://dyndolod.info/Help/Clean-Save. There are probably several 1,000s cells and maybe 10,000 dynamic LOD objects depending on mods, settings etc. I would not be surprised if each requires a couple hundreds bytes, more for each cell with dynamic LOD objects. Once every cell and dynamic LOD object has been encountered once, it should not increase anymore as all the data/instances have been created. Save bloat is exponential growth, where in a matter of hours it reaches dozens if not hundreds of MBs. If you already worry about 71kb and 1MB after several days, reaching the typical expected file sizes of several MBs for the co-save and 10, 20 MB or more for the game save after playing for weeks/months is probably going to give you a heat attack. DynDOLOD and its scripts have been developed, improved and scrutinized for over a decade. They never used any of the techniques that cause save bloat. DynDOLOD is used by millions of people and is part of hundreds of modding guides. You can search the 10s of thousands of feedback posts, supports queries and troubleshooting to actual fix queries.

The item not found error was due to the BSHeartland worldspace not being commented in the DynDOLOD_SSE_worldspace_ignore.txt. It happened also in every older version. The atlas textures not being generated was a regression due to updates to rendering processes.

Please also upload useful screenshots of the full models with more informative console so we know the reference and base record form IDs. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots

I uploaded a new test version for you to try. It should generate the texture atlasses of the combined worldspaces again. It should always work now, regardless of changing DynDOLOD_SSE_worldspace_ignore.txt or not. Please report results, upload new logs if there still is a problem.

Requested information like logs, a copy of error message were not provided. The message most likely mentioned bloatware installed with graphics drivers. I suggest to carefully read the entire message and clicks its links to further help and read that as well. See https://dyndolod.info/Official-DynDOLOD-Support-Forum. All executables in the DynDOLOD are x64 versions as can be seen from their filenames. Since everything is x64, only the x64 versions of the redistributable and .NET Desktop are required as explained. Installing separate x86 versions is not required and consequently are not part of the instructions. If something in the instructions is unclear, then make a post with concrete feedback, information about it. See https://dyndolod.info#DynDOLOD-3-Alpha. So far what I gathered is that MS changed the name of the latest Redistributable recently and thus the instruction were outdated. That has been updated in the meantime. There are no bots posting on this forum.