DynDOLOD 3.00 Alpha 180

[vengas2346]

1 hour ago, sheson said:

Use the latest version DynDOLOD 3 Alpha 95 as explained on the first post. This has been fixed in DynDOLOD 3 Alpha 93 back in early June.

Well, now i feel really stupid. Sorry for wasting your time...

[Blackread]

I'm getting a large ref flickering bug on a nordic ruin object. LODs were generated with the latest DynDOLOD 3 Alpha 95. The reference in question is 372BA which is one of the large arches outside Ragnvald in The Reach.

According to xEdit the reference is added in Skyrim.esm and not edited by anything else in my load order.

DynDOLOD reported zero large ref bugs (or any issues for that matter) after being run. Any idea what might be causing this issue? The LOD unloads when the object enters uGridsToLoad, but when it's in the large ref LOD grid the bug manifests. Here are the logs for the last DynDOLOD run:

Last DynDOLOD Log

DynDOLOD Debug Log

Edited August 15, 2022 by Blackread

[skinjack]

Hi sheson,

I'm having an issue generating DynDOLOD after my TexGen ran successfully. My log.txt tells me "Error: No TexGen output detected. Consider generating updated object LOD textures with TexGen first." But I'm literally staring at it in my OutPut folder. After a few hours of banging my head against the wall I know when I've reached the limits of what I think could be wrong.

I have the current Resources and Alpha installed, I just don't understand why DynDOLOD is not recognizing the TexGen Output. It originally started tonight by saying that there were numerous LOD's missing and progressed to not recognizing them at all. I have not changed any of my executable paths in MO2. Any idea what could be going on? I'm attaching my logs. There is no bugreport from the latest runs.

DynDOLOD_SSE_Debug_log.txt DynDOLOD_SSE_log.txt TexGen_SSE_log.txt

[sheson]

3 hours ago, skinjack said:

Hi sheson,

I'm having an issue generating DynDOLOD after my TexGen ran successfully. My log.txt tells me "Error: No TexGen output detected. Consider generating updated object LOD textures with TexGen first." But I'm literally staring at it in my OutPut folder. After a few hours of banging my head against the wall I know when I've reached the limits of what I think could be wrong.

I have the current Resources and Alpha installed, I just don't understand why DynDOLOD is not recognizing the TexGen Output. It originally started tonight by saying that there were numerous LOD's missing and progressed to not recognizing them at all. I have not changed any of my executable paths in MO2. Any idea what could be going on? I'm attaching my logs. There is no bugreport from the latest runs.

DynDOLOD_SSE_Debug_log.txt 271.1 kB · 0 downloads DynDOLOD_SSE_log.txt 167.85 kB · 0 downloads TexGen_SSE_log.txt 349.11 kB · 0 downloads

Install the contents of the output path or the *.zip archive as a mod. It should overwrite everything. Consider moving the zip archive to the mod managers download folder for later re-use.

The OS returns "file not found" when DynDOLOD checks the data folder for an INI file that is part of the TexGen Output.
There is nothing DynDOLOD can do about the OS  function returning file not found for a file path one way or the other.

If there are seemingly weird file access errors, check Windows UAC, Antivir etc. is not interfering. With MO2,  restarting it or rebooting the PC helps in case background processes keep the virtual file systems running for older load orders and things acting odd.

[sheson]

6 hours ago, Blackread said:

I'm getting a large ref flickering bug on a nordic ruin object. LODs were generated with the latest DynDOLOD 3 Alpha 95. The reference in question is 372BA which is one of the large arches outside Ragnvald in The Reach.

According to xEdit the reference is added in Skyrim.esm and not edited by anything else in my load order.

DynDOLOD reported zero large ref bugs (or any issues for that matter) after being run. Any idea what might be causing this issue? The LOD unloads when the object enters uGridsToLoad, but when it's in the large ref LOD grid the bug manifests. Here are the logs for the last DynDOLOD run:

Last DynDOLOD Log

DynDOLOD Debug Log

https://dyndolod.info/Help/Large-References
Large reference bugs describe the issue that the object LOD for all large references of a cell is not disabled when the full models for the large references are loaded. Their LOD stays enabled as usual until the active exterior cells attach and all LOD is disabled. Again, the entire cell is affected, regardless of the model used by the large reference or its type.

For example, If a large references being overwritten by ESP, it means that the large reference being overwritten is not large anymore and only loads insides the uGridsToLoad and does not flicker. All other large references that are still loading in the uLargeRefLODGridSize and have object LOD flicker.

DynDOLOD reports some references that cause large reference bugs in the debug log only. Some causes are not reported at all.

I can find this in the debug log for the cell:

[01.38] [BuildReferences] <Debug: Initially disabled large reference in Nordic Ruins of Skyrim.esp [REFR:000372E6] (places NorTempleExteriorRibFree03 [STAT:00022F21] in GRUP Cell Temporary Children of RagnvaldExterior05 [CELL:000070E0] (in Tamriel "Skyrim" [WRLD:0000003C] at -43,6))>
[01.43] [BuildReferences] <Debug: Initially disabled large reference in Nordic Ruins of Skyrim.esp [REFR:00082246] (places NorTempleExteriorRibFree05 [STAT:00022F20] in GRUP Cell Temporary Children of RagnvaldExterior05 [CELL:000070E0] (in Tamriel "Skyrim" [WRLD:0000003C] at -43,6))>
[07.42] [FixLargeReferences] <Notice: Converted permanently Initially Disabled large reference Nordic Ruins of Skyrim.esp [REFR:000372E6] (places NorTempleExteriorRibFree03 [STAT:00022F21] in GRUP Cell Temporary Children of RagnvaldExterior05 [CELL:000070E0] (in Tamriel "Skyrim" [WRLD:0000003C] at -43,6))>
[07.42] [FixLargeReferences] <Notice: Converted permanently Initially Disabled large reference Nordic Ruins of Skyrim.esp [REFR:00082246] (places NorTempleExteriorRibFree05 [STAT:00022F20] in GRUP Cell Temporary Children of RagnvaldExterior05 [CELL:000070E0] (in Tamriel "Skyrim" [WRLD:0000003C] at -43,6))>

Those 2 references could be the cause, maybe the fix fails for some reasons. Check what plugin makes them initially disabled. Test if vanilla game with only this plugin has large reference bugs, then run DynDOLOD on this minimal test setup to see what happens.

[Blackread]

1 hour ago, sheson said:

https://dyndolod.info/Help/Large-References
Large reference bugs describe the issue that the object LOD for all large references of a cell is not disabled when the full models for the large references are loaded. Their LOD stays enabled as usual until the active exterior cells attach and all LOD is disabled. Again, the entire cell is affected, regardless of the model used by the large reference or its type.

For example, If a large references being overwritten by ESP, it means that the large reference being overwritten is not large anymore and only loads insides the uGridsToLoad and does not flicker. All other large references that are still loading in the uLargeRefLODGridSize and have object LOD flicker.

DynDOLOD reports some references that cause large reference bugs in the debug log only. Some causes are not reported at all.

I can find this in the debug log for the cell:

[01.38] [BuildReferences] <Debug: Initially disabled large reference in Nordic Ruins of Skyrim.esp [REFR:000372E6] (places NorTempleExteriorRibFree03 [STAT:00022F21] in GRUP Cell Temporary Children of RagnvaldExterior05 [CELL:000070E0] (in Tamriel "Skyrim" [WRLD:0000003C] at -43,6))>
[01.43] [BuildReferences] <Debug: Initially disabled large reference in Nordic Ruins of Skyrim.esp [REFR:00082246] (places NorTempleExteriorRibFree05 [STAT:00022F20] in GRUP Cell Temporary Children of RagnvaldExterior05 [CELL:000070E0] (in Tamriel "Skyrim" [WRLD:0000003C] at -43,6))>
[07.42] [FixLargeReferences] <Notice: Converted permanently Initially Disabled large reference Nordic Ruins of Skyrim.esp [REFR:000372E6] (places NorTempleExteriorRibFree03 [STAT:00022F21] in GRUP Cell Temporary Children of RagnvaldExterior05 [CELL:000070E0] (in Tamriel "Skyrim" [WRLD:0000003C] at -43,6))>
[07.42] [FixLargeReferences] <Notice: Converted permanently Initially Disabled large reference Nordic Ruins of Skyrim.esp [REFR:00082246] (places NorTempleExteriorRibFree05 [STAT:00022F20] in GRUP Cell Temporary Children of RagnvaldExterior05 [CELL:000070E0] (in Tamriel "Skyrim" [WRLD:0000003C] at -43,6))>

Those 2 references could be the cause, maybe the fix fails for some reasons. Check what plugin makes them initially disabled. Test if vanilla game with only this plugin has large reference bugs, then run DynDOLOD on this minimal test setup to see what happens.

Thank you, it seems I misunderstood how the large reference bug works. I tried a vanilla game with just that one plugin enabled, and I didn't see any LOD unloading issues with that object. Then I ran DynDOLOD against that load order and the problem returned.

However, now that I better understand how the large ref bug manifests I took a look at some other objects in the cell, and for example these stairs are in the same cell, and a large reference I believe, but do not have any such issues. The LOD on the side is there as it should, since the smaller side parts aren't large refs, and the mid part does not have its LOD model displayed as expected. I disabled the object in console to make sure the LOD wasn't hidden underneath.

So I guess this isn't actually a large ref bug, but something else?

Here are the logs again:

https://ufile.io/f/m0uug Both logs behind the same folder link.

This time DynDOLOD did warn about deleted references, as I didn't have the cleaned vanilla plugins active, and about one missing script file, which presumably is fixed by USSEP.

[Blackread]

Looks like I solved the issue. It was caused by the Nordic Ruins of Skyrim.esp having an exact duplicate of the object placed in the same spot, so the LOD I was seeing was generated for this duplicate, which wasn't a large reference. Thank you for your help once again!

[sheson]

45 minutes ago, Blackread said:

Looks like I solved the issue. It was caused by the Nordic Ruins of Skyrim.esp having an exact duplicate of the object placed in the same spot, so the LOD I was seeing was generated for this duplicate, which wasn't a large reference. Thank you for your help once again!

Can you tell me the form ID of the duplicate? Maybe it is something that can be discovered and reported or dealt with automatically.

[Blackread]

53 minutes ago, sheson said:

Can you tell me the form ID of the duplicate? Maybe it is something that can be discovered and reported or dealt with automatically.

Sure, it's xx000D62.

[sheson]

2 hours ago, Blackread said:

Sure, it's xx000D62.

Thanks, that really has exactly the same position and everything.

[skinjack]

Hi again, sheson,

So unless I am misunderstanding your instructions, you are saying put whatever generates in the Textures_Output folder (in the DynDOLOD folder) into a mod similarly named in MO2. Which is what I do. I have one for TexGen_Output and one for DynDOLOD_ Output.

I restarted my computer this morning and I am still getting the same error, so that wasn't the issue. I've never had issue with the UAC or AntiVirus affecting it, but that doesn't mean things haven't changed. I have TexGen and DynDOLOD.exe whitelisted in my antivirus so I don't know that it would be the cause anyway. But I'm not sure how to tell if the UAC is interfering. How do you do that? Without having to change the account settings for everything? Should I run it as an administrator?

EDIT: Never mind the administrator part. It won't let me unless I run MO2 that way as well, and I'm 95% sure I read a warning against doing that somewhere.

Edited August 15, 2022 by skinjack

[sheson]

59 minutes ago, skinjack said:

Hi again, sheson,

So unless I am misunderstanding your instructions, you are saying put whatever generates in the Textures_Output folder (in the DynDOLOD folder) into a mod similarly named in MO2. Which is what I do. I have one for TexGen_Output and one for DynDOLOD_ Output.

I restarted my computer this morning and I am still getting the same error, so that wasn't the issue. I've never had issue with the UAC or AntiVirus affecting it, but that doesn't mean things haven't changed. I have TexGen and DynDOLOD.exe whitelisted in my antivirus so I don't know that it would be the cause anyway. But I'm not sure how to tell if the UAC is interfering. How do you do that? Without having to change the account settings for everything? Should I run it as an administrator?

EDIT: Never mind the administrator part. It won't let me unless I run MO2 that way as well, and I'm 95% sure I read a warning against doing that somewhere.

I suggest to first check if some key files have been created and are installed properly. https://dyndolod.info/Messages/TexGen-Output#No-TexGen-output-detected

Do not change the folder structure of the content of the TexGen output folder when installing it as a mod. E.g. the folder "textures" needs to end up in the (virtual) ..\data\textures\ folder of the game. Use the zip output option, then use the mod manager to install the zip as any other mod.

Use the MO2 right windows data tab to make sure the files exist in the (virtual) data folder:
..\textures\DynDOLOD\LOD\version.ini
..\textures\DynDOLOD\LOD\TexGen.ini

[skinjack]

I got it to run once, but it errored on a REFR from one of the mods. Tracking that down now with the author. Hopefully he responds. Still have no idea what was special about this morning or what I changed that might have gotten it to run. It failed twice, then ran the third time... Mondays....

EDIT: I disabled that patch for now (Ancient Land - CG4 Trees Patch.esp) and DynDOLOD ran all the way through. So I can at least run the game to see what kinds of issues I have now. I just upgraded to AE, but downgraded the Skyrim.exe and binkw64.dll back to 1.5.97.

Edited August 15, 2022 by skinjack

[Mertz]

21 hours ago, sheson said:

Unfortunately, the log and debug log from DynDOLOD both only show loading and the being stopped at applying patches at the start.

Understood. I'll revisit the documentation again and see what I need to do in order to capture a better debug log for you if I can reproduce the issue. See below.

21 hours ago, sheson said:

I suggest to use the Adrenalin 22.5.1 Recommended (WHQL) and not any of the optional newer drivers that still seem to contain bugs. If I understand it correctly the OpenGL driver was rewritten from the ground up, hopefully the cause of the problem is going to be fixed  in the near future.

If you have actual log and debug log with the error then upload anyway. There more I can collect of these the higher the chance I might be able to do a workaround.

I ran several tests this morning with both RenderDoc and the AMD GPU profiler running to try to capture the OpenGL compute shader that is executing when the bugcheck occurs.  I was going to submit a bug report to AMD but alas as fate would have it, I got four complete runs without the bugcheck occurring again on the AMD 2022.8.1 driver.

If I can reproduce the error again reliably I'll run the same procedure again and share it with you before submitting a bug report to AMD.

I'd also like to try it again with Mesa Injector running to force everything onto the CPU just to test. I'd like to try to eliminate buggy game assets before concluding it has anything to do with DynDOLOD or the AMD driver.

 

21 hours ago, sheson said:

Typically do not disable any plugins - including the Bashed Patch. This warning is just in case someone still uses an old version of Wrye Bash that created broken plugins.

Yep I'm on the Bash dev team, mostly testing these days due to RL work. I'm running the Bash 311 nightly builds. I disabled the Bashed Patch to eliminate unknown variables.

Edited August 15, 2022 by Mertz

[sheson]

49 minutes ago, Mertz said:

Understood. I'll revisit the documentation again and see what I need to do in order to capture a better debug log for you if I can reproduce the issue.

When the program is closed, the normal log is appended to, the debug is replaced. So in case of error, rename debug log to keep it.