DynDOLOD 3.00 Alpha 180

[Blackread]

With a few of my recent DynDOLOD generations I've had issues with flickering distant LOD. Here's a video with a couple clips that demonstrate the problem:

https://www.youtube.com/watch?v=U9o7jh5UYUI

I don't think this is a large reference issue, as the affected cells are way too far to be included in the uLargeRefLODGridSize range, which I have set to 11. Also it often affects trees, which can never be large references anyway. To my eyes it looks like two different LOD levels are fighting in the affected cells, rapidly switching between LOD4 and LOD8 or similar.

The issue is quite sporadic. With each LOD generation the affected cells are different. Sometimes I don't find any affected cells at all. When I tried approaching the bugged cells some of the LOD in the cells failed to properly unload. All non-bugged cells always unload without a hitch.

Here are some logs. Logs 1 should correspond to the first clip on the video, and Logs 2 to the second clip.

What kind of troubleshooting steps would you recommend? Is there a chance this is related to the large ref workarounds? Should I try generating LODs without them active? I tried setting uLargeRefLODGridSize to 5 just in case, but it had no effect on this as expected.

Edit: Checked Papyrus logs, no DynDOLOD related messages.

Edited September 28, 2022 by Blackread

[sheson]

1 hour ago, Blackread said:

With a few of my recent DynDOLOD generations I've had issues with flickering distant LOD. Here's a video with a couple clips that demonstrate the problem:

https://www.youtube.com/watch?v=U9o7jh5UYUI

I don't think this is a large reference issue, as the affected cells are way too far to be included in the uLargeRefLODGridSize range, which I have set to 11. Also it often affects trees, which can never be large references anyway. To my eyes it looks like two different LOD levels are fighting in the affected cells, rapidly switching between LOD4 and LOD8 or similar.

The issue is quite sporadic. With each LOD generation the affected cells are different. Sometimes I don't find any affected cells at all. When I tried approaching the bugged cells some of the LOD in the cells failed to properly unload. All non-bugged cells always unload without a hitch.

Here are some logs. Logs 1 should correspond to the first clip on the video, and Logs 2 to the second clip.

What kind of troubleshooting steps would you recommend? Is there a chance this is related to the large ref workarounds? Should I try generating LODs without them active? I tried setting uLargeRefLODGridSize to 5 just in case, but it had no effect on this as expected.

Edit: Checked Papyrus logs, no DynDOLOD related messages.

Some of it looks like z-fighting between object LOD and object LOD or maybe terrain LOD. Are the trees affected or not? If there is ultra tree LOD set standard tree LOD to zero.

Some of it looks like almost like there is something going on with the snow LOD shaders. https://dyndolod.info/Help/Snow-Ash-LOD-Shader, check what overwrites those records.

Test without DynDOLOD plugins to make sure it has nothing to do with dynamic LOD and this the large ref workarounds. Large ref workarounds can only work in the uLargeRefLODGridSize.

Test with default INIs. Make sure no custom INI or [plugin].ini in data folder either.

Test without the water (falls) mod that has controller blocks in LOD models (the block itself is not causing the issue as it is ignored, but it means somebody made bad static object LOD models). Which version of Water for ENB is it?  https://dyndolod.info/Mods/Waterfalls (meshes in DynDOLOD Resources for these mods have the full model CRC32 in their filename)
Do you use other full models for LOD. Especially ones with BSEffectShaderProperty. Some shader settings/flags can cause wierd effects.

The last few seconds of the video shows switch between LOD levels.

[David2408]

Using the current Dyndolod 3 Beta with Dyndolod 3 Scripts and LargeRef Workarounds, I am getting an error for a specific mod for the first time almost instantly after starting the LOD creation process in the Dyndolod exe.

Dyndolod: "Item not found while processing Improved Mountain LOD and Z Fight Patch.esp [REFR:00041EE4] (places MountainRidge01_HeavySN [STAT:0005205B] in GRUP Cell Temporary Children of [CELL:0000BBA1] (in Tamriel "Skyrim" [WRLD:0000003C] at 48,-15))". 

Maybe this error report is helpful, so I posted it here according to the recommendation for such errors from Dyndolod info page.

EDIT: Same error for Lanterns of Skyrim II with another random reference: "Item not found while processing Lanterns Of Skyrim II.esm [REFR:000F4CFA] (places FXAmbSnowBlowingPlane [MSTT:000197C7] in GRUP Cell Temporary Children of [CELL:00006E0D] (in Tamriel "Skyrim" [WRLD:0000003C] at -33,29))".

Edited September 28, 2022 by David2408

[MarkAim]

Do I need to disable synthesis and Wyre Bash When running Dyndolod I was having Form ID errors from some mods and when I disabled well synthesis since that was coming up a lot it works all of a sudden. In my Experience Dyndolod dosent add any draw distance for these 2 patches 

[mooit]

18 hours ago, sheson said:

It reported this in the log
[00:04] <Error: File not found textures\DLC03\Architecture\PierShacksSiding03TwoWideRed_s.dds. Used by textures\DLC03\Architecture\PierShacksSiding03TwoWideRed_d.dds>

The textures were copied fine to the new _s name, it just didn't look for them in the temp location, only in data.

I also made it so that temp textures use uncompressed formats so texconv doesn't complain about multiple of 4

This version should do the trick
https://mega.nz/file/dAp1CDLS#tf55DHqIv8p6N5pjilTyVtY9fqbyk7UDtZ5a7O--3E4

See https://dyndolod.info/Changelog to see what changed between versions.

>I'm not sure if something has changed

You are changing settings. This is what changes. 
In your last post you said you set uLockedObjectMapLOD=8.

Which means the map is obviously not using object LOD Level 32.

https://dyndolod.info/Help/Ultra-Tree-LOD#Trees-on-the-Map

Hi shenson,

So I'm using uLockedObjectMapLOD=8 and then in the DynDOLOD UI I have LOD4/LOD8/Level0 and LOD16 Level 1 and LOD32 None.

I thought this is all correct for no trees on the map? But I still see tress...

THANKS

[sheson]

8 hours ago, David2408 said:

Using the current Dyndolod 3 Beta with Dyndolod 3 Scripts and LargeRef Workarounds, I am getting an error for a specific mod for the first time almost instantly after starting the LOD creation process in the Dyndolod exe.

Dyndolod: "Item not found while processing Improved Mountain LOD and Z Fight Patch.esp [REFR:00041EE4] (places MountainRidge01_HeavySN [STAT:0005205B] in GRUP Cell Temporary Children of [CELL:0000BBA1] (in Tamriel "Skyrim" [WRLD:0000003C] at 48,-15))". 

Maybe this error report is helpful, so I posted it here according to the recommendation for such errors from Dyndolod info page.

EDIT: Same error for Lanterns of Skyrim II with another random reference: "Item not found while processing Lanterns Of Skyrim II.esm [REFR:000F4CFA] (places FXAmbSnowBlowingPlane [MSTT:000197C7] in GRUP Cell Temporary Children of [CELL:00006E0D] (in Tamriel "Skyrim" [WRLD:0000003C] at -33,29))".

Read the first post which log and debug log and bugreport.txt (if it exists) to upload

[sheson]

8 hours ago, MarkAim said:

Do I need to disable synthesis and Wyre Bash When running Dyndolod I was having Form ID errors from some mods and when I disabled well synthesis since that was coming up a lot it works all of a sudden. In my Experience Dyndolod dosent add any draw distance for these 2 patches 

Read the first post which log and debug log to upload when making posts.

As explained in the first post, click on "Click on this link for additional explanations and help for this message" if an error prompt and read what the error means and suggestions how to fix it.
https://dyndolod.info/Messages

https://dyndolod.info/Generation-Instructions#Prerequisites
Finalize the load order. Install mods and their requirements. Sort and resolve conflict. ...
Typically create all other patches first. Especially all patches affecting exterior worldspaces in any way should be done before generating LOD.

https://dyndolod.info/Generation-Instructions#2-Generate-The-LOD-Mod-with-DynDOLOD
Finalize the load order as explained in the prerequisites above. Make sure all mods, plugins and patches (that affect exterior cells and worldspaces and base records used by references in exterior cells) are enabled and their overwrite order is sorted. Ignore wrong 3rd party advice to temporarily disable plugins, mods, meshes or textures. Such advice is categorically wrong or outdated. In case of issues, solve the cause or use appropriate rules or settings for desired results.

Errors in the patches need to be fixed (for example the patch needs to be generated for the current load order) instead of being ignored.

[sheson]

2 hours ago, mooit said:

So I'm using uLockedObjectMapLOD=8 and then in the DynDOLOD UI I have LOD4/LOD8/Level0 and LOD16 Level 1 and LOD32 None.

I thought this is all correct for no trees on the map? But I still see tress...

THANKS

You set uLockedObjectMapLOD=8.

Which means the map is not using object LOD Level 32.

https://dyndolod.info/Help/Ultra-Tree-LOD#Trees-on-the-Map explains to set uLockedObjectMapLOD=32.

[David2408]

3 hours ago, sheson said:

Read the first post which log and debug log and bugreport.txt (if it exists) to upload

Here are links to the three log files as requested. These were generated when I encountered a second error (of similar kind to the z Fight Patch mod) with Lanterns of Skyrim II and latest Dyndolod 3.

bugreport: https://ufile.io/uc9wlnsb

log: https://ufile.io/lwzvs2qh

debug: https://ufile.io/713o3vat

[sheson]

33 minutes ago, David2408 said:

Here are links to the three log files as requested. These were generated when I encountered a second error (of similar kind to the z Fight Patch mod) with Lanterns of Skyrim II and latest Dyndolod 3.

bugreport: https://ufile.io/uc9wlnsb

log: https://ufile.io/lwzvs2qh

debug: https://ufile.io/713o3vat

Download and use this test version. https://mega.nz/file/ZJhCDLaR#55i96PrOSVkStquO4Tz9aL0-w6nQOprGvZUh8GBNWzQ
It should properly deal large references being moved to cells that didn't lave large references before. Let me know in case there are still problems and upload new logs in that case.

Also note this:

https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Requirements
The workarounds require plugins containing deleted large references to be cleaned. Every plugin containing deleted references should be cleaned. See the Prerequisites section of the Generation Instructions for more.

https://dyndolod.info/Generation-Instructions#Prerequisites
Clean and error check the load order with xEdit. Clean every plugin that LOOT suggests to clean - ignore misinformation that cleaning any plugins is not needed or causes problems. The Batch Plugin Cleaner for Mod Organizer or the xEdit Cleaning Extension for Vortex help to automate some of that.

[Blackread]

16 hours ago, sheson said:

Some of it looks like z-fighting between object LOD and object LOD or maybe terrain LOD. Are the trees affected or not? If there is ultra tree LOD set standard tree LOD to zero.

Some of it looks like almost like there is something going on with the snow LOD shaders. https://dyndolod.info/Help/Snow-Ash-LOD-Shader, check what overwrites those records.

Test without DynDOLOD plugins to make sure it has nothing to do with dynamic LOD and this the large ref workarounds. Large ref workarounds can only work in the uLargeRefLODGridSize.

Test with default INIs. Make sure no custom INI or [plugin].ini in data folder either.

Test without the water (falls) mod that has controller blocks in LOD models (the block itself is not causing the issue as it is ignored, but it means somebody made bad static object LOD models). Which version of Water for ENB is it?  https://dyndolod.info/Mods/Waterfalls (meshes in DynDOLOD Resources for these mods have the full model CRC32 in their filename)
Do you use other full models for LOD. Especially ones with BSEffectShaderProperty. Some shader settings/flags can cause wierd effects.

The last few seconds of the video shows switch between LOD levels.

Thank you for the tips. It is indeed a case of z-fighting between object LOD and object LOD. The youtube compression ruins the image so it's not so clear, but here's another video that should display it better: https://www.youtube.com/watch?v=piHXL1DE9CM

I also found a solution: remove ini files from the data folder for an amount that adds up to at least 8 lines of text. Commenting out lines of settings with a semicolon (;) works too. It doesn't matter what settings they are or which mod they are from, or whether the settings are overridden by another ini file from a later loading plugin. As long as at least 8 lines are removed the z-fighting is gone. It also looks like ini files intended to be read by various SKSE plugins (KID, SWAP, DISTR, LID, FLM, etc.) are included in this count. Removing any of these files that have at least 8 lines of text removes the z-fighting. The file I remove can also be in a subfolder. It doesn't even have to be an ini file at all, it can be a json file or a txt file such as a changelog, or a readme. Script source files (.psc) also work.

Reseting my base inis to default also fixes the z-fighting. I would imagine this is because it effectively removes at least 8 lines of text from them, as the BethINI Tweaks add several new settings to the files.

I also tried packing one of my mods that had loose script files into a bsa, and this too removed the z-fighting.

Putting all of the above together seems to suggest that there is some sort of engine limitation on the number of lines there can be in loose files with text content in the data folder. Or something along those lines.

Edited September 29, 2022 by Blackread

[sheson]

12 minutes ago, Blackread said:

Thank you for the tips. It is indeed a case of z-fighting between object LOD and object LOD. The youtube compression ruins the image so it's not so clear, but here's another video that should display it better: https://www.youtube.com/watch?v=piHXL1DE9CM

I also found a solution: remove ini files from the data folder for an amount that adds up to at least 8 lines of text. Commenting out lines of settings with a semicolon (;) works too. It doesn't matter what settings they are or which mod they are from, or whether the settings are overridden by another ini file from a later loading plugin. As long as at least 8 lines are removed the z-fighting is gone. It also looks like ini files intended to be read by various SKSE plugins (KID, SWAP, DISTR, LID, FLM, etc.) are included in this count. Removing any of these files that have at least 8 lines of text removes the z-fighting. The file I remove can also be in a subfolder. It doesn't even have to be an ini file at all, it can be a json file or a txt file such as a changelog, or a readme. Script source files (.psc) also work.

Reseting my base inis to default also fixes the z-fighting. I would imagine this is because it effectively removes at least 7 lines of text from them, as the BethINI Tweaks add several new settings to the files.

I also tried packing one of my mods that had loose script files into a bsa, and this too removed the z-fighting.

Putting all of the above together seems to suggest that there is some sort of engine limitation on the number of lines there can be in loose files with text content in the data folder. Or something along those lines.

If I didn't know any better the video looks like object LOD models with slightly different textures have been added to the same BTO. Like duplicate references/models with different textures.

Since you say you can fix it by removing lines from INI files that theory is ruled out. Wild.

I assume you are using SSE Engine Fixes and have MaxStdio to the max the OS supports? That is the one known thing that could be related I can thing of right now.

Try to estimate the max number of lines, if it is close to a power of like 4096, 8192, 16384, 32767 etc. then this could very well be a line counter of buffer limitation thing.

If you have the willpower and time, try to check some LOD related INI setting right in the game via the getini command to see what they actually are.

[Glanzer]

15 hours ago, MarkAim said:

Do I need to disable synthesis and Wyre Bash When running Dyndolod I was having Form ID errors from some mods and when I disabled well synthesis since that was coming up a lot it works all of a sudden. In my Experience Dyndolod dosent add any draw distance for these 2 patches 

I create the bashed patch first, then run xlodgen/dyndolod/occlusion, then run synthesis. I find that there are a few records that dyndolod uses from the bashed patch, so the plugin order ends up being bashed patch, dyndolod.esp, synthesis.esp, occlusion.esp, followed by map mod plugins. Your mileage may vary! Here's the remind I wrote for myself, but keep in mind this is based on the mods I have installed:

PATCHING ORDER:
1. Disable map mods
2. Remove all dynamic patches (bashed patch, zpatch, synthesis, dyndolod)
3. Run blacksmith forge water xedit patcher, enable it
4. Run bashed patch, enable it
5. Run the "No Grass in Objects" grass generator from within MO2. Move the output file to the NGIO mod.
6. Then run SSELODGEN/Dyndolod/Occlusion, enable them.
7. Run zedit patches, enable them
8. Run synthesis patcher, enable it.
9. Run the standalone Experience Synthesis patcher
10. Rerun Nemesis and execute the vbs file for Engarde
11. Re-enable map mods

Edited September 29, 2022 by Glanzer

[Blackread]

2 hours ago, sheson said:

If I didn't know any better the video looks like object LOD models with slightly different textures have been added to the same BTO. Like duplicate references/models with different textures.

Since you say you can fix it by removing lines from INI files that theory is ruled out. Wild.

I assume you are using SSE Engine Fixes and have MaxStdio to the max the OS supports? That is the one known thing that could be related I can thing of right now.

Try to estimate the max number of lines, if it is close to a power of like 4096, 8192, 16384, 32767 etc. then this could very well be a line counter of buffer limitation thing.

If you have the willpower and time, try to check some LOD related INI setting right in the game via the getini command to see what they actually are.

Yeah, MaxStdio is set to 8192.

Unfortunately it looks like after packing the Missives mod to an archive and unpacking it I am no longer able to reproduce this issue. Maybe it was some random fluke or some obscure yet undiscovered bug. I'll update this if it returns and I'm able to perform more testing.

Edit: Here's a quick video of the same LODs now: https://www.youtube.com/watch?v=4DGjMtBSnvs

Edited September 29, 2022 by Blackread

[mooit]

12 hours ago, sheson said:

You set uLockedObjectMapLOD=8.

Which means the map is not using object LOD Level 32.

https://dyndolod.info/Help/Ultra-Tree-LOD#Trees-on-the-Map explains to set uLockedObjectMapLOD=32.

Remember I reported flickering/shimmering on Objects?

You said to change the uLockedObjectMapLOD which was on 32. 

Not sure why but with it on 32, if you remember I was getting bad shimmering flickering on objects all across the map.