DynDOLOD 3.00 Alpha 169

[sheson]

11 minutes ago, DudeGuy said:

Ah sorry about that I was assuming the debug log was only for issues with TextGen.

Here it is:
https://ufile.io/cb4gun3z

Thanks for the quick response. 

Terminate whatever crapware installed with the graphics card driver before running any of the tools or do a clean reinstall of the graphic card driver without any of the crapware.

[DudeGuy]

7 minutes ago, sheson said:

Terminate whatever crapware installed with the graphics card driver or do a clean reinstall of the graphic card driver without any of the crapware.

Ok I will go ahead and do what you suggested above and then do a clean reinstall of my graphics driver.

How would you recommend I get rid of crapware? 
Would using DDU be the best way?
https://www.guru3d.com/files-details/display-driver-uninstaller-download.html

Sorry for all the questions I'm you get this a lot.

[sheson]

21 minutes ago, DudeGuy said:

Ok I will go ahead and do what you suggested above and then do a clean reinstall of my graphics driver.

How would you recommend I get rid of crapware? 
Would using DDU be the best way?
https://www.guru3d.com/files-details/display-driver-uninstaller-download.html

Sorry for all the questions I'm you get this a lot.

You might want to try terminating the crapware and then running the tool(s) and using the linked test version etc. first.

How to best to do a clean driver installation would be something to ask on a AMD/Windows etc. support forum. There seems to be an influx of new issues potentially caused either by changes with drivers, unneeded software or changes in the OS, while the way the tools work is still the same as it was a couple years ago.

[Terminetwork]

Greetings Sheson, i wanted to ask an opinion on an issue i was having with Dyndolod 3 Alpha-122 (the one available on the Nexus). After following throughly the Open Cities guide and a reddit post with a similar situation,  I keep having a part of Dragonsreach building in Whiterun invisible, the LOD is fine but the building when i get close disappears. Here are some pictures of my issue.

I have read the first post and managed to find both the bugreport.txt and DynDOLOD_TES5_Debug_log.txt but not sure what other debug file i should send since i have 117 total in the Logs folder. Pheraps Whiterun or Tamriel log files?

And sorry but what is a text sharing service?

I apologize for the disturb, i tried my best but couldn't make everything work as this is my first time with DynDOLOD, i don't have many hopes but since i found you active here i thought i could give this thread a try.

Edited April 3, 2023 by Terminetwork

[sheson]

2 hours ago, Terminetwork said:

Greetings Sheson, i wanted to ask an opinion on an issue i was having with Dyndolod 3 Alpha-122 (the one available on the Nexus). After following throughly the Open Cities guide and a reddit post with a similar situation,  I keep having a part of Dragonsreach building in Whiterun invisible, the LOD is fine but the building when i get close disappears. Here are some pictures of my issue.

I have read the first post and managed to find both the bugreport.txt and DynDOLOD_TES5_Debug_log.txt but not sure what other debug file i should send since i have 117 total in the Logs folder. Pheraps Whiterun or Tamriel log files?

And sorry but what is a text sharing service?

I apologize for the disturb, i tried my best but couldn't make everything work as this is my first time with DynDOLOD, i don't have many hopes but since i found you active here i thought i could give this thread a try.

Read the first post which DynDOLOD log, DynDOLOD debug log and bugreport.txt (if it exists) to upload when making posts.
The word "text" of the term "text sharing service" is a hyperlink you can click to find out what it is.

https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots - a proper screenshot of the full model without DynDOLOD output for example.

Possible reasons:

https://dyndolod.info/Mods/Open-Exterior-Cities
Click one of the presets buttons Low, Medium or High to update the rules.

https://dyndolod.info/Generation-Instructions
Activate the plugins(s).

[Onyx]

20 hours ago, sheson said:

See what happens with this test version https://mega.nz/file/RUQlla5T#3dsJH7Ec5qPTRb-DYghY2srcoC1yRAm0rTzEkc8EKGg

If there are still issues, add GLListDebug=1 and GLDebug=1 under [TexGen] to ..\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.INI.
Only enable the RealTimeLog in case the program is terminated without having the chance to writes its own bugreport, log and debug log.

Hi Sheson,

In trying to troubleshoot before I posted here, I had been running with and without GLListDebug=1 and GLDebug=1 as well already (although come to think of it that may have simply been useless without a test version like that one). I had enabled the real time log because TexGenx64 was indeed terminating without any other log files being generated.

I may have solved whatever my issue was by fumbling around with my load order. My issues began after I'd added ELFX Shadows (on top of other ELFX mods), but changing some overwrite ordering with Particle Patch for ENB seems to have done the trick. I previously had Particle Patch loading after most everything else in accordance with Vortex's recommendations, but some more Nexus posts I found indicated that Particle Patch should come much earlier in a load order and tend to be overwritten by most things. Doing that is what seems to have allowed things to work again. I can run TexGenx64 and DynDOLODx64 successfully.

If you'd like, I can try to recreate the old load/overwrite order again to try to break it again for troubleshooting. I'm not sure how much value that would add for you.

Edited April 4, 2023 by Onyx

[sheson]

3 hours ago, Onyx said:

Hi Sheson,

In trying to troubleshoot before I posted here, I had been running with and without GLListDebug=1 and GLDebug=1 as well already (although come to think of it that may have simply been useless without a test version like that one). I had enabled the real time log because TexGenx64 was indeed terminating without any other log files being generated.

I may have solved whatever my issue was by fumbling around with my load order. My issues began after I'd added ELFX Shadows (on top of other ELFX mods), but changing some overwrite ordering with Particle Patch for ENB seems to have done the trick. I previously had Particle Patch loading after most everything else in accordance with Vortex's recommendations, but some more Nexus posts I found indicated that Particle Patch should come much earlier in a load order and tend to be overwritten by most things. Doing that is what seems to have allowed things to work again. I can run TexGenx64 and DynDOLODx64 successfully.

If you'd like, I can try to recreate the old load/overwrite order again to try to break it again for troubleshooting. I'm not sure how much value that would add for you.

The load order of mods, especially when they do not contain textures used by TexGen, should have any effect on TexGen being terminated by the OS / exceptions with nvoglv64.dll without OPenGL reporting back the problem as "invalid operation" for example and TexGens own exception handler being executed. If anything it is indirectly. Check if the last mentioned full textures that are loaded in the log are from a different mod now.

[Terminetwork]

17 hours ago, sheson said:

Read the first post which DynDOLOD log, DynDOLOD debug log and bugreport.txt (if it exists) to upload when making posts.
The word "text" of the term "text sharing service" is a hyperlink you can click to find out what it is.

https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots - a proper screenshot of the full model without DynDOLOD output for example.

Possible reasons:

https://dyndolod.info/Mods/Open-Exterior-Cities
Click one of the presets buttons Low, Medium or High to update the rules.

https://dyndolod.info/Generation-Instructions
Activate the plugins(s).

Hello Sheson, while i was reading the link you sent me (the first one) i got into the game again and took note of the ref id to check it up on xEdit. Apparently the bug was caused by DynDOLOD.esp which has set that static object (the building) to be initially disabled. I reverted all the changes to the static object to Open Cities state and when loaded in game the building was there.  I wonder if other ref ids could be victim of such weird behaviour.

I noticed another problem although this could be much different, when using the map i lag terribly when i am over whiterun (or another city i am currently standing in). And i noticed that if i teleport to Solitude and then check the map, the moment i look back at whiterun the game CTDs.

In the FAQ, under the section ILS and CTD it is recommended NOT to use Safety Load which i am in fact using. After deactivating it and creating a new save the problem persists though. I suppose it is a problem of memory? Is there a Crash Logger for LE?

Thank you for the advices and availability.

 

Edited April 4, 2023 by Terminetwork

[sheson]

24 minutes ago, Terminetwork said:

Hello Sheson, while i was reading the link you sent me (the first one) i got into the game again and took note of the ref id to check it up on xEdit. Apparently the bug was caused by DynDOLOD.esp which has set that static object (the building) to be initially disabled. I reverted all the changes to the static object to Open Cities state and when loaded in game the building was there.  I wonder if other ref ids could be victim of such weird behaviour.

I noticed another problem although this could be much different, when using the map i lag terribly when i am over whiterun (or another city i am currently standing in). And i noticed that if i teleport to Solitude and then check the map, the moment i look back at whiterun the game CTDs.

In the FAQ, under the section ILS and CTD it is recommended NOT to use Safety Load which i am in fact using. After deactivating it and creating a new save the problem persists though. I suppose it is a problem of memory? Is there a Crash Logger for LE?

Thank you for the advices and availability.

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

Really follow the instructions on page https://dyndolod.info/Mods/Open-Exterior-Cities and follow all the instructions exactly. There is no need whatsoever to edit generated plugins.  If you are certain you followed the instructions correctly, then instead of wasting time editing plugins, make a proper problem report.

Does the lagging/CTD have something to do with the LOD patch generated by DynDOLOD? Read the FAQ and readme in the download archive.
Follow a modern modding guide how to properly setup Skyrim LE. SafetyToLoad was superseded by the memory patch build into SKSE, which is superseded by Crash Fixes OSAllocators.

https://www.google.com/search?q=skyrim+le+crash+log
First result: https://www.nexusmods.com/skyrim/mods/106929

[Terminetwork]

3 hours ago, sheson said:

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

Really follow the instructions on page https://dyndolod.info/Mods/Open-Exterior-Cities and follow all the instructions exactly. There is no need whatsoever to edit generated plugins.  If you are certain you followed the instructions correctly, then instead of wasting time editing plugins, make a proper problem report.

Does the lagging/CTD have something to do with the LOD patch generated by DynDOLOD? Read the FAQ and readme in the download archive.
Follow a modern modding guide how to properly setup Skyrim LE. SafetyToLoad was superseded by the memory patch build into SKSE, which is superseded by Crash Fixes OSAllocators.

https://www.google.com/search?q=skyrim+le+crash+log
First result: https://www.nexusmods.com/skyrim/mods/106929

After extensive testing turns out the map CTD was caused by Open Cities itself and NOT by DynDOLOD. After all this time i got betrayed by the mod i put at the center of my modlist.  I'm not sure what exactly in the mod causes this bug but without the mod the map is super stable despite moving and rotating the camera continuosly. Considering this bug is too big and dangerous to ignore, i'm afraid i'll have to give up on this mod since i prefer stability first.

I suppose that if i end up removing OCS and repurposing my modlist then DynDOLOD will not require extra steps and will work straight out of the box.

I don't think i will make a problem report about the initial issue since i can't be 100% sure whether it was user error or a bug with DynDOLOD 3 Alpha.d

Unfortunately the CrashLog mod didn't really help me but it could still be useful in the future so thank you for the recommendation Sheson.

I am sorry for the disturb. Wish you a good day.

P.S: I followed this guide which yes is not modern but is still very useful and functioning. If you have a personal favourite (apart from STEP) i'd be happy to hear.

[z929669]

Testing some new LODs and correcting errors, but one error makes no sense.

This seems like a DynDOLOD reporting mistake, but I may not be aware of something not so obvious. The LOD model has the correct-named strings of the full model, and texture paths match. For some reason, DynDOLOD is calling out the string name of the full model, "RockPileL03Wet:8" but it's not even represented in the LOD model:

Error:

Warning: Textures do not match for "RockPileL03Wet:8": textures\landscape\mountains\mountainslab02.dds in rockpilel03wet.nif -> textures\landscape\rocks01.dds in rockpilel03wet_lod_0.nif

Logs with the full/LOD meshes

EDIT: Cancel that^ ... we've found the problem. The RockPileL03Wet:8 string should be the RockPileL03Wet:19 string. Now I'm wondering how DynDOLOD caught that, since neither of these is used by the LOD model. Does the answer lie in the plugin reference?

[sheson]

12 hours ago, Terminetwork said:

After extensive testing turns out the map CTD was caused by Open Cities itself and NOT by DynDOLOD. After all this time i got betrayed by the mod i put at the center of my modlist.  I'm not sure what exactly in the mod causes this bug but without the mod the map is super stable despite moving and rotating the camera continuosly. Considering this bug is too big and dangerous to ignore, i'm afraid i'll have to give up on this mod since i prefer stability first.

I suppose that if i end up removing OCS and repurposing my modlist then DynDOLOD will not require extra steps and will work straight out of the box.

I don't think i will make a problem report about the initial issue since i can't be 100% sure whether it was user error or a bug with DynDOLOD 3 Alpha.d

Unfortunately the CrashLog mod didn't really help me but it could still be useful in the future so thank you for the recommendation Sheson.

I am sorry for the disturb. Wish you a good day.

P.S: I followed this guide which yes is not modern but is still very useful and functioning. If you have a personal favourite (apart from STEP) i'd be happy to hear.

This is user error, especially when constantly ignoring my begging for logs.

[sheson]

11 hours ago, z929669 said:

Testing some new LODs and correcting errors, but one error makes no sense.

This seems like a DynDOLOD reporting mistake, but I may not be aware of something not so obvious. The LOD model has the correct-named strings of the full model, and texture paths match. For some reason, DynDOLOD is calling out the string name of the full model, "RockPileL03Wet:8" but it's not even represented in the LOD model:

Error:

Warning: Textures do not match for "RockPileL03Wet:8": textures\landscape\mountains\mountainslab02.dds in rockpilel03wet.nif -> textures\landscape\rocks01.dds in rockpilel03wet_lod_0.nif

Logs with the full/LOD meshes

EDIT: Cancel that^ ... we've found the problem. The RockPileL03Wet:8 string should be the RockPileL03Wet:19 string. Now I'm wondering how DynDOLOD caught that, since neither of these is used by the LOD model. Does the answer lie in the plugin reference?

Wrong shapes name/textures will be fixed in the next DynDOLOD Resources version.

The message must be for a different version of the LOD model than the one included in the archive you upload, since that one does not include shape name "RockPileL03Wet:8", while provided full model (which set the MountainSlab02.dds) does.

Mountainslab02.dds is a "HD LOD" texture, which means LOD typically uses the full texture. The UV for HD LOD textures does not need to be limited for the atlas. The vanilla game contains a 3x3 stitched LOD texture for it, which TexGen updates accordingly. If you want to limit the UV of shapes using that texture, the max UV limits are between 0.0 and 3.0 in this case.

[heheloveer]

Several builds ago (I think it was alpha 119) an alt3 complex grass billboard was added. I don't think this particular change was mentioned in the changelogs, and the description in DynDOLOD_SSE.ini was pretty vague, aside from "experimental" and "do not use". So what does it do exactly? Is there any information you can disclose right now?

[RainingTacco]

I also want to know that. The billboards for grass are so small i don't think the chosen billboard levels should affect anything? For me it's like 32x32 texture its really small.