sheson

RenderThreads only has an effect if RenderSingle is set to 0 specicially in the INI. Upload the the log, debug log or in case they are not saved, the realtime log from the proprietary drivers and RenderSingle=0 when it gets terminated. Upload just the debug log from any of the successful runs. Doesn't matter which.

The first post I linked says: ... only set MaxRenderResolution=4096 to work around the recent Nvidia Linux drivers to consume all main memory. This only makes sense to do, if all memory is actually consumed at start up. That can be checked with system tools/monitors installed with the OS. Read the second thread I linked. Run and upload logs from the test version from this post https://stepmodifications.org/forum/topic/21129-opengl-invalid-value-from-twbrenderloadglmultiimage/page/2/#findComment-287412

Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt. Make a useful screenshot of a full model that has too bright LOD with more informative console. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots: Use Mfg Console or More Informative Console to show additional information when opening the console and clicking an object. Keep the selected object visible to the side, so it is not covered by the informative panels. Also try to make a useful screenshot with more informative console of one if the dynamic LOD models in the distance. Try to get closer with tcl. If that proofs too difficult, the DynDOLOD_SSE_Object_Report.txt hopefully tells me what I need to know. The upload full source snow01.dds is BC7 sRGB and not BC1 sRGB. I thought you reported a problem with source textures being BC1 SRGB? You reported earlier, that setting 1.4 gamma had no effect. The log however shows that sRGBGamma was still default 2.2? The generated snow01pbr_lod.dds looks as one would expect with the default gamma and alpha channel removed. If you want it darker, lower the sRGBGamma setting in the TexGen and DynDOLOD INI. See https://dyndolod.info/Mods/Community-Shaders#PBR The snow01linear.dds you upload earlier looks like it was generated from a different snow01.dds.

Upload D:\Modding\tools\DynDOLOD\Logs\LODGen_SSE_RigmorRoscrea_log.txt. DynDOLOD Resources contains 3 NIF files in that effects folder. Install the DynDOLOD Resources properly and ensure the NIFs are winning any conflict. MO2 should obviously properly report the contents of that folder/find all those 3 files. Typically DynDOLOD would report missing resources files at startup or there should be file not found messages later in the log. The block types (e.g. strings of their names) are read from the header of the same NIF. The root block being an empty string might be a problem with reading the NIF from disk/ through the vfs. If the NIF file seems fine when loading directly in NifSkope, close all NifSkopes, then run Explore Virtual Folder from the MO2 drop down, navigate to D:\SteamLibrary\steamapps\common\Skyrim Special Edition\data\Meshes\effects\ and double click the NIF to open it in NifSkope through the vfs. You can also try using xEdit Asset Browser started with CTRL+F3 and then filter by a NIF filename and double clicking the shown NIF file to open it through the vfs. Could be antivirus interfering, though that seems very specific if it only affects those files and nothing else. I am more worried about this error message: Error assigning to [ \ [BA] DynDOLOD.esm \ [4] GRUP Top "WRLD" \ [1] GRUP World Children of Tamriel "Skyrim" [WRLD:0000003C] \ [3] GRUP Exterior Cell Block -1, 0 \ [1] GRUP Exterior Cell Sub-Block -2, 2 \ [2] [CELL:000092BB] \ [9] XCWT - Water] from [ \ [09] LegacyoftheDragonborn.esm \ [41] GRUP Top "WRLD" \ [1] GRUP World Children of Tamriel "Skyrim" [WRLD:0000003C] \ [11] GRUP Exterior Cell Block -1, 0 \ [8] GRUP Exterior Cell Sub-Block -2, 2 \ [4] [CELL:000092BB] \ [9] XCWT - Water]: [Exception] Load order FileID [01] can not be mapped to file FileID for file "DynDOLOD.esm" What version of LegacyoftheDragonborn.esm do you use? What are the last plugins to overwrite the worldspace 0000003C and cell record 000092BB? Are they error free? You want to sort out the conflict of the mineorescript if you want CCO it to work as intended.

If possible repeat the tests with the proprietary driver. The OS freezing is a problem of the OS/driver or hardware. The worst that should in any program is that it has an error or crashes. Ring 0 and 3 and all that. Vanilla should not be really more than 2 or 3 minutes at default settings for 1080p.

Wow, that is incredible slow. Lets try to fix that first. It should not be more than a few minutes. Set GLDebug=0, RenderSingle=0, RenderThreads=2 or 4 to see if/which improves times. Set compression to DXT1/DXT5 as a separate test as well if changing the settings does not improve things. Report results. You do not have to wait hours for it to complete if you notice it still runs as slow as before, just report the findings without logs. You will need a test version of DynDOLOD as well. You can use the one from this post https://stepmodifications.org/forum/topic/19903-dyndolod-300-alpha-194/page/700/#findComment-287548. If above settings improved time, set the same in DynDOLOD_SSE.INI. You can find the textures in the SMIM SE archive. You can extract/install them manually. You may have selected custom install options that TexGen does/can not recognize as it just assumes a (complete) install that includes those textures.

This is the DynDOLOD 2.x thread. I believe you are using DynDOLOD 3? In either case upload the entire DynDOLOD log and not just a few lines. In case of DynDOLOD 3 also uplaod the debug log. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs The provided error message seens to report the rootblock name to be empty, which might indicate a problem with accessing or reading the files. Verify in MO2 right window data tab that the NIFs are actually from DynDOLOD Resources and check their root node with NifSkope. The meshes in DynDOLOD Resources have BSFadeNode root nodes and should be fine. See https://dyndolod.info/Mods/Waterfalls

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs how to enable the realtime log in case the tools are prematurely terminated and can not write the normal log and debug log. Could be related to https://stepmodifications.org/forum/topic/21027-texgendyndolod-out-of-graphics-memory-linux/page/2/#findComment-287422, then maybe https://stepmodifications.org/forum/topic/21129-opengl-invalid-value-from-twbrenderloadglmultiimage

Try the new test version from that post https://stepmodifications.org/forum/topic/21129-opengl-invalid-value-from-twbrenderloadglmultiimage/page/2/#findComment-287412. GLListDebug doesn't matter, just run with GLDebug=1. Upload new logs.

Thanks for letting us know.

Try new test version from that post. Start without GLListDebug=1 or set it to 0. Only enable it in case there are still errors to produce new logs.

Use the test version from this post and report results. If there still is an error upload new log, debug log and bugreport.txt.

Upload logs from new test version. If it does get to the GUI and you can start creation of textures and then has an error, add GLListDebug=1 under GLDebug=1 to the INI. Then upload those logs.

Moved to the appropriate thread for PBR. See posts above. See https://dyndolod.info/Mods/Community-Shaders#PBR and https://dyndolod.info/Help/xLODGen#Terrain-LOD-Textures-Brightness If the distant terrain is too bright, lower the gamma setting in xLODGen. For example to 0.7 as a start. Use the specific chunk option to generate a specific area only for quicker testing. See Terrain-LOD-Readme.txt in the xLODGen folder.

Moved to the DynDOLOD 3 alpha thread. See the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which bugreport.txt to also upload when making posts. https://dyndolod.info/Messages/Exceptions#Range-check-error Always use the latest version of DynDOLOD/TexGen as explained above. Check the messages log for errors and warnings leading up to this error. This is 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. Nothing in the provided logs gives a hint yet. The bugreport.txt should help with further troubleshooting. The worldspace bounds messages for WTT and its patches are expected for the mod and not a problem.

Just uploaded another new test version to that post. Upload new logs.

This test version of DynDOLOD should fix it https://mega.nz/file/ddg12IZS#YVylaDyEVJq5j6a4UXdZuYKv7cyz1BMyADibeHhR_jM Loading existing installed output/plugins and then just updating Tamriel object LOD and then overwriting old output with the new output might work. Otherwise generate from scratch.

Get new test version from that post and upload new logs...

Get new test version from this post https://stepmodifications.org/forum/topic/21129-opengl-invalid-value-from-twbrenderloadglmultiimage/page/2/#findComment-287412 Report results. If there is an error set GLDebug=1 in the INI and run again and then upload the log, debug log and bugreport.txt.

Run the updated test version from this post https://stepmodifications.org/forum/topic/21129-opengl-invalid-value-from-twbrenderloadglmultiimage/page/2/#findComment-287412 Report results. If there is an error set GLDebug=1 in the INI and run again and then upload the log, debug log and bugreport.txt. In any case get glew-2.2.0-win32.zip from https://github.com/nigels-com/glew/releases, unpack the folder ../bin/Rel4ease/x64 and run the two exes. Upload the two txt files they generate. The missing texture messages are a result of the OpenGL error when trying to load those textures.

The uploaded texture is reported by Texdiag to use the BC1_UNORM texture format and not the BC1_UNORM_SRGB format. It shows DXT1 in the header. Upload the actual source PBR diffuse texture ..\textures\PBR\landscape\snow01.dds from which the linear and LOD textures are made from. Upload the TexGen and DynDOLOD logs and debug logs. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt. Make a useful screenshot of a full model that has too bright LOD with more informative console. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots so we know the actual full model, reference and base record to look up in the logs. Then make a screenshot like https://imgur.com/FV0snJZ but this time with all LOD disabled via console tll. I expect the too bright snow LOD in that screenshot to also be toggled off, which would mean they are not dynamic LOD and do not use the base record shown in the xEdit screenshots. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#xEdit-Screenshots how not to trim anything from the xEditscreenshots. The base record will most likely have a Reference By tab at the bottom, which lists the references using it. I expect this not to be more than a handful, maybe a dozen dynamic LOD references unless you did something odd with the meshes mask rules or settings. The object LOD for the snow drift should typically use the object LOD texture atlas generated by DynDOLOD which should be made with ..\textures\lod\snow01pbr_lod.dds from the TexGen output. So upload the that texture as well.

To fix this in the current output, bring up the base record 0008E2CE in xEdit again. In the right window, in the DynDOLOD.esp column, right click remove these two entries for Alternate Texture: The first entry, SBluePalace_LOD:0, spbr_lod1_DynDOLOD.TXST [TXST:120A9C11] The last entry, SBluePalace_LOD:1, spbr_lod2_DynDOLOD.TXST [TXST:120A9C10] Save, then check in game the palace looks OK. Report results. The next alpha version should not create the wrong entries anymore.

Great. Do the same type of xEdit screenshots for the texture sets 120A9C10 and 120A9C11. Upload ..\textures\lod\spbr_lod01.dds and ..\textures\lod\spbr_lod02.dds from the TexGen output. Check in MO2 right window data tab they are from the desired TexGen output mod.

Moved to the post to the appropriate thread. Upload a DXT1 sRGB texture that does not seem to be converted to linear RGB. Upload the TexGen and DynDOLOD logs and debug logs. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt. Make a useful screenshot of a (snow drift?) full model that has too bright snow with more informative console. Also make a screenshot of LOD up close. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots

Report the actual issue properly. Define what "LOD is still broken" means. Post a screenshot of the LOD and the close up full model with it being clicked in console so it shows the reference form ID. Upload the log.