sheson

Moved to the appropriate thread for the error message. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search. Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which entire DynDOLOD log and debug log to upload when making posts. Click the link Click on this link for additional explanations and help for this message of the message as explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages to open https://dyndolod.info/Messages/Record-Is-Being-Overridden, which explains: 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. Without the logs I can not verify the CRC32 of the used plugins, so I am not sure which version of the Lux -JK'S Blue Palace patch.esp you are using and above applies or if something else is going in. Is it from Lux (patch hub) 7.0?

Thanks for letting us know it works OK .

The reported error happened with LODGen generating object LOD meshes for DLC2SolstheimWorld. <Error: LODGenx64Win.exe failed to generate object LOD for DLC2SolstheimWorld. LODGenx64Win.exe returned C0000409. Check Z:\run\media\nvme1\MO2\Tools\DynDOLOD\Logs\LODGen_SSE_DLC2SolstheimWorld_log.txt The log itself does not reveal anything. It is possible the command line window might if you get a glimpse if it. https://dyndolod.info/Messages/LODGen-Failed-To-Generate-Object-LOD and https://dyndolod.info/Help/LODGen. Do this: To restart LODGen generation for a worldspace in case there is no LODGen_[GAME MODE]_[WORLDSPACE]_log.txt or it does not contain a useful error message, start DynDOLOD in expert mode, select the desired worldspace and click Execute LODGen. Bring the LODGen command prompt window to the front to see if it prints more details to the console. If that does not give more detail, check the Windows Event Viewer for additional messages from the .Net Framework or the .NET Desktop Runtime. If the .Net 6 LODGenx64Win.exe keeps having problems, you could try making repairing/reinstalling the .NET 6 installation, or hide the LODGenx64Win.exe by renaming it, so DynDOLOD falls back to LODGenx64.exe, the .Net Framework 4.8 version.

Here is a DynDOLOD test version with the same changes https://dyndolod.info/Downloads/Test-Versions in case it has similar issues when generating textures.

Your post is the first report about this problem with Alpha-37. The latest version is Alpha-38. Always use the latest version. Replace DynDOLOD.DLL with this test version https://mega.nz/file/FQxjzSiT#UqrCBiG2blKgel0xlsBnnpsXa2thII6FymVp2_PSBJE and start the game with the existing output and repeat the fast travel steps required to cause the issue. If the issue persists with the test version, edit ..\SKSE\plugins\DynDOLOD_Data\DynDOLOD_NG_Worlds.txt in the DynDOLOD output and change debug=true and add a line underneath it: debuglevel=1 Then start the game, do the minimum steps required to reproduce the problem and upload the new DynDOLOD.log from DynDOLOD.DLL. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs

Test what happens with the latest test version https://dyndolod.info/Downloads/Test-Versions Set GLDebug=0 so it the first test doesn't take that long. If it fails run again with GLDebug=1 for more detailed logs. Upload logs either way and bugreport as well if it failed.

https://dyndolod.info/Messages/Exceptions#OpenGL 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. Run again with GLDebug=1 and upload those logs. Also upload bugreport.txt if it exists or report that it doesn't exist.

The default value of 2.2 for the sRGBGamma setting in the INIs has been changed based on user feedback from the CS Discord. https://dyndolod.info/Mods/Community-Shaders#PBR TexGen and DynDOLOD will both automatically create linear texture versions of the LOD textures for object and tree LOD in case the full model uses PBR textures. The gamma for the conversion can be adjusted by changing sRGBGamma=2.2 in ..\DynDOLOD\Edit Scripts\DynDOLOD\[TexGen|DynDOLOD]_[GAME MODE].INI. Use lower values to darken the LOD textures derived form the PBR textures. Gamma values around 1.3 have been found to work well.

This should be fixed in Alpha-196

https://dyndolod.info/Official-DynDOLOD-Support-Forum The official DynDOLOD support forum should be preferred over any other resource where only second hand knowledge is available at best. Posting about problems anywhere else usually results in wrong answers, wrong assumptions and wrong suggestions and does not really help to fix or improve the tools, procedures or documentation for everyone. https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs Do not post screenshots of the tools, unless it is about visual issues with the user interface. The used settings and options are typically documented in the debug log already. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots A useful screenshot of the full model and a screenshot of no full model and no LOD in the LOD area would have sufficed. The source of the problem is unrelated to DynDOLOD and seems to be an engine limitation where overwriting temporary references to make them persistent does not always seem to work properly. Instead of instructing to flag the original reference as neverfade/IsFullLOD - which means the object LOD Levels and the Grid settings are irrelevant, set the Reference dropdown to Unchanged (in that case change the Grid drop down to Far Full) . Then the full model is used for actual object LOD generation with the HD snow LOD shader. Which should usually be sufficient. It will require a bit more performance/resources than using the object LOD models for object LOD. If you rather want the full model to not have object LOD there are two options: 1) Set the Grid dropdown to Far Full and the object LOD levels to None, so the full models are disabled past the far grid. Will require a bit more performance/resources than object LOD. 2) Set the Grid dropdown to Neverfade and the object LOD levels to None for worse performance but showing the full model past the Far Grid. The distance of the Far Grid can be changed in the DynDOLOD SkyUI Settings page.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts. xEdit should report this error when error checking the load order before running DynDOLOD as explained in the instructions. Looking up the reference xx0A34B7 in JK's Markarth Outskirts.esp should certainly show the same unresolved error. In this case you are using a mod that requires Update.esm from 1.6. You will have to follow a modern guide that explains how to install the latest game plugins. For example https://www.nexusmods.com/skyrimspecialedition/articles/6529

This should be fixed in Alpha-38. Upload new DynDOLOD.log and crash log if there still is an issue.

You are welcome. Enjoy!

That's great. Enjoy.

Moved to the appropriate thread for the message. See posts above, for example https://stepmodifications.org/forum/topic/15567-unresolved-formid/page/14/#findComment-282011. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts. The 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/Unresolved-Form-ID, which explains: Unresolved Form ID errors signify records that try to use non-existing records in the same or master plugins. The reported form ID is unresolved, because it is missing. The message reports the record the error occurs in as 0000003C See the explanation under https://dyndolod.info/Messages/Unresolved-Form-ID#Large-Reference how to unset the xEdit "never shown" setting to show the large reference data on the worldspace records. The record xx00392A exists in Dawnguard.esm from SE/AE 1.5 and newer. Restore the vanilla plugin and only use xEdit QuickAutoClean on it.

You did not upload any assets that you referred to in your post or provided any logs, so the explanation for the cause of tint still applies: The crown/branch textures are already replaced to their new version of the patched full model. Which is the cause of the tint, sine the patch removes the third texture, which is used by the Soft_Lighting flag of the vanilla full model and its accompanying 3D LOD model. The patched version sets Rim_Lighting instead, which typically also uses the third texture at least in vanilla shaders - no idea if CS PBR shaders would make use of it. If you do not want to create a dedicated LOD model with the appropriate shader settings that does not require a 3rd texture. You could try setting the 3rd texture with PG, either to the diffuse texture or just black.dds for example. You seem to expect tools (and by proxy the tool makers) to automatically account for your mod and do extra work. Right now PG just exports CRC32s without information about any changes made to the full model. I have explained how to create dedicated LOD models that target the modified full models that are not vanilla anymore. That is the standard way at the moment. I will see what I can do about a trunk NIF that was made for specific full models to automatically use the changed texture filenames for full models changed by PG. Check if it works with the next alpha release.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post Logs which DynDOLOD log and debug log to upload when making posts. It also explains how to enable the realtime log in case the logs can not be saved and upload that instead. https://dyndolod.info/FAQ#BSOD-Blue-Screen-Of-Death BSOD, the PC crashing or turning off is a hardware, BIOS setting, OS or driver problem. For example, problems with overclocking, memory timings, cooling, unstable power supply etc. Searching the Internet for the BSOD code should help troubleshooting. Check the Windows event log for hints. Test system stability with things like prime95 and OCCT. You should really fix the actual issue with the hardware, BIOS settings or the OS. Not addressing and fixing the cause of BSOD is going down the wrong path. See https://dyndolod.info/FAQ#High-memory-usage-Out-of-memory and https://dyndolod.info/FAQ#Long-running-time-or-output-several-GB-in-file-size and reduce resource/memory usage while generating the LOD patch. This might help avoiding BSOD caused by unstable hardware etc. In case reducing memory requirements as explained in the FAQs above does not help, see https://dyndolod.info/Updating#New-or-Updated-Mods-or-Plugins: In case a new mod contains a plugin that adds new objects to a worldspace or adds a new worldspace, start DynDOLOD with the existing DynDOLOD output in the load order. The existing DynDOLOD plugins need to load after any other plugins of the same type (e.g. DynDOLOD.esm after the highest priority ESM, DynDOLOD.esp with the highest priority possible). In case Occlusion.esp exists, it needs to load after DynDOLOD.esp. Select the worldspaces affected by the plugin and generate LOD as usual. Then install the DynDOLOD output, overwriting the existing DynDOLOD output. This might not carry forward all changes made to existing worldspace or cell records made by new plugins. In that case resolve conflicts by manually forwarding conflicting records or consider generating from scratch. To combine different worldspaces in separate sessions, update existing and installed DynDOLOD output as explained above by generating different worldspaces per update run, e.g. generate one worldspace, save & exit, install, start next session with installed output, save & exit, merge install, repeat.

That Occlusion quality 3 sure taking its time. A thing to check would be the duplicated cell conflicts between WTT and Rigmor. Without having looked into that myself it might mean that Rigmor has content in the north east with which WTT might interfere with.

TexGen typically (with a few exception regarding glow maps and non alpha textures) generates LOD textures from full textures. Thus they have the lod.dds ending. DynDOLOD generates the linear versions on demand if a LOD NIF with a normal shader would otherwise end using a sRGB texture. sRGBGamma=1.0 ; 2.2 in Texgen_SSE.ini or DynDOLOD_SSE.ini is not going to work. The line should not contain a comment separated by ; it should just be: sRGBGamma=1.0 The conversion changes brightness of all color channels equally. The different looking snow01linear.dds must have been generated from a different snow01.dds at that time. Fix the last / mesh mask rule to Level0 for LOD 4 instead of Level1. Do not set anything to Level 32 unless you intent to actually generate it for the map. That should always be the case when clicking low, medium, high to populate the rules for the current load order. If not, reinstall the DynDOLOD Standalone to make the included rules files default again.

Great. That is better. I updated the test version one more time, so it defaults to RenderSingle=0 again. It might even be one or two seconds faster. Get the matching DynDOLOD test version from this post https://stepmodifications.org/forum/topic/19903-dyndolod-300-alpha-194/page/700/#findComment-287548

Moved to the DynDOLOD 3 Alpha thread. Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which entire TexGen log and debug (with GLDebug=1) log to upload when making posts. If you have narrowed down a problem to a specific asset in your load order, then upload that asset and whatever other assets it requires, especially the cubemap texture. In particular if the asset(s) can not be acquired elsewhere. Make sure you are using the latest version of PGPatcher. The linked mod does not contain a ferngrass.nif or any PBR textures, so it is unclear what PBR mods are used or required to reproduce. There are plenty of NIFs using the environment shader already which are loaded and rendered TexGen without problem. So there is a to be at least a second factor in your specific asset. https://dyndolod.info/Messages/Exceptions#OpenGL 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.

I assume after that that error message is gone or is there still another plugin moving the reference?

I would say grass LOD brightness not matching full grass is not normal. https://dyndolod.info/Help/Grass-LOD Grass LOD is generated for LOD level 4 only. https://dyndolod.info/How-LOD-Works near the bottom is a screenshot that explains why the different LOD levels are large squares.

See https://dyndolod.info/FAQ#Long-running-time-or-output-several-GB-in-file-size in particular: It is normal for ultra tree LOD with 3D tree LOD models to take longer. Especially if the 3D tree LOD models are complex (large file size). Use or create optimized 3D tree LOD models or use tree LOD billboards instead. Do not use complex models for ultra tree LOD. Check ..\DynDOLOD\Logs\DynDOLOD_[GAME MODE]_ModelsUsed_[WORLDSPACE].txt for a list of meshes and their total contribution to the object LOD meshes file sizes. If the total file size for an object exceeds hundreds of MBs, consider creating an optimized LOD model. The DynDOLOD log reports at 2:15 and 4:54 not very well optimized 3D tree "LOD" models that generate several GBs of LOD meshes. Use billboards or a better optimized 3D tree LOD models (which might mean a different tree mod). It is normal that Grass LOD generation takes considerable longer. The more grass placements (mods, game INI, data in the grass cache) and the higher the density setting the longer it will take and the larger the output will be. Grass LOD for complex grass may take even longer. The larger the grass cache, the larger the generated object LOD and the longer it takes. The grass LOD density was set to a 100%. Consider lower settings. Like 33 for example. See https://dyndolod.info/Help/Grass-LOD#Settings Change the Density dropdown to a lower value in the advanced mode of DynDOLOD under the Grass LOD checkbox to thin out grass LOD for better performance. Note that HD grass LOD billboards for ENB complex grass use double the triangles, so in case performance is of concern, use half the density, 50% or less. In case the grass pre-cache was generated with SuperDenseGrass/Super-dense-grass = True, expect really long object LOD generation times. Lower the density to 33% or less. In regards to brightness see: In case the grass LOD brightness or color seems off (it might depend on weathers or ENB settings), try different Direct/Ambient settings for grass LOD billboards in TexGen. In addition or alternatively change the GrassBrightnessTop*/ComplexGrassBrightnessTop* and GrassBrightnessBottom*/ComplexGrassBrightnessBottom* settings in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini - those settings help if the color tone is off. Especially the image based lighting effect from ENB has a big impact on the brightness and color tone of the grass LOD. Additional complex grass lighting and time of day settings will obviously not apply to object LOD, as they are separate meshes and shaders. Do not use them so full grass and grass LOD match better for all weathers/times. 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 you follow a guide like STEP, their settings should work for their exact setup. The complex grass brightness settings still seem default. If you deviate, you can try to find relevant hints/discussion on the mods pages and test different settings. See https://dyndolod.info/Help/Grass-LOD#Updating how to test different settings more quickly.

Report if you have a plugin changing position of xx13DD6F in LegacyoftheDragonborn.esm?