DynDOLOD 3.00 Alpha 173

[sheson]

1 hour ago, 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

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.7z

Edited August 14, 2022 by Mertz

[vengas2346]

1 hour ago, 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.

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 TexGen_SSE_log.txt DynDOLOD_SSE_Debug_log.txt TexGen_SSE_Debug_log.txt bugreport.txt

[sheson]

1 hour ago, 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

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.

55 minutes ago, 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

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]

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