DynDOLOD 3.00 Alpha 182

[Mousetick]

On 6/24/2023 at 8:01 AM, sheson said:

If you are unable to do what I am asking directly, then simply say so.

I'm unwilling to do these tests. I'm not going to regenerate Tamriel LODs for ~20 trees in a corner of Solitude, with any DynDOLOD version, old or latest. I've already spent a lot time of time reporting, researching and documenting the issue caused by the USSEP rules. @MisterMorden also researched the issue on his side and helped with our findings. It's unfortunate that the most important post slipped through the cracks, but that's ok. I'm a bit fed up at this point, though, to tell you the truth.

The simple questions I asked were:

Quote

• Can you confirm our findings and would you agree this is an issue, or at least an unexpected visual behavior.
• Is this the way it's supposed to be, or have we messed up somewhere?
• What would be a solution?

 

On 6/23/2023 at 11:14 PM, sheson said:

In the past few years new features were added that should automatically deal better with this if the references are not deleted. If not, then a new more appropriate solution that works for both standard and ultra tree LOD will be conceived.

I have no idea what this means pertaining to the specific issue at hand.

DynDOLOD is a computer program - of which you're the developer - with a defined, expected behavior based on its algorithms and implementation. We should be able to have a rational discussion about predicted vs. observed behavior, or about predictable output based on specific input, without running tests to "see what happens". DynDOLOD is not a black box.

On 6/24/2023 at 8:01 AM, sheson said:

obviously just remove the reference rules that delete those references via the advanced interface or directly from the DynDOLOD_SSE_unofficialskyrimspecialeditionpatchesp.ini. Then everything should just work with ultra tree LOD. Does it not?

I don't know, I haven't tried. Do you know? It seems to me if the USSEP rules are removed and the USSEP trees are left as is by DynDOLOD, then the Tamriel LODs will overlap with the full models of the Persistent, IsFullLOD USSEP references. In which case we'd be back to the original issue that the USSEP rules were intended to prevent. Unless DynDOLOD removes the IsFullLOD flag on tree references when doing ultra tree LODs. Does it? Do you know if it does? We should be able to predict the results based on the implemented logic, without running tests.

Lastly, if you're affirming (rather than speculating) that removing the USSEP rules should just work with ultra tree LODs, without undesirable side-effects, why are these rules enabled by default and have been for a very very long time? It's still not clear to me after all the back-and-forth whether you agree the USSEP "delete" rules are an issue when used with ultra tree LODs.

Thanks for your time and attention. I'm now going back to lurking in the corner, while playing the game with my "dirty" against-the-rules patch.

[MisterMorden]

Hey y'all I'm running 128 right now with the rules in question removed, I'll be back shortly with results/logs.

[sheson]

5 hours ago, Mousetick said:

• Can you confirm our findings and would you agree this is an issue, or at least an unexpected visual behavior.
• Is this the way it's supposed to be, or have we messed up somewhere?
• What would be a solution?

I already explained the how - and thus confirmed your findings - the "Delete" rules work and why they were added for standard tree LOD generation.
For standard tree LOD, which does not unload in child worldspace, this used to be the desired and expected outcome.
Obviously that outcome is not desired when generating ultra tree LOD - which unloads properly.
Hence my suggestion to generate ultra tree LOD without the rules. Despite my troubleshooting suggestions had no feedback from anyone so far. So the best working solution is yet undetermined. So in your case, the solution is to wait for the next version, as I have repeatably said already.

5 hours ago, Mousetick said:

I have no idea what this means pertaining to the specific issue at hand.

It means, deleting the rules and then generating ultra tree LOD may just have the correct/desired outcome without having to do anything else. Potentially a quick and easy fix to the issue without having to wait for me to to tests and waiting for the next version.

5 hours ago, Mousetick said:

DynDOLOD is a computer program - of which you're the developer - with a defined, expected behavior based on its algorithms and implementation. We should be able to have a rational discussion about predicted vs. observed behavior, or about predictable output based on specific input, without running tests to "see what happens". DynDOLOD is not a black box.

Yes, that is why I answer questions and explain how things work and why and post links etc.
You are participating in an Alpha test, reporting an issue. I am suggesting a solution that might immediately rectify that issue.  You do not seem to be interested having a shot at an immediate solution and no interest to report the outcome to improve the tool/configs so everyone's saves time.
I prominently require users to make an effort and help with the development of the tools to improve them, including troubleshooting and reporting. This is typically done, so users can address issues without having to wait for me trying to replicate issues and to publish an update. Editable configurations and settings exist for this reason. It is impossible to know if something works or not without testing it. Without testing the outcome has not been proven. That is the scientific method that drives the development/troubleshooting.
Me asking users to test or try things is the modus oprandi since inception and a requirement to use the tools in order to advance the development and compatibility.

5 hours ago, Mousetick said:

Lastly, if you're affirming (rather than speculating) that removing the USSEP rules should just work with ultra tree LODs, without undesirable side-effects, why are these rules enabled by default and have been for a very very long time? It's still not clear to me after all the back-and-forth whether you agree the USSEP "delete" rules are an issue when used with ultra tree LODs.

I have already explained why the rules were added: It was done because when generating standard tree LOD, the standard tree LOD does not unload in child worlds and there there will be billboards and full models showing at the same time. The fact that the references are added as IsFullLOD results in similar issues in the parent worldspace.
I am not speculating why nobody noticed or reported the issues with ultra tree LOD before. 
Since I now have been informed that you are unable to do the troubleshooting I asked for, I have added this issue to my long list of things to do, as I said I would. I can not affirm anything until then.
That means - as I already said - the next version will have an appropriate solution.
I have repeatedly suggested a potential solution for the issue, awaited the success or failure report for it  and promised an appropriate solution for the next version for this issue. In case having said these things in several posts didn't make it clear: This is an issue and that is why it will be fixed in the next version.

[MisterMorden]

Ok, here's what I've found...loading "high" rules in the advanced mode, removing the USSEP mesh rules for the trees and using ultra lod did result in most of the trees behind the Winking Skeever remaining without vanishing when approached.  There are still some trees further back behind these, though, as well as some behind Castle Dour that do still disappear when you get within a certain distance.  When I discussed this issue with Mousetick a couple months ago, I also mentioned how 3 or 4 mountain peak/ridge/cliffs (also behind Castle Dour) had no lod representation when approached from the Blue Palace and would suddenly render into place.  I'm guessing these other objects weren't addresses by USSEP (at least not the version I'm using which is the last one for 1.5.97) Anyhoo here are my logs:

No bugreport generated

Dyndolod & TexGen logs: https://ufile.io/f/kj4qh

TexGen debug (there was no Dyndolod debug generated): https://ufile.io/rw2kbfzg

 

I hope this helps, I really appreciate it!

Edited June 26, 2023 by MisterMorden

[redrapptor]

I've followed along with GamerPoets' DynDOLOD guide and everything had gone smoothly until I reached the part where it was time to run DynDOLOD itself. For whatever reason, DynDOLOD absolutely crawls and can't run without freezing or crashing.

According to Task Manager, it utilizes less than 1% of my CPU, but it eats up around 30% of my Memory. TexGen went smoothly and took no more than 15 minutes from start to finish, whereas I've let DynDOLOD run for over an hour and it was unable to finish even one worldspace before hard crashing and closing itself, with many lengthy periods of freezing along the way where the Time Elapsed counter would be perpetually suspended around 10-13 seconds even if 30+ minutes had elapsed.

Here's my modlist. The only mods not shown are DynDOLOD Resources SE, DynDOLOD DLL SE - Scripts, DynDOLOD DLL SE - DLL, and TexGen_Output, all done and arranged in accordance with GamerPoets' guide. He did mention that DynDOLOD takes significantly longer to run than TexGen, but in my case, there's definitely something wrong and I have no idea what it is.

Any help in diagnosing/resolving the issue would be much appreciated.

[sheson]

6 hours ago, MisterMorden said:

Ok, here's what I've found...loading "high" rules in the advanced mode, removing the USSEP mesh rules for the trees and using ultra lod did result in most of the trees behind the Winking Skeever remaining without vanishing when approached.  There are still some trees further back behind these, though, as well as some behind Castle Dour that do still disappear when you get within a certain distance.  When I discussed this issue with Mousetick a couple months ago, I also mentioned how 3 or 4 mountain peak/ridge/cliffs (also behind Castle Dour) had no lod representation when approached from the Blue Palace and would suddenly render into place.  I'm guessing these other objects weren't addresses by USSEP (at least not the version I'm using which is the last one for 1.5.97) Anyhoo here are my logs:

No bugreport generated

Dyndolod & TexGen logs: https://ufile.io/f/kj4qh

TexGen debug (there was no Dyndolod debug generated): https://ufile.io/rw2kbfzg

 

I hope this helps, I really appreciate it!

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.

[sheson]

1 hour ago, redrapptor said:

I've followed along with GamerPoets' DynDOLOD guide and everything had gone smoothly until I reached the part where it was time to run DynDOLOD itself. For whatever reason, DynDOLOD absolutely crawls and can't run without freezing or crashing.

According to Task Manager, it utilizes less than 1% of my CPU, but it eats up around 30% of my Memory. TexGen went smoothly and took no more than 15 minutes from start to finish, whereas I've let DynDOLOD run for over an hour and it was unable to finish even one worldspace before hard crashing and closing itself, with many lengthy periods of freezing along the way where the Time Elapsed counter would be perpetually suspended around 10-13 seconds even if 30+ minutes had elapsed.

Here's my modlist. The only mods not shown are DynDOLOD Resources SE, DynDOLOD DLL SE - Scripts, DynDOLOD DLL SE - DLL, and TexGen_Output, all done and arranged in accordance with GamerPoets' guide. He did mention that DynDOLOD takes significantly longer to run than TexGen, but in my case, there's definitely something wrong and I have no idea what it is.

Any help in diagnosing/resolving the issue would be much appreciated.

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.

[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