DynDOLOD 3.00 Alpha 190

[primem0ver]

  On 8/14/2022 at 5:08 AM, sheson said:

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

If there is an error prompt, clock on "Click on this link for additional explanations and help for this message"  as explained on the first post.

Expand  

I had to redo the entire build because not everything was made correctly due to a crash caused by music files I didn't mean to include in my load order.  So it appears there might be a "pattern" after all.  The same errors repeat once per build session but it seems to not repeat any of these errors in the session.  (By session I mean a single set of built attempts until I get the output).  So here is the first crash.  I will add more to this post for each crash.  The logs and an image of the crash are in each report.

 

Crash1.zipFetching info...

Edited August 14, 2022 by primem0ver

[sheson]

  On 8/14/2022 at 9:41 AM, primem0ver said:

I had to redo the entire build because not everything was made correctly due to a crash caused by music files I didn't mean to include in my load order.  So it appears there might be a "pattern" after all.  The same errors repeat once per build session but it seems to not repeat any of these errors in the session.  (By session I mean a single set of built attempts until I get the output).  So here is the first crash.  I will add more to this post for each crash.  The logs and an image of the crash are in each report.

 

Crash1.zip 213.39 kB · 0 downloads

Expand  

The zip doesn't contain the DynDOLOD log or the debug log but thankfully the bugreport.txt. See if using the test version from this post https://stepmodifications.org/forum/topic/16796-dyndolod-3-alpha-95/?do=findComment&comment=261075 fixes it.

Note for future reference: use the "Copy message to clipboard" and paste the text instead of making a screenshot as explained on the first post.

[primem0ver]

  On 8/14/2022 at 10:02 AM, sheson said:

The zip doesn't contain the DynDOLOD log or the debug log but thankfully the bugreport.txt. See if using the test version from this post https://stepmodifications.org/forum/topic/16796-dyndolod-3-alpha-95/?do=findComment&comment=261075 fixes it.

Note for future reference: use the "Copy message to clipboard" and paste the text instead of making a screenshot as explained on the first post.

Expand  

Sorry about not including the "Copy Message to Clipboard".  I didn't here either until Crash4.  I have been including the logs that have been written to when the errors occured (based on timestamp).  So the reason the others were left out was because they weren't updated... probably because I didn't exit Dyndolod when making the copies (write buffer wasn't cleared/file updated).   I have included the requested files this time in Crash3 and Crash4.  The fourth file is too big to upload here so you can get it here.  I will try your linked version on my next attempt.

EDIT:
The issue might have something to do with having Bashed Patch,0.esp being enabled... or not.  Not sure.  It was disabled for times that it worked (at least the most recent ones).

 

 

Crash2.zipFetching info... Crash3.7zFetching info...

Edited August 14, 2022 by primem0ver

[sheson]

  On 8/14/2022 at 11:15 AM, primem0ver said:

Sorry about not including the "Copy Message to Clipboard".  I didn't here either until Crash4.  I have been including the logs that have been written to when the errors occured (based on timestamp).  So the reason the others were left out was because they weren't updated... probably because I didn't exit Dyndolod when making the copies (write buffer wasn't cleared/file updated).   I have included the requested files this time in Crash3 and Crash4.  The fourth file is too big to upload here so you can get it here.  I will try your linked version on my next attempt.

EDIT:
The issue might have something to do with having Bashed Patch,0.esp being enabled... or not.  Not sure.  It was disabled for times that it worked (at least the most recent ones).

 

 

Crash2.zip 232.76 kB · 0 downloads Crash3.7z 3.39 MB · 0 downloads

Expand  

https://dyndolod.info/Generation-Instructions#Prerequisites explains to clean and error check with xEdit prior prior to generating. It also explain to pay attention to log messages when generating.

See https://dyndolod.info/Messages for explanations.  Pay attention to the Summary that opens at the end https://dyndolod.info/Help/Summary-Of-Messages and click through all categories and read their explanations.

Clean all mods that have deleted references, in particular in CoreLocationsStandard.esp, which might be relevant to the error message but should be fixed either way. https://dyndolod.info/Messages/Deleted-Reference

The Unresolved FormID errors in CoreLocationsStandard.esp might be relevant to the error message  but should be fixed either way. https://dyndolod.info/Messages/Unresolved-Form-ID
The mod also seems to be missing a lot of assets.

CoreHybridMerge.esp seems also missing a lot of assets. Seems like a problem with missing/merging the BSAs of the mods that are being merged.

[vengas2346]

Hey, im currently facing a problem at the end of my modlist creation. Running Dyndolod i get these warnings for Outdated Billboards. I read through this https://dyndolod.info/Messages/Outdated-Billboards, however im running Dyndolod directly after my Texgen creation without changing anything and its still the same. 

 

Edit: should probably mention i use QW's Grass Patch 2 and the RootBlock warnings i posted just incase however i read they can be ignored for grass mods

These are my Texgen settings:  

  Reveal hidden contents

And here an example that i do have these textures installed:

  Reveal hidden contents

 

DynDOLOD_Summary_OutdatedBillboards.htmlFetching info... DynDOLOD_Summary_RootBlock.htmlFetching info...

Edited August 14, 2022 by vengas2346

[sheson]

  On 8/14/2022 at 3:44 PM, vengas2346 said:

Hey, im currently facing a problem at the end of my modlist creation. Running Dyndolod i get these warnings for Outdated Billboards. I read through this https://dyndolod.info/Messages/Outdated-Billboards, however im running Dyndolod directly after my Texgen creation without changing anything and its still the same. 

 

Edit: should probably mention i use QW's Grass Patch 2 and the RootBlock warnings i posted just incase however i read they can be ignored for grass mods

 

DynDOLOD_Summary_OutdatedBillboards.html 4.56 kB · 1 download DynDOLOD_Summary_RootBlock.html 7.14 kB · 0 downloads

Expand  

Read the first post which log and debug log to upload when making posts. In this case it should be both for TexGen and DynDOLOD.

Check the TexGen log if it actually creates billboards for the grasses mentioned in the message about outdated billboards. Maybe they are from an older generation or mod.

Make sure to read the explanations for outdated billboards at https://dyndolod.info/Messages/Outdated-Billboards.
The messages says current NIF does not seem to use the mentioned texture. It does not say the mentioned texture is missing.
When the billboard dds/txt were created the NIF used the mentioned texture. Double check the current NIF in NifSkope or xEdit Asset Browser what textures it actually uses.
Compare the billboards to how the models look in NifSkope (might need to disable vertex alpha shader flag to "properly" see them).

As the https://dyndolod.info/Messages/Root-Block explanations says, grasses are not used for dynamic LOD. The LOD models from the manny mod are a different story.  They could be.

[Mertz]

I'm also getting the OpenGL bugcheck on the newest AMD RDNA2 (22.8.1) drivers. I have a hunch as to what is going on.

I originally had a more detailed post with the exact texture atlas that was being processes when the bugcheck was raised, but I suck at keyboards and accidentally closed the tab.

I'll try to be as brief as possible. 

In summary it was processing Solstheim World when it the main thread stopped and threw:

Error: OpenGL: invalid operation while processing 602A829C.

I've attached my bug dump and the entirety of my ./Logs directory. I've also added a file with the clipboard contents and a DXDiag log to this post.

So what changed on AMD cards?

AMD just updated their OpenGL drivers in mid-July in their 22.7.1 driver. This is the first time I've run alpha .95 with the new (now 22.8.1) drivers.

The release notes on 22.7.1 are vague in what was changed but can be found here: https://www.amd.com/en/support/kb/release-notes/rn-rad-win-22-7-1

Steps to reproduce aka my usual process:

1. Disable bashed patch in Bash
2. Run "monitor external installation" in Bash and leave it running in the background
3. Run xLODGen .94 to generate .btr  & close
4. Switch back to Bash and create a new project for the xLODGen output.  Zip output.
5. Install xLODGen output.
6. Close Bash
7. Start TexGenx64 SSE and generate. Zip and close.
8. Install texgen_output in Bash.
9. Close Bash
10. Run DynDOLODx64 SSE. Zip and close.

Thanks for your hard work on DynDOLOD and please let me know if there's any other information or testing I can provide for you.

P.S. I'm currently generating LOD without SolstheimWorld enabled. I'll update this post if I can reproduce the bugcheck without it.

Update: can reproduce even without SolsthemWorld.

Mertz_Beermotor_20220814-DynDOLOD3a95_bugreport.7zFetching info...

Edited August 14, 2022 by Mertz

[vengas2346]

  On 8/14/2022 at 4:51 PM, sheson said:

Read the first post which log and debug log to upload when making posts. In this case it should be both for TexGen and DynDOLOD.

Check the TexGen log if it actually creates billboards for the grasses mentioned in the message about outdated billboards. Maybe they are from an older generation or mod.

Make sure to read the explanations for outdated billboards at https://dyndolod.info/Messages/Outdated-Billboards.
The messages says current NIF does not seem to use the mentioned texture. It does not say the mentioned texture is missing.
When the billboard dds/txt were created the NIF used the mentioned texture. Double check the current NIF in NifSkope or xEdit Asset Browser what textures it actually uses.
Compare the billboards to how the models look in NifSkope (might need to disable vertex alpha shader flag to "properly" see them).

As the https://dyndolod.info/Messages/Root-Block explanations says, grasses are not used for dynamic LOD. The LOD models from the manny mod are a different story.  They could be.

Expand  

Hey sheson, i have to apologize, i have not read the first page. Here are my uploaded logs.

I did a search in the TexGen log and it seems to create the billboards for the grass nifs. I can confirm this by actually finding the .dds files in my TexGen Output.

As far as comparing them to the Nifskope model, here is an image of the actual grass nif model in Nifskope  

I also found a text file inside my TexGen Output for this specific model and it seems like the texture path is leading to a temporary file, i assume a fallback dyndolod texture?

If there is anything else missing let me know.

DynDOLOD_SSE_log.txtFetching info... TexGen_SSE_log.txtFetching info... DynDOLOD_SSE_Debug_log.txtFetching info... TexGen_SSE_Debug_log.txtFetching info... bugreport.txtFetching info...

[sheson]

  On 8/14/2022 at 5:23 PM, Mertz said:

I'm also getting the OpenGL bugcheck on the newest AMD RDNA2 (22.8.1) drivers. I have a hunch as to what is going on.

I originally had a more detailed post with the exact texture atlas that was being processes when the bugcheck was raised, but I suck at keyboards and accidentally closed the tab.

I'll try to be as brief as possible. 

In summary it was processing Solstheim World when it the main thread stopped and threw:

Error: OpenGL: invalid operation while processing 602A829C.

I've attached my bug dump and the entirety of my ./Logs directory. I've also added a file with the clipboard contents and a DXDiag log to this post.

So what changed on AMD cards?

AMD just updated their OpenGL drivers in mid-July in their 22.7.1 driver. This is the first time I've run alpha .95 with the new (now 22.8.1) drivers.

The release notes on 22.7.1 are vague in what was changed but can be found here: https://www.amd.com/en/support/kb/release-notes/rn-rad-win-22-7-1

Steps to reproduce aka my usual process:

1. Disable bashed patch in Bash
2. Run "monitor external installation" in Bash and leave it running in the background
3. Run xLODGen .94 to generate .btr  & close
4. Switch back to Bash and create a new project for the xLODGen output.  Zip output.
5. Install xLODGen output.
6. Close Bash
7. Start TexGenx64 SSE and generate. Zip and close.
8. Install texgen_output in Bash.
9. Close Bash
10. Run DynDOLODx64 SSE. Zip and close.

Thanks for your hard work on DynDOLOD and please let me know if there's any other information or testing I can provide for you.

P.S. I'm currently generating LOD without SolstheimWorld enabled. I'll update this post if I can reproduce the bugcheck without it.

Update: can reproduce even without SolsthemWorld.

Mertz_Beermotor_20220814-DynDOLOD3a95_bugreport.7z 613.23 kB · 0 downloads

Expand  

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

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.

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.

  On 8/14/2022 at 6:26 PM, vengas2346 said:

Hey sheson, i have to apologize, i have not read the first page. Here are my uploaded logs.

I did a search in the TexGen log and it seems to create the billboards for the grass nifs. I can confirm this by actually finding the .dds files in my TexGen Output.

As far as comparing them to the Nifskope model, here is an image of the actual grass nif model in Nifskope  

I also found a text file inside my TexGen Output for this specific model and it seems like the texture path is leading to a temporary file, i assume a fallback dyndolod texture?

If there is anything else missing let me know.

DynDOLOD_SSE_log.txt 1.11 MB · 0 downloads TexGen_SSE_log.txt 260.98 kB · 0 downloads DynDOLOD_SSE_Debug_log.txt 255.91 kB · 0 downloads TexGen_SSE_Debug_log.txt 1.22 MB · 0 downloads bugreport.txt 88.3 kB · 0 downloads

Expand  

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.

[vengas2346]

  On 8/14/2022 at 6:45 PM, 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.

Expand  

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.txtFetching info... DynDOLOD_SSE_log.txtFetching info... TexGen_SSE_log.txtFetching info...

[sheson]

  On 8/15/2022 at 2:55 AM, 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

Expand  

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]

  On 8/15/2022 at 12:35 AM, 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

Expand  

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]

  On 8/15/2022 at 6:16 AM, 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.

Expand  

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.