sheson

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?

I upload a new test version. Use default INIs/settings if possible. Run once with RenderSingle=0 and in a case there are errors upload logs as usual. Then run with with RenderSingle=1 to verify it still works. If it works just report times for now.

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.