sheson

DynDOLOD does not do anything to full grass. Set the appropriated settings in NGIO GrassControl.config.txt to control full grass and its max render distance. https://dyndolod.info/Help/Grass-LOD With No Grass In Objects full grass can be rendered past the active cells, so Grass LOD can either start right beyond the active exterior cells (uGridsToLoad), which has better for performance - or beyond the large reference distance (uLargeRefLODGridSize). The DynDOLODGrassMode/DynDOLOD-Grass-Mode 1 or 2 setting controls the distance of full grass respectively. Set the same desired Mode in the advanced mode of DynDOLOD under the Grass LOD checkbox and for DynDOLODGrassMode/DynDOLOD-Grass-Mode in the settings file. While the DynDOLODGrassMode/DynDOLOD-Grass-Mode setting can be changed at any time, the Mode used to generate grass LOD is baked into the object LOD meshes. If you have problems with full grass and NGIO, you need to ask on the NGIO forum or comments.

Ensure-max-grass-types-setting changes number of full grasses per landscape texture. Overwrite-min-grass-size changes density of full grass. As explained by NGIO, the above settings overwrite iMaxGrassTypesPerTexure and iMinGrassSize in the Skyrim/mod INI. Changing these settings changes full grass amount and density, so the positions. So the cache and the LOD should be updated to reflect those changes.

Yes you are correct, both BOS and DynDOLOD also sort the BOS INIs alphabetical. Same issue with the case sensitivity though - that I double checked with the logs. So that will be fixed as well.

cache = precache = the files in the ..\data\grass\ folder generated by NGIO. https://dyndolod.info/Help/Grass-LOD Grass LOD uses grass LOD billboards in object LOD, similar to ultra tree LOD. [..] Grass LOD is generated for LOD level 4 only. Grass LOD generation requires a warmed (current) grass precache for the current load order. It uses the *.CGID files found in the ..\Data\Grass\ folder. If you do not change any settings that affect the data in the cache, like changing the filenames of full grass models, the number of full grasses per landscape texture or the density full grass, then there is no need to generate the grass cache again, as it will be more or less the same.

https://dyndolod.info/Help/Grass-LOD The grass cache contains grass model and placement information. https://dyndolod.info/Help/Grass-LOD#Settings 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. https://dyndolod.info/Help/Grass-LOD#Performance There are settings that change the amount of full grasses and the density of full grass in the cache. There more full grass, the more LOD grass, the higher the performance requirement. The denser the placements, the denser the grass LOD, the higher the performance requirements.

If you are absolutely sure that the load order did not change after generating the output with alpha 170 let me know for follow up questions/troubleshooting.. Otherwise, generate a LOD patch from scratch with the latest alpha for the current load order, to verify that the crash still happens. If it does, upload new DynDOLOD log and debug log and new crash log and keep the output around for follow up questions/troubleshooting.

As I mentioned, the 3D LOD assets point the normal vector upwards so that double side triangles have equal brightness on either side and are brightest if the light shines from the top (they are actually slightly angled, so not exactly) You could test removing the double sided flag and right click a BSTriShape, Mesh, Face normals, then again right click a BSTriShape, Mesh, Update Tangent Space. If those work better, to restore the now missing "back triangles", convert the meshes to Skyrim (NiTriShapes) format with CAO. Duplicate the crown shape with right click on the NiTriShape, Block, Copy and right click on the root 0 BSFadeNode, Block, Paste. Then right click the NiTriShape, Mesh, Flip faces, Flip normals, Update Tangent Space.

That screenshot is a good example for how the object LOD for some stony structures is not recieving shadows, while some full models that happen to be large references in the LOD area still do.

However unlikely that seems to be, if we assume for a minute that to be true, what do you want the tool creating the BTOs to do differently if the engine does whatever it does regardless of settings? That would be something that needs to be addressed in the engine/shaders with ENB or Communuty Shaders etc. If using ENB distant shadows or Community Shaders does not help, then I suggest to look into the normal vectors next. In these 3D tree LOD assets the normal vectors typically point upwards instead of the usual perpendiular direction from the surface. That is usually a better option for double sided triangles, so both sides are illuminated equally and brightest when the sun shines from above. Double check the BTOs that the normal vectors for the crowns still point upwards. NifSkope shows the normal vectors if you unfold the Vertex Data array in the BSTriShape and highlight the normal entry in an array entry.

The link to the 3D LOD files requires a login, so I can not download it. Based on the screenshots I would assume this has to do with LOD by default not receiving/casting shadows. https://dyndolod.info/How-LOD-Works LOD does not cast or receive shadows. This can be mitigated by the ENB distant shadow effect or Screen-Space Shadows. If large reference bugs workarounds are used, tree full models can be made to also load outside the active cells, to push their swap distance further away. https://dyndolod.info/Help/Terrain-Underside#Troubleshooting LOD does not cast or receive shadows. This can be mitigated by the ENB distant shadow effect or Screen-Space Shadows. 0005C06E uses s3dtrees_treepineforestsnow05_lod_0.nif with CRC32 91829509 which I could not match to any file I currently have. I assume it might be one from the upload that I can not access. If the LOD model sets those flags or third texture and they somehow end up in the BTO with those features despite no passthru in filename (or shapename), remove them form the LOD asset. https://dyndolod.info/Help/3D-Tree-LOD-Model 0005C06F uses s3dtrees_treepineforestsnow04_lod_0.nif with CRC32 56F8528E which indicates it is still the LOD files included in Skyrim3DTrees and Plants 3dLOD Resources, which does not set any rim or soft lighting or third texture. Its combined shapes in the BTO should not have such settings either. The screenshot of NifSkope shows no rim or soft lighting flags being set. What is it supposed to show?

By default, LOD assets and thus their LOD shapes in BTOs do not set these shader flags or have a third texture. Only LOD assets that specifically instruct DynDOLOD to keep those settings have them generated in the BTO. https://dyndolod.info/Official-DynDOLOD-Support-Forum Report the actual problem or error message without making assumptions or asking leading questions. Read the explanations and tips below, especially about what information and logs to provide and how.

It is correct. The screenshotted reference xx00C938 using Meshes\jk's blue palace\sbluepalacegate.nif also has Meshes\jk's blue palace\sbluepalacegate.nif in the BTO because of that mesh mask rule. The full model gate can be seen in the BTO. That reference is not involved in the issue you are seeing. As I suspected, I found the different reference to be xx5A004B in BluePalaceTerrace.esp. That is the one that is being replaced to a completely different model because of sos_seasons_vigilant_win.ini defines that swap. You can look up these references (BA00C938 and 325A004B) in the export file LODGen_SSE_Export_Tamriel_WIN.txt to see which reference uses which LOD model in the BTO in the end. I got confused with Base Object Swapper. Seasons INIs can have any file name and DynDOLOD does load them alphabetically (can be checked in the debug log). So "zzzConfig wins over aaaConfig". The problem is that SOS treats the filenames case sensitive while xEdit - like Windows - by default does not. For example, a is loaded after B by SOS. I will address that in the next alpha (including making sure the underscore sorts the same way - its after uppercase but before lowercase usually)

When you execute texconv from https://github.com/Microsoft/DirectXTex/wiki/Texconv from a windows command prompt, it puts out something like this:

The cd command requires a path to a directory. It can not take a path to a file. cd into the directory is not needed if you execute the exe file with its full path anyways. Do not post screenshots of text. Copy and paste the text instead.

I looked some more into this. There are 2 references adding the palace gate twice: xx5A004B in BluePalaceTerrace.esp and xx00C938 in Open Cities Skyrim.esp It probably happens because of conflicting swaps for the same base record (or EditorID) to different new base records in different INIs: sos_seasonspatch_solitude_win.ini Season WIN, swapping record Skyrim.esm SBluePalaceGate [STAT:000801ED] to SoS_Seasonspatch_Solitude.esp SBluePalaceGateWinter [STAT:FE12F812 sos_seasons_vigilant_win.ini Season WIN, swapping record Skyrim.esm SBluePalaceGate [STAT:000801ED] to SoS_Seasons - Vigilant.esp SCWgateWinter [STAT:FE310801] DynDOLOD loads in the swap INIs in the same order as the plugins and as usual whatever is loaded last wins. It is possible that Seasons of Skyrim does it different for some reason. If that is the case and actually intended to work differently than usual, then I will change that in DynDOLOD obviously. In any case, the swap from the palace gate SBluePalaceGate to Solitude main gate SCWgate in sos_seasons_vigilant_win.ini seem wrong anyways.

Programs are executed from a command prompt by typing their name and then hitting Enter key. Typically cd into the directory first. However, do it with the official version. The custom version included in DynDOLOD is "silent".

https://dyndolod.info/Help/Texconv DynDOLOD includes a customized version of Texconv to convert different texture formats. Since you got the official version, run it on a Windows command prompt and check its output. It should list the command line options and stuff, the interesting parts are the supported (DirectX) feature levels and list of adapters. Make sure the best graphics is listed first. As explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs use pastebin or a file service for the logs. If Texconv returns -1 = FFFFFFFF it had a problem all by itself. The DynDOLOD and Occlusions plugins are created when the LOD patch is generated and saved once the creation was successful and the user clicks the Save & Exit or Save & Zip & Exit options and also when checking the log and then closing the tool.

"DynDOLOD.exe" https://dyndolod.info/Installation-Instructions Use the x64 versions of DynDOLOD/TexGen. That means to use TexGenx64.exe and DynDOLODx64.exe https://dyndolod.info/Messages/Exceptions, also says: Make sure to use the x64 versions of the tools. Scrolling to https://dyndolod.info/Messages/Exceptions#Access-violation, also suggests: This could be low or out of memory problems. Use the x64 version of the tools.

LODGen_SSE_Export_Tamriel_WIN.txt BA00C938 00000000 -52591.691406 101743.687500 -8256.000000 0.000000 0.000000 45.000000 1.000000 XJKBluePaSBluePalaceGateWIN 08000000 Snow Meshes\jk's blue palace\sbluepalacegate.nif Meshes\jk's blue palace\sbluepalacegate.nif Meshes\jk's blue palace\sbluepalacegate.nif The shown full model reference/base record uses the full model sbluepalacegate.nif for LOD in Level 4 and 8. Remove that line from LODGen_SSE_Export_Tamriel_WIN.txt and then Execute LODGen in export for Tamriel/Win only with Specfic Chunk=4 W=-16 S=24 to only generate that specific BTO. It should still have that wall. Try to find the actual reference Whatever you see in the LOD screenshot is caused by a different reference. Use tfc in console to get closer. https://dyndolod.info/Mod-Authors#How-to-add-your-own-object-LOD-models The automatic matching assigns the different distant LOD meshes levels based on _[0|1|2|3] part of the filename. To assign models to specific distant LOD meshes levels, use house_lod_0.nif for level 0, house_lod_1.nif for level 1, and house_lod_2.nif for level 2 and house_lod_3.nif for level 3. However, in this case it is easier, quicker and more compatible to use rules with mesh masks that match entire groups of filenames, since variations exist. For example if the mesh mask is just rtfarmhouse, it will match all vanilla rtfarmhouse01, rtfarmhouse02 and any custom variation added by mods like rtfarmhouse01win, rtfarmhouse02snow, rtfarmhouse03 etc. without having to rename dozen of files. Just make a rule that looks like the last / rule and enter rtfarmhouse as mesh mask.

If you want to report a mismatch between full models and LOD, then provide screenshots of the full model (with more informative console) and the LOD. The reference and base record form ID are required to look things up in the logs. The "highest" available LOD models in these cases end in *1.nif, which means Level1. The last / rule automatically assigns those to LOD8 max. *2.nif = Level2 is assigned to LOD16 automatically as explained in the documentation. But no such LOD models exist in these cases. So in this case add mesh rules for these models and set Level1 to LOD16 - choose the partial mesh mask right, a couple rules might be enough to cover all cases and seasons. There are no such rules yet, because nobody reported a problem so far. I will most likely address this in future updates.

https://dyndolod.info/Help/Advanced-Mode#Low-Medium-or-High-Preset-Buttons All existing rules will be replaced. https://dyndolod.info/Help/Advanced-Mode#Candles-FXGlow The check boxes activate rules for Candles and FXGlow. These rules will be loaded when clicking any of the low, medium or high preset buttons. As explained, clicking Low, Medium or High will always replace all existing rules. It will then load the rule files that match the selected preset and any files without any preset identifier or _all in the filename.

https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-the-Latest-Versions Always use the latest DynDOLOD Standalone and DynDOLOD Resources version. The logs show that Dawnguard.esm has a CRC32 of A8AD8072, which indicates it is not the latest or latest quick cleaned version (that ship with 1.6.1770) which the CC plugins are made for. Downgrading is basically just replacing the SkyrimSE.exe with whatever runtime of your choice and making sure to keep binkw64.dll if required and older version of steam_api64.dll in case SteamLess is not used to remove the DRM.

Moved to the appropriate thread for the error message. As explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages, click onto "Click on this link for additional explanations and help for this message link of" to open https://dyndolod.info/Messages/Unresolved-Form-ID For example, do not use plugins or paid mods from the Creation Club Anniversary Edition with outdated vanilla game plugins from before the Anniversary update (only downgrade the executable of the game, not the plugins). Update the required plugins and use matching versions. Search this forum for the error as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-Search. It finds this post: https://stepmodifications.org/forum/topic/15567-unresolved-formid/?do=findComment&comment=265606 Either cceejsse005-cave.esm has been modified or more likely one of its masters is the wrong/outdated version. Probably Dawnguard.esm. Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which entire DynDOLOD log and debug log to upload when making posts. As explained, the paid mods obviously require the latest/matching versions of the vanilla game plugins.

DynDOLOD saves the debug log right after the normal log. Simply let it close/shut down normally. It can take a while. No mods or links to mods were provided. No useful screenshots were provided. https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots No base record form IDs were provided. Read https://dyndolod.info/Installation-Instructions and https://dyndolod.info/Updating#New-DynDOLOD-Version. Do not install newer versions over older versions. I assume for all listed references, the issue is both, the winter LOD does not match and no LOD on the map when the season is winter? 00080C57 swapped to base record to 844~SoS_Seasonspatch_Riften.esp from Simplicity of Seasons? CRC32 of plugin does not match Simplicity of Seasons 1.4.1? Full model rtkeep01snow.nif CRC32 dos not match Simplicity of Seasons 1.4.1? LOD uses vanilla LOD model and should have snow cover via the snow LOD shader in winter LOD. With the current default rules there is no LOD model defined for LOD level 16 for default or winter seasons. so it expected the it does not show in the map. Create a custom rule that sets Level1 to LOD Level 16 to show it on the map. 167A~RiftenExtension.esp swapped to base record to 83A~SoS_Seasonspatch_Riften.esp from Simplicity of Seasons? CRC32 of plugin does not match Simplicity of Seasons 1.4.1? Full model rtfarmhouse01snow.nif CRC32 dos not match Simplicity of Seasons 1.4.1? LOD uses vanilla LOD model and should have snow cover via the snow LOD shader in winter LOD. With the current default rules there is no LOD model defined for LOD level 16, so it expected the it does not show in the map. Create a custom rule that sets Level1 to LOD Level 16 to show it on the map. 167A~RiftenExtension.esp swapped to base record to BBD~Seasonal Landscapes - SoS_Seasons patch.esp, unclear what mod the plugin is from. Full model rtfarmhouse02win.nif, unclear what mod it is from. LOD uses vanilla LOD model and should have snow cover via the snow LOD shader in winter LOD. With the current default rules there is no LOD model defined for LOD level 16, so it expected the it does not show in the map. Create a custom rule that sets Level1 to LOD Level 16 to show it on the map. 000BB7B4 swapped to base record to 86C~SoS_Seasonspatch_Riften.esp from Simplicity of Seasons? CRC32 of plugin does not match Simplicity of Seasons 1.4.1? Full model rtstables01snow.nif CRC32 dos not match Simplicity of Seasons 1.4.1? LOD uses rtstables01snow_lod.nif, unclear what mod it comes from. LOD has snow cover via the snow LOD shader. LOD model defined for Level 16, so It should show on the winter map. 7EDC~Bells of Skyrim - OCS Patch.esp Reference form id not found in any logs 0008E2CA swapped to base record to 889~SoS_Seasonspatch_Solitude.esp from Simplicity of Seasons? CRC32 of plugin does not match Simplicity of Seasons 1.4.1? Full model shouseforsalesnow.nif CRC32 dos not match Simplicity of Seasons 1.4.1? LOD uses "vanilla" LOD model from DynDOLOD Resources and should have snow cover via the snow LOD shader in winter LOD. With the current default rules there is no LOD model defined for LOD level 16, so it expected the it does not show in the map. Create a custom rule that sets Level1 to LOD Level 16 to show it on the map. All the swapped full models (minus the rtfarmhouse02win.nif) I have here from Simplicity of Seasons, do not contain 3D snow covers. The snow cover for the full model always seems to be realized via using a snow shader. So in that regard the default LOD models using the snow LOD shader should match?

Read my answers above https://stepmodifications.org/forum/topic/14153-overwriteesl-or-overwriternamesl-is-not-a-valid-plugin-invalid-object-id/?do=findComment&comment=236494 Overwrite.esl is an example plugin for the documented large reference bugs of Skyrim Special Edition and should obviously not be installed as part of a normal DynDOLOD installation. https://stepmodifications.org/forum/topic/14153-overwriteesl-or-overwriternamesl-is-not-a-valid-plugin-invalid-object-id/?do=findComment&comment=232930 You should not install anything from the Standalone archive to any the game folders. https://stepmodifications.org/forum/topic/14153-overwriteesl-or-overwriternamesl-is-not-a-valid-plugin-invalid-object-id/?do=findComment&comment=258351 you installed files from in the sub folder ..\Docs\SkyrimSELargeRefGrid\Data\ - which are part of a bug report example - into the data folder / as a mod. There are no such instructions anywhere to do so. https://stepmodifications.org/forum/topic/14153-overwriteesl-or-overwriternamesl-is-not-a-valid-plugin-invalid-object-id/?do=findComment&comment=275019 Do not install anything from the DynDOLOD Standalone archive to the game data folder, in particular do not install test plugins from the large reference error report. If you read and follow https://dyndolod.info/Installation-Instructions, then you will notice that they explain to unpack the DynDOLOD Standalone archive to a folder outside of the game and mod manager folders. The instructions do not mention to install Overwrite.esl or any of the other plugins to any game or mod folders. You did not read or follow the instructions given in the linked https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs. The erroneously installed example plugins need to be permanently removed from the any game or mod folders.