DynDOLOD 3.00 Alpha 182

[MisterMorden]

8 hours ago, sheson said:

Thanks. If you say most of the trees, it probably means, that the unofficial patch does not add references for all trees that happen have references/LOD in the parent worldspace. After all, the trees in Solitude not having full models is how the vanilla game was made. I suppose an appropriate solution will have to cover all trees and work regardless of the patch.

If something doesn't have LOD it is typically because there is no reference for it in the parent worldspace Tamriel. Screenshots of the full models with more informative console would help. Mountains/Rocks are on the ignore list for the automatic carbon copies to the parent to avoid unnecessary conflicts. Large references make this more obvious, since where the LOD starts to show is pushed further away.

The tools save the log and then debug log right after when they shutdown. Give the saving of the logs some time. Just let the tools close on their own. Otherwise there should be an error message if something prevents saving of the debug log.

I do let the tool close on it's own,  I don't know why the dyndolod debug didn't show up...I usually just hit "save and exit" and let it finish that.  Sorry I didn't have that piece of info for you.  If it helps at all, I have several tree and a couple mountain ids in the patch I made to make them visible inside Solitude that cover some of these non-USSEP fixed objects I can post when I get home this evening (might be more thorough to browse the cells in question I suppose). 

[z929669]

11 hours ago, sheson said:

Moved to the DynDOLOD 3 Alpha thread.

Read the first post or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log, debug log and bugrepost.txt (if it exists) to upload when making posts.

See Long running time or output several GB in file size at https://dyndolod.info/FAQ. In particular, see if removing or terminating crapware installed with the graphics drivers helps.

Check if there are Texconv background processes DynDOLOD might be waiting on.

 

11 hours ago, sheson said:

Moved to the DynDOLOD 3 Alpha thread.

Read the first post or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log, debug log and bugrepost.txt (if it exists) to upload when making posts.

See Long running time or output several GB in file size at https://dyndolod.info/FAQ. In particular, see if removing or terminating crapware installed with the graphics drivers helps.

Check if there are Texconv background processes DynDOLOD might be waiting on.

 

If you are using AMD graphics, try running Taskmanager and killing anything beginning with 'AMD':

Then repeat TexGen processing to see if long-running time is significantly reduced.

[sheson]

17 hours ago, MisterMorden said:

I do let the tool close on it's own,  I don't know why the dyndolod debug didn't show up...I usually just hit "save and exit" and let it finish that.  Sorry I didn't have that piece of info for you.  If it helps at all, I have several tree and a couple mountain ids in the patch I made to make them visible inside Solitude that cover some of these non-USSEP fixed objects I can post when I get home this evening (might be more thorough to browse the cells in question I suppose). 

Just listing the form ids of mountain/rock references that have no representation in the Solitude child worldspace works, too.

[MisterMorden]

4 hours ago, sheson said:

Just listing the form ids of mountain/rock references that have no representation in the Solitude child worldspace works, too.

These are the mountain ids that I have in the patch I've been loading after Dyndolod.esm that fixes the issue for me..I haven't noticed any other problem peaks.

00058823, 00058826, 00058827, 00058828, & 000688CB

[sheson]

1 hour ago, MisterMorden said:

These are the mountain ids that I have in the patch I've been loading after Dyndolod.esm that fixes the issue for me..I haven't noticed any other problem peaks.

00058823, 00058826, 00058827, 00058828, & 000688CB

The unofficial patch already covers some of those. However, they are not added as large references - probably also because those were done in Skyrim long before Special Edition came out - so they unload too early if large references are active in child worlds. In case of cell -17,28 the additions actually prevent automatic copying of large references into the child world cell since it is not empty anymore. I will probably undo everything the unofficial patch does in those cells just outside the walls, so that as much as possible is done automatically based on the references found in the Tamriel worldspace. Hopefully, that will have best compatibility with other mods making modifications to those areas. We'll see...

[Blackread]

How important are the cell editor IDs for DynDOLOD to function? I've been using this Synthesis patcher https://github.com/Deigue/CellEditorIDFixer and I recently noticed that it's also removing underscores from the editor IDs of some cells generated by DynDOLOD.

I also have another unrelated question: is swapping large references with Base Object Swapper supported?

Edited June 28, 2023 by Blackread

[sheson]

7 minutes ago, Blackread said:

How important are the cell editor IDs for DynDOLOD to function? I've been using this Synthesis patcher https://github.com/Deigue/CellEditorIDFixer and I recently noticed that it's also removing underscores from the editor IDs of some cells generated by DynDOLOD.

I also have another unrelated question: is swapping large references with Base Object Swapper supported?

Cell EditorIDs are not used in the game by DynDOLOD. They are used while the plugins are generated or updated.

https://dyndolod.info/Generation-Instructions
Typically create all other patches first. Especially all patches affecting exterior worldspaces in any way should be done before generating LOD.

In case there is a reason to change the EditorID, consider this common sense explanation:
https://dyndolod.info/Mod-Authors (that would include patch developers)
Remember, DynDOLOD is a patcher to automatically generate a LOD patch. The LOD patch it generates is not supposed to require patching itself.
Reach out and describe the problem or issue with as much information as possible in order to discuss and to address it one way or the other.

https://dyndolod.info/Mods/Base-Object-Swapper
Swapping typically works for large references, too. Large reference bugs are triggered if the new base record type is changed from STAT or MSTT (a warning message Base Record Type Not STAT or MSTT For Large Reference is written to the message log - the large reference bugs workarounds fix this) or in case the volume of the objects bounds of the new base record is smaller than the required minimum (this is automatically fixed by DynDOLOD).

https://dyndolod.info/Help/Large-References
The base record not being of the type STAT or MSTT. For example if the base record is changed by a plugin or base object swapper for a large reference, even if the plugin is an ESM. A warning message Base Record Type Not STAT or MSTT For Large Reference is written to the message log.

[Poncington]

Is anyone else getting stuck in texgen64?  It keeps stopping at imperialfortlod.dds every time.  It used to take maybe 5 or 10 minutes but now it gets to that exact point and never moves on.  I found a post online that suggested rolling my nvidia driver back and setting RenderThreads=1  in texgensse.ini but still no joy.  No error messages or anything it just gets to that point and never gets past it.  Any ideas?  I already have texgen64 and dyndolod64 set to run as admin.  Cpu is at 1% and memory is at 47%. Thanks!

 

Forgot to mention I was using the latest dyndolod/texgen3.0 128 with skyrim 1.6.64.  I also used dydndolod dll se and dyndolod skse64 plugin loaded after dyndolod resources 3.

Edited June 29, 2023 by Poncington

[Roastlawyer]

On 6/15/2023 at 1:07 AM, Roastlawyer said:

When I tried it again just now it worked, but if it happens again I'll be back with the log

Well, not exactly the same as before when it was freezing at generating at Tamriel, but I'm getting an issue with similar effect where generation completely freezes and CPU usage drops to zero. So far it's been frozen for 15 minutes or so without doing anything. The realtime log you had me enable last time I had an issue also stopped being updated when It froze. https://drive.google.com/file/d/1tUjYNaETcLsX4LjJH9aFQNFAB1ZDbOok/view?usp=drive_link Link to log

 

Later edit: It happened on my next try as well, here is the log from that second time https://drive.google.com/file/d/1aotQ77s_BhUu2Do8e-WAOY-mPSh7laXn/view?usp=drive_link

Edited June 29, 2023 by Roastlawyer

[sheson]

3 hours ago, Poncington said:

Is anyone else getting stuck in texgen64?  It keeps stopping at imperialfortlod.dds every time.  It used to take maybe 5 or 10 minutes but now it gets to that exact point and never moves on.  I found a post online that suggested rolling my nvidia driver back and setting RenderThreads=1  in texgensse.ini but still no joy.  No error messages or anything it just gets to that point and never gets past it.  Any ideas?  I already have texgen64 and dyndolod64 set to run as admin.  Cpu is at 1% and memory is at 47%. Thanks!

Forgot to mention I was using the latest dyndolod/texgen3.0 128 with skyrim 1.6.64.  I also used dydndolod dll se and dyndolod skse64 plugin loaded after dyndolod resources 3.

Read the first post or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which log, debug log and bugrepost.txt (if it exists) to upload when making posts.

TexGen is probably waiting for a TexConv process to finish.

Add LockTexconv=1 under [TexGen] in B:\Mods\Skyrim\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.INI and see if that changes anything.
It helped users with the same problem a couple pages back where TexGen seems to be stuck or stopped.

[sheson]

11 minutes ago, Roastlawyer said:

Well, not exactly the same as before when it was freezing at generating at Tamriel, but I'm getting an issue with similar effect where generation completely freezes and CPU usage drops to zero. So far it's been frozen for 15 minutes or so without doing anything. The realtime log you had me enable last time I had an issue also stopped being updated when It froze. https://drive.google.com/file/d/1tUjYNaETcLsX4LjJH9aFQNFAB1ZDbOok/view?usp=drive_link Link to log

When you close the tool via X top right it should also just save the log and debug log you could then upload instead.

Check in task manager if there are TexConv processes the tool might be waiting on.

Test with RenderSingle=1 added under [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini

[Roastlawyer]

23 hours ago, sheson said:

When you close the tool via X top right it should also just save the log and debug log you could then upload instead.

Check in task manager if there are TexConv processes the tool might be waiting on.

Test with RenderSingle=1 added under [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini

Yesterday when it was freezing like that, pressing the X in the top right would cause the program to hang, then windows would say dyndolod stopped responding. I click end anyways, the main window would close and then a dyndolod process that could not be killed would hang around in task manager untill the PC was forcably restarted. When that happened the normal log files where not generated which is why you had my enable the realtime one before. Anyways I'll give the RenderSingle=1 line a try.

Alright tried again with the RenderSingle=1 line just below [DynDOLOD] in the _SSE.ini. It hung at [Tamriel] Creating texture atlas. In task manager I couldn't find any TexConv processes. After 25 minutes of DynDOLOD being at 0% cpu usage and no further additionsto the realtime log since it stalled I tried to stop generation. Pressing the X gave me the message about how generation would be incomplete, I accepted and now the dyndolod window is greyed out and the both the window and task manager say it's not responding. Pressing end task in task manager does nothing. Because of this I have no DynDOLOD_SSE__debug_log.txt, bugreport.txt, or DynDOLOD_SSE_log.txt.

Here is the realtime log https://drive.google.com/file/d/1fRTAGWFz2OUqAkvpQROdrmSYT77DmVBJ/view?usp=drive_link

[sheson]

4 hours ago, Roastlawyer said:

Yesterday when it was freezing like that, pressing the X in the top right would cause the program to hang, then windows would say dyndolod stopped responding. I click end anyways, the main window would close and then a dyndolod process that could not be killed would hang around in task manager untill the PC was forcably restarted. When that happened the normal log files where not generated which is why you had my enable the realtime one before. Anyways I'll give the RenderSingle=1 line a try.

Alright tried again with the RenderSingle=1 line just below [DynDOLOD] in the _SSE.ini. It hung at [Tamriel] Creating texture atlas. In task manager I couldn't find any TexConv processes. After 25 minutes of DynDOLOD being at 0% cpu usage and no further additionsto the realtime log since it stalled I tried to stop generation. Pressing the X gave me the message about how generation would be incomplete, I accepted and now the dyndolod window is greyed out and the both the window and task manager say it's not responding. Pressing end task in task manager does nothing. Because of this I have no DynDOLOD_SSE__debug_log.txt, bugreport.txt, or DynDOLOD_SSE_log.txt.

Here is the realtime log https://drive.google.com/file/d/1fRTAGWFz2OUqAkvpQROdrmSYT77DmVBJ/view?usp=drive_link

Install latest graphics driver only. Disable all overclocking etc.

Add TextureCache=10 under [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini

Keep an eye on VRAM usage. Close other programs to free up VRAM usage if needed.

If no change, test with AtlasThreads=1 (and RenderSingle=1) added under [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini

[Katarsi]

I have some inquiries about Large Reference Bugs Workaround.

I have downloaded DynDOLOD DLL NG and Scripts 3.00, but I don't know how to use it. It says that large references need to be cleaned - but how?

The last time I generated LOD was last year, here is my log. My load order didn't change much regarding large reference offenders, although - how exactly do I find out exactly which mods have large reference bugs? Do I have to determine that and clean them before generating LOD, or will DynDOLOD do it by itself when I start it while the aforementioned script is active?

If it's of any significance, I'm on downgraded Skyrim - version 1.5.97 total, not "best of both worlds".

[Roastlawyer]

6 hours ago, sheson said:

Install latest graphics driver only. Disable all overclocking etc.

Add TextureCache=10 under [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini

Keep an eye on VRAM usage. Close other programs to free up VRAM usage if needed.

If no change, test with AtlasThreads=1 (and RenderSingle=1) added under [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini

Ensured my CPU overclock was disabled (was already running stock) and that MSI afterburner didn't currently have an GPU overclock set (It didn't)

updated Nvidia driver from 528.24 to 336.40  (latest one for 3080)
updated AMD APU Graphics driver from 22.20.27.09 (November 2022) to 22.49.57.05 (June 1 2023) (latest one for Ryzen 5600g)

Ran DynDOLOD (twice because I forgot to watch Vram usage the first time) Both times it got stuck at "[Tamriel] Creating texture atlas E:\Mods\[Bethesda Stuff]\Patchers and Similar Tools (Xedit, Wrye Bash,Loot etc)\DynDOLOD & TexGen\DynDOLOD 3.00 Alpha 128\DynDOLOD_Output\Textures\DynDOLOD\LOD\DynDOLOD_Tamriel_Glow.dds"
Vram usage never went above 1.6GB out of 10GB
Ram maxed out at 9.6GB used out of 31.8GB

 

Ran a 3rd time but with

[DynDOLOD]
TextureCache=10
RenderSingle=1

Instead of just RenderSingle=1 set in DynDOLOD_SSE.ini

That time it got further, getting to "[06:18] [DLC2SolstheimWorld] Creating texture atlas E:\Mods\[Bethesda Stuff]\Patchers and Similar Tools (Xedit, Wrye Bash,Loot etc)\DynDOLOD & TexGen\DynDOLOD 3.00 Alpha 128\DynDOLOD_Output\Textures\DynDOLOD\LOD\DynDOLOD_DLC2SolstheimWorld_Glow.dds 512 x 256" before CPU usage dropped to 0% and Vram usage dropped back to idle levels (0.5GB used)
No real change in amount of Vram or ram used

Ran a 4th time:

[DynDOLOD]
TextureCache=10
RenderSingle=1
AtlasThreads=1

Whoohoo! finally got a complete run. So that's quite nice. Vram usage was pretty much the same. Ram topped out ~13GB when it peaked, most of the time usage was still around 10GB.

Edit: Spelling/formatting

Edited June 30, 2023 by Roastlawyer