DynDOLOD 3.00 Alpha 173

[sheson]

1 hour ago, AriochRN said:

Hi, SkyrimVR player and I’m having a visual issue after travelling to Solstheim: after I got there I could see black areas on the volcano and Skyrim mainland. I went through the process of disabling Dyndolod & rerunning xlodgen/texgen/Dyndolod and everything on the distant landscape looked fine when I got back into the game - until after I’d been inside a building. When I came outside again the black areas were back. Doing the uninstall/install process again brought back the good landscapes - until after I’d been inside a building again!

Any help would be greatly appreciated if I’m missing something obvious.

 

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts.

This is the terrain underside peeking through.

Try to increase LOD distance in DynDOLOD SkyUI MCM Settings.
Try to generate better quality terrain LOD for Solstheim with xLODGen.
Try to generate better quality terrain underside and/or use higher height setting for Solstheim.
You can change the z-height manually afterwards with xEdit by editing the reference. You get its form ID by clicking the mesh when console is open.

[AriochRN]

Thanks for the reply - after several hours of fiddling it doesn’t appear to be tied to LOD distance (I’ve tried increasing fblockmaximum up to 500,000 and the level 0/1 numbers up without visible difference), I’ve reran xlodgen with 4/8/16/32 levels all set at quality 0, generated underside at quality 0 & height 990 - nothing makes a difference. 

I’ll see if I can do the xEdit thing but a quick look at the mod page makes me think it might be beyond my ability

I don’t see anything similar in mainland Skyrim so I might just have to do my best to ignore it whilst in Solstheim.

[TioDrakul]

16 hours ago, sheson said:

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making problem reports.

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make use full screenshots of the full model with more informative console, both with and without DynDOLOD enabled.

Generating a LOD mod for Skyrim LE with DynDOLOD does not create a DynDOLOD.esm.
Do not install output generated for other game versions.
Make sure the output folder is empty before generating a new LOD patch from scratch.

 

No no, let's be clear here, I said the problem is similar but I didn't generate an "ESM", I correctly followed the instructions to generate an "ESP", which is what Skyrim LE uses and using the LE options of the DynDOLOD 3.0

The problem is as I described. The entire section of the bridge that is composed of the file "winterholdextbridge01.nif" has been moved far below the terrain, the game informs me that the last plugin to modify the related object was Dyndolod and using TSE5Edit I couldn't find out where this modification would be (may be applied via script?).

I also checked the nif file itself in case the problem was in it, but I don't have any other mod changing that nif. I suspect it's related to the problem the other user reported because he had the same result (the object being positioned far below the terrain) but while he uses Skyrim SE I use Skyrim LE. I propose that you have a look at the code you mentioned using as a test of these "large references" to see if it wasn't being activated in the LE version in addition to the SE version, given that what you had mentioned it would do is exactly the problem I'm experiencing.

Edited November 26, 2023 by TioDrakul

[sheson]

9 hours ago, AriochRN said:

Thanks for the reply - after several hours of fiddling it doesn’t appear to be tied to LOD distance (I’ve tried increasing fblockmaximum up to 500,000 and the level 0/1 numbers up without visible difference), I’ve reran xlodgen with 4/8/16/32 levels all set at quality 0, generated underside at quality 0 & height 990 - nothing makes a difference. 

I’ll see if I can do the xEdit thing but a quick look at the mod page makes me think it might be beyond my ability

I don’t see anything similar in mainland Skyrim so I might just have to do my best to ignore it whilst in Solstheim.

Editing the z position of the reference in xEdit is pretty straight forward.

Open DynDOLDO.esp in xEdit and enter DLC2SolstheimWorld_Underside_DynDOLOD_NOLOD into the Editor ID field top left and hit Enter to open up the record.
Then in the right window scroll to the bottom and unfold Data - Position/Rotation, double or right click edit the Position Z entry and set something like -1200.

[sheson]

13 hours ago, TioDrakul said:

No no, let's be clear here, I said the problem is similar but I didn't generate an "ESM", I correctly followed the instructions to generate an "ESP", which is what Skyrim LE uses and using the LE options of the DynDOLOD 3.0

The problem is as I described. The entire section of the bridge that is composed of the file "winterholdextbridge01.nif" has been moved far below the terrain, the game informs me that the last plugin to modify the related object was Dyndolod and using TSE5Edit I couldn't find out where this modification would be (may be applied via script?).

I also checked the nif file itself in case the problem was in it, but I don't have any other mod changing that nif. I suspect it's related to the problem the other user reported because he had the same result (the object being positioned far below the terrain) but while he uses Skyrim SE I use Skyrim LE. I propose that you have a look at the code you mentioned using as a test of these "large references" to see if it wasn't being activated in the LE version in addition to the SE version, given that what you had mentioned it would do is exactly the problem I'm experiencing.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making problem reports.

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make use full screenshots of the full model with more informative console, both with and without DynDOLOD enabled.

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.

Posts are answered based on the actual information given which without the requested logs and screenshots is pretty much none. The requested information is required for qualified troubleshooting to quickly find out the actual cause in this particular case.

Skyrim LE should not use patch files for Skyrim SE.
If it did, the replacement copy to the DynDOLOD.esp is made before moving the original reference below ground.
Hundred other users and I do not have this problem with the current alpha version with Skyrim LE.

[AriochRN]

59 minutes ago, sheson said:

Editing the z position of the reference in xEdit is pretty straight forward.

Open DynDOLDO.esp in xEdit and enter DLC2SolstheimWorld_Underside_DynDOLOD_NOLOD into the Editor ID field top left and hit Enter.
In the bottom of right window unfold Data - Position/Rotation, double or right click edit the Position Z entry and set something like -1200.

Thank you very much for the detailed instructions; I’ve dropped the Z-position to -1200 but unfortunately the underside looks unchanged and is still poking through on Red Mountain & the mainland.

Is it anything to do with the bit in the guide about SkyrimVR terrain LOD meshes being lowered in the distance being baked into a shader? If I look at the volcano and look upwards I can see the problem disappear on the lower slopes in the bottom of my view (the view frustum thing?)

If I’ve read your guides correctly, the underside is used to give more accurate shadows and sun-rays. Skyrim VR doesn’t have volumetric sun-rays so that’s no great loss to me, so I’ve just deleted the underside.nif for Solstheim. I’ve run around the island for an hour and not noticed a massive difference in the shadows so I think this will be the Gordian Knot solution to my problem

Thanks again for your help.

Edited November 27, 2023 by AriochRN

[sheson]

4 hours ago, AriochRN said:

Thank you very much for the detailed instructions; I’ve dropped the Z-position to -1200 but unfortunately the underside looks unchanged and is still poking through on Red Mountain & the mainland.

Is it anything to do with the bit in the guide about SkyrimVR terrain LOD meshes being lowered in the distance being baked into a shader? If I look at the volcano and look upwards I can see the problem disappear on the lower slopes in the bottom of my view (the view frustum thing?)

If I’ve read your guides correctly, the underside is used to give more accurate shadows and sun-rays. Skyrim VR doesn’t have volumetric sun-rays so that’s no great loss to me, so I’ve just deleted the underside.nif for Solstheim. I’ve run around the island for an hour and not noticed a massive difference in the shadows so I think this will be the Gordian Knot solution to my problem

Thanks again for your help.

Then try lower values, like -1500 or -2000 for example.

Yes it is possible that the automatic lowering of terrain LOD could be the cause. It may also be just the usual z-fighting. Other worldspaces cover up terrain LOD with object LOD, not so those far away land masses in Solstheim.

If the underside is not required/desired then simply do not check the option.
If you just do not want to generate the underside for Solstheim add DLC2SolstheimWorld to the ignore list in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini
TerrainUndersideIgnoreWorlds=Blackreach, DLC01SoulCairn, DLC2ApocryphaWorld, ccBGSSSE067DeadlandsWorld, ccKRTSSE001QNWorld, DLC2SolstheimWorld

[Chromatic]

On 11/25/2023 at 2:33 PM, sheson said:

Make sure to use a driver only installation and/or terminate crapware with task manager before testing. For example:
amdfendrsr.exe
atiesrxx.exe
atieclxx.exe
RadeonSoftware.exe
cncmd.exe

Use this test version https://mega.nz/file/MZA2VDoT#1KgtOQa-L74pnMVRCCF1uTsh4ixwTZ08Ezbbc4haBVg, upload new bugreport.txt, log and debug log.

Latest logs: https://ufile.io/iwpf7kqf

[TioDrakul]

8 hours ago, sheson said:

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making problem reports.

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make use full screenshots of the full model with more informative console, both with and without DynDOLOD enabled.

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.

Posts are answered based on the actual information given which without the requested logs and screenshots is pretty much none. The requested information is required for qualified troubleshooting to quickly find out the actual cause in this particular case.

Skyrim LE should not use patch files for Skyrim SE.
If it did, the replacement copy to the DynDOLOD.esp is made before moving the original reference below ground.
Hundred other users and I do not have this problem with the current alpha version with Skyrim LE.

 

I fixed the problem, in a way. I couldn't figure out how or where you set this in the plugin or in the files generated by DynDOLOD, but I noticed that you had mentioned that you had purposely moved the bridge below the terrain and put another object in its place. Where this test of yours would be in Skyrim SE but it also affected my LE version (and I, again, assure you I followed the instructions to generate the plugin for LE, not SE).

But then I thought, if the plug-in moved the object, where would the other object be that should have been put in place? I then discovered that this other object wasn't generated, and that it should be "Data\Meshes\lod\winterhold\winterholdextbridge01_lod.nif". I then created this object manually, placed it where in the directory described above and BAM, problem solved.

[sheson]

On 11/27/2023 at 5:50 PM, TioDrakul said:

 

I fixed the problem, in a way. I couldn't figure out how or where you set this in the plugin or in the files generated by DynDOLOD, but I noticed that you had mentioned that you had purposely moved the bridge below the terrain and put another object in its place. Where this test of yours would be in Skyrim SE but it also affected my LE version (and I, again, assure you I followed the instructions to generate the plugin for LE, not SE).

But then I thought, if the plug-in moved the object, where would the other object be that should have been put in place? I then discovered that this other object wasn't generated, and that it should be "Data\Meshes\lod\winterhold\winterholdextbridge01_lod.nif". I then created this object manually, placed it where in the directory described above and BAM, problem solved.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making problem reports.

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make use full screenshots of the full model with more informative console, both with and without DynDOLOD enabled.

By default DynDOLOD is not doing anything to the vanilla reference for the bridge when running in the TES5 game mode.
When DynDOLOD is running in TES5 game mode, it does not load any patch files for the SSE game mode.
The cause of the problem will be most likely something else entirely.
Making manual edits to generated files or patches is not really solving the cause of the problem.
Making baseless assumptions without having any understanding how anything works is not going to help with finding the actual cause of problems. Proper troubleshooting with the help of the log files and screenshots is.

Do not use DynDOLOD and do not participate in the alpha test until you are able to meet the requirements to do so which includes being able to provide repeatedly requested logs and screenshots so the problem can be properly troubleshooted and solved.

[sheson]

2 hours ago, Chromatic said:

Latest logs: https://ufile.io/iwpf7kqf

Thanks. RIght now here is what I am seeing: it reserves memory for a texture with X*Y resolution, and a few milliseconds later asks for the X*Y of the reserved memory and at some point the values returned are wrong, while everything worked perfectly fine for the same texture several times before for the earlier worldspaces.

So this seems to be something random. Can you double check that there are no instabilities caused by CPU overclocking, memory timings, other BIOS settings etc?
Can you double check main and video memory usage while the tool runs. Maybe really close everything else, including browsers and whatever else might be using video memory.

Run this test version https://mega.nz/file/9FYRHZ5C#dNqoWMpDrH9LRN1nmGq5Brwnjo29MjQ9eBmVTn4GieY and upload new bugreport.txt, log and debug log.

[S-Matrix]

Hello, currently getting repeated crashes while attempting to cross the estuary separating Solitude from the marshes north of Morthal. Using Alpha-156.
Here's the crashlog https://pastebin.com/sWkypg9V where DynDOLOD is being pointed to, and the corresponding DynDOLOD generation logs are attached. As always, thanks for all your hard work.

EDIT: Forgot debug log, uploading now and will post it here.
EDIT 2: Here's the debug log https://ufile.io/vzz9bnx8

DynDOLOD_SSE_log.txt

Edited November 28, 2023 by S-Matrix

[sheson]

7 hours ago, S-Matrix said:

Hello, currently getting repeated crashes while attempting to cross the estuary separating Solitude from the marshes north of Morthal. Using Alpha-156.
Here's the crashlog https://pastebin.com/sWkypg9V where DynDOLOD is being pointed to, and the corresponding DynDOLOD generation logs are attached. As always, thanks for all your hard work.

EDIT: Forgot debug log, uploading now and will post it here.
EDIT 2: Here's the debug log https://ufile.io/vzz9bnx8

DynDOLOD_SSE_log.txt 1.84 MB · 0 downloads

What the crash log seems to point to is Architecture\Solitude\SBlackSmith.nif which is used by the mentioned references and base records defined or overwritten by DynDOLOD plugins.

Test if the NIF opens in NifSkope, run it through CAO or try removing or replacing it.

If you found that the NIF really causes the crash and it comes that way with a mod, then upload the NIF as is.

[S-Matrix]

4 hours ago, sheson said:

What the crash log seems to point to is Architecture\Solitude\SBlackSmith.nif which is used by the mentioned references and base records defined or overwritten by DynDOLOD plugins.

Test if the NIF opens in NifSkope, run it through CAO or try removing or replacing it.

If you found that the NIF really causes the crash and it comes that way with a mod, then upload the NIF as is.

Hi sheson, thanks for the reply - as per your suggestion I checked to make sure the mesh would open properly in NifSkope, and it did indeed do so.

Next, using MO2's "Data" tab, I was able to see each mod in my load order that was contributing a version of the mesh; the one provided by "Flickering Meshes Fix" was the overriding version, so I isolated and then deactivated that file from the mod, and returned to the problem area, but the issue persisted. Before trying CAO, I decided to try removing the version of the mesh provided by "Assorted Mesh Fixes", which was next in line in terms of override/use by the game, but the crash still occurred. I repeated the process one last time with the "Landscape and Water Fixes" version of the mesh, mostly as a sanity check - alas: crash.

Honestly, I'm not the most knowledgeable about troubleshooting mesh issues, especially with a completed DynDOLOD output in the mix, so this was mostly just me trying to brute force possible resolutions without being able to parse/tinker with the DynDOLOD output itself. While it yielded no results on my end, maybe this info can help with your more seasoned diagnosis. It indicates to me (and again, I'm pretty inexperienced) that the construction of the mesh itself isn't the root cause of the crash, since even across multiple different versions of the mesh, sblacksmith.nif still appears in the crashlog.

If it does end up being related to DynDOLOD, would I need to regenerate LOD in order to test solutions? Is there a "mini-run" I can do, localized to the Solitude region, to save on generation time, in that case? Let me know if anything jumps out about the issue, or if there's some other things I can try in the meantime. Thanks!

[sheson]

27 minutes ago, S-Matrix said:

Hi sheson, thanks for the reply - as per your suggestion I checked to make sure the mesh would open properly in NifSkope, and it did indeed do so.

Next, using MO2's "Data" tab, I was able to see each mod in my load order that was contributing a version of the mesh; the one provided by "Flickering Meshes Fix" was the overriding version, so I isolated and then deactivated that file from the mod, and returned to the problem area, but the issue persisted. Before trying CAO, I decided to try removing the version of the mesh provided by "Assorted Mesh Fixes", which was next in line in terms of override/use by the game, but the crash still occurred. I repeated the process one last time with the "Landscape and Water Fixes" version of the mesh, mostly as a sanity check - alas: crash.

Honestly, I'm not the most knowledgeable about troubleshooting mesh issues, especially with a completed DynDOLOD output in the mix, so this was mostly just me trying to brute force possible resolutions without being able to parse/tinker with the DynDOLOD output itself. While it yielded no results on my end, maybe this info can help with your more seasoned diagnosis. It indicates to me (and again, I'm pretty inexperienced) that the construction of the mesh itself isn't the root cause of the crash, since even across multiple different versions of the mesh, sblacksmith.nif still appears in the crashlog.

If it does end up being related to DynDOLOD, would I need to regenerate LOD in order to test solutions? Is there a "mini-run" I can do, localized to the Solitude region, to save on generation time, in that case? Let me know if anything jumps out about the issue, or if there's some other things I can try in the meantime. Thanks!

Make sure to enable archive parsing in MO2 Settings, tab Workarounds.
Once you are down to the Unofficial Patch or the vanilla Meshes0.bsa for the NIF, we can probably assume that the NIF is OK.

In that case start xEdit and load the entire load order. Then enter 1D0422B9 in the form ID field top left and hit enter so the right window shows the record. In case DynDOLOD.esm is not loaded at load order 1D, adjust the first two digits accordingly to what is shown in the left tree view for DynDOLOD.esm.
Scroll to the very right and make a screenshot. If necessary also scroll down and make more screenshots.
Repeat with form ID 0008618F
Upload those screenshots.