sheson Posted June 25, 2023 Author Share Posted June 25, 2023 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. Link to comment Share on other sites More sharing options...
MisterMorden Posted June 25, 2023 Share Posted June 25, 2023 (edited) 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 1 Link to comment Share on other sites More sharing options...
redrapptor Posted June 26, 2023 Share Posted June 26, 2023 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. Link to comment Share on other sites More sharing options...
sheson Posted June 26, 2023 Author Share Posted June 26, 2023 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. Link to comment Share on other sites More sharing options...
sheson Posted June 26, 2023 Author Share Posted June 26, 2023 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. Link to comment Share on other sites More sharing options...
MisterMorden Posted June 26, 2023 Share Posted June 26, 2023 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). Link to comment Share on other sites More sharing options...
z929669 Posted June 26, 2023 Share Posted June 26, 2023 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. Link to comment Share on other sites More sharing options...
sheson Posted June 27, 2023 Author Share Posted June 27, 2023 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. Link to comment Share on other sites More sharing options...
MisterMorden Posted June 27, 2023 Share Posted June 27, 2023 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 Link to comment Share on other sites More sharing options...
sheson Posted June 27, 2023 Author Share Posted June 27, 2023 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... 1 Link to comment Share on other sites More sharing options...
Blackread Posted June 28, 2023 Share Posted June 28, 2023 (edited) 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 Link to comment Share on other sites More sharing options...
sheson Posted June 28, 2023 Author Share Posted June 28, 2023 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. Link to comment Share on other sites More sharing options...
Poncington Posted June 29, 2023 Share Posted June 29, 2023 (edited) 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 Link to comment Share on other sites More sharing options...
Roastlawyer Posted June 29, 2023 Share Posted June 29, 2023 (edited) 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 Link to comment Share on other sites More sharing options...
sheson Posted June 29, 2023 Author Share Posted June 29, 2023 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now