DynDOLOD 3.00 Alpha 198

[StrayHALO_MAN]

Candlehearth Hall is misaligned inside of the city when I am in the parent world space, I don't know how to fix this to where DynDOLOD 3 doesn't generate Windhelm child lod in the exterior.
It's also causing major clipping at the main gate... Yes that's part of the same mesh, my Argonian is standing under that just outside the city.

Edited September 4, 2023 by StrayHALO_MAN
Additional info

[Onyxeagle171]

10 hours ago, sheson said:

Moved to the DynDOLOD 3 Alpha thread.

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

Apologies, clearly I hadn't looked enough. 
Below is a google drive with the logs of both TexGen and DynDOLOD, along with their debugs;
https://drive.google.com/file/d/18TwcPu_Mytgkc79SYI-3Vzs8JqKOn1Ed/view?usp=sharing

[sheson]

7 hours ago, StrayHALO_MAN said:

Candlehearth Hall is misaligned inside of the city when I am in the parent world space, I don't know how to fix this to where DynDOLOD 3 doesn't generate Windhelm child lod in the exterior.
It's also causing major clipping at the main gate... Yes that's part of the same mesh, my Argonian is standing under that just outside the city.

Moved to the DynDOLOD 3 Alpha thread.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload.

Lookup the reference form id in xEdit to find out its editor id which shows the source for which the reference was added as explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots.

The land and building should be two separate references and using two different LOD models. 

[sheson]

3 hours ago, Onyxeagle171 said:

Apologies, clearly I hadn't looked enough. 
Below is a google drive with the logs of both TexGen and DynDOLOD, along with their debugs;
https://drive.google.com/file/d/18TwcPu_Mytgkc79SYI-3Vzs8JqKOn1Ed/view?usp=sharing

Generate with this test version instead https://mega.nz/file/AAo1EZSI#Ww2_BpQ63EggdX7KYPWeovJ4shgyhnVPQOwS8eEMfpc

It should run through. If not, upload new log and debug log.

[Mousetick]

14 hours ago, sheson said:

Did you actually flag the plugin as master?

Yes that is correct, I did ESM-flag the SaveTheIcerunner.esp plugin.

14 hours ago, sheson said:

Not sure why mfg sees what it seems. it probably has to do with how a master plugins overwrites other master plugins, which is different than non master.

That console display inaccuracy bothers me greatly so I decided to investigate. I tried to reproduce the issue from scratch using test plugins manually created in xEdit. One 'master' plugin defining a new reference, one 'override' plugin overriding that reference. This is a rabbit hole of mind-boggling permutations but I think I managed to narrow it down:

• The 'master' plugin must be ESM. Either .esm or ESM-flagged .esp.
• The reference override in the 'override' plugin must have an enable parent.

Notes:

• Console display problem doesn't happen if 'master' plugin is not ESM.
• It doesn't matter if 'override' plugin is ESM or not.
• It doesn't matter if the reference in the 'master' plugin has an enable parent or not. Only the enable parent in the override triggers the incorrect display.
• It doesn't matter what changes the override makes to the reference. It can be simply an ITM + enable parent.
• It doesn't matter whether 'master' or 'override' plugins are ESL-flagged or not.

Weird, huh?

I don't know if this is a bug in More Informative Console or yet another engine quirk or a side-effect of low-level SKSE plugins (such as SSE Engine Fixes).

Sorry for veering off-topic but I think this is pertinent as it affects DynDOLOD reporting and troubleshooting. The true origin of the reference cannot be determined by looking at the console in those cases, one must go look into xEdit. I'd be interested if others could confirm my observations.

Thanks.

[imnotfamous]

I got same issue with DynDOLOD v3 140a. It hangs at atlas creation:
[04:22] [Tamriel] Creating texture atlas C:\Modding\DynDOLOD3.00-140a\DynDOLOD_Output\Textures\DynDOLOD\LOD\DynDOLOD_Tamriel_Glow.dds 1024 x 512
The process  "Taking your firstborn" (you really should stop this meme I think) is still running at 25% cpu though, but it's more than 20 minutes like that, nothing react. It almost the fifth time I restarted. I don't have this issue on previous versions. 

Edited September 5, 2023 by imnotfamous
time

[sheson]

1 hour ago, imnotfamous said:

I got same issue with DynDOLOD v3 140a. It hangs at atlas creation:
[04:22] [Tamriel] Creating texture atlas C:\Modding\DynDOLOD3.00-140a\DynDOLOD_Output\Textures\DynDOLOD\LOD\DynDOLOD_Tamriel_Glow.dds 1024 x 512
The process  "Taking your firstborn" (you really should stop this meme I think) is still running at 25% cpu though, but it's more than 20 minutes like that, nothing react. It almost the fifth time I restarted. I don't have this issue on previous versions. 

Moved the post from an old 2019 thread to the appropriate DynDOLOD 3 Alphja thread.

Read the first post and https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log upload when making posts or how to enable the realtime log.

As explained use search to find similar posts and answers, for example https://stepmodifications.org/forum/search/?q=DynDOLOD_Tamriel_Glow.dds&quick=1&type=forums_topic&item=17510

I will list the things that worked for people in the past as discussed in this thread. Try one at time until it hopefully works:

Make sure UAC and antivirus are not interfering. Add exceptions for all executables, also for in ..\Edit Scripts\Texconvx64.exe for example.

Update the graphics driver to the latest version. Install the driver only without the crapware or terminate the crapware before using the tools.

Check the task manager for stuck Texconvx64.exe that DynDOLOD might be waiting for. If you terminate all Texconvx64.exe DynDOLOD should have a related error message and stop.

Add LockTexconv=1 under [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.INI to see if that changes anything.

If not, test if adding RenderSingle=1 under [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.INI lets it run through.

If not, test if instructing Texconv to not use the GPU by adding TexconvAdapterIndex=-1 under [DynDOLOD] in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.IN changes anything.

If it still gets stuck, upload both the log and the debug log.

Requiring firstborns is an allegory and not a meme.

[imnotfamous]

Thanks Sheson for the fast answer. I add LockTexconv=1 and unselected the Fake lights child world option, and it works now. 
I think it could have been a light issue as I use the recent Light Limit Fix mod with its candle glow fake texture, and with LLF Particle Lights instead of Fake Glow mod as well. Not sure how this will be compatible with the Fake lights child world option. Or maybe it's just the LockTexconv that has resolve the issue. Thanks anyway. 
Keep the good work.
Best Regards.

PS: I don't get it about the allegory, maybe something related to dragonborn  Anyway, your choice, just I'm probably not only to not get it. 

Edited September 5, 2023 by imnotfamous

[sheson]

17 minutes ago, imnotfamous said:

Thanks Sheson for the fast answer. I add LockTexconv=1 and unselected the Fake lights child world option, and it works now. 
I think it could have been a light issue as I use the recent Light Limit Fix mod with its candle glow fake texture, and with LLF Particle Lights instead of Fake Glow mod as well. Not sure how this will be compatible with the Fake lights child world option. Or maybe it's just the LockTexconv that has resolve the issue. Thanks anyway. 
Keep the good work.
Best Regards.

PS: I don't get it about the allegory, maybe something related to dragonborn  Anyway, your choice, just I'm probably not only to not get it. 

The fake light child world option is entirely unrelated to generating textures or Texconv.

As explained at https://dyndolod.info/Help/Glow-LOD#Fake-Lights, the fake light option adds dynamic LOD references at the same position where there are reference with LIGH base records that match a certain criteria. The only incompatibility is things not matching well visually.

[Mousetick]

DynDOLOD 3a143 Test version for Parent > Child copies of references with dynamic LOD

Preliminary test results with Icerunner in Solitude: Before > After 👍

I'm trying to take a systemic approach to testing rather than wandering around haphazardly and visually checking stuff:

• I loaded the DynDOLOD plugins in xEdit and applied a filter by references with EDID containing "DYNDOLOD_PARENT".
• Then I applied a custom script to list all records that have an Enable Parent.

Notes:

• My cities are vanilla with minor changes, mostly various small fixes.
• I always use the default NoCellsWithNAVM=1.

Results:

• A total of 993 references were copied, which is a pretty high number, but not too bad.
• Most of the copied references are vanilla stuff for Civil War sieges, and Khajiit Caravans.
• The rest of the copied references are from mods which in my case are not at all close to the cities, the changes are at least 3 or 4 cells away from the city walls. Such as Goldenglow Estate in Riften, or the Western Watchtower in Whiterun, or a buildable house on the road up to Riverwood, at the foot of the mountains.

Next Steps:

• It should be fairly easy to check the Khajiit Caravans when they're in town, so I'm going to do that.
• As for the Civil War siege stuff, I think each city is controlled by its own enable parent common to all the changes, more or less - I hope - so I should be able to toggle them and check them out.
• In order to save time, I don't think it's worth checking the copies that are far away from the walls. It may be important for players who fly/glide, but I don't. Even if I did, it doesn't make sense to me to fly out of cities. Once the player reaches the border of the child worldspace, there is nowhere else to go.

Questions:

• Are there other types of references beside Enable Parent that have dynamic LOD and that I should look for copies in DynDOLOD plugins?
• Any thoughts, comments, advice?

Thanks.

Full logs here if you'd like to take a look: https://drive.google.com/file/d/1HBzSJ56QkptARN150kduGita9awnWx77/view

[sheson]

21 minutes ago, Mousetick said:

DynDOLOD 3a143 Test version for Parent > Child copies of references with dynamic LOD

Preliminary test results with Icerunner in Solitude: Before > After 👍

I'm trying to take a systemic approach to testing rather than wandering around haphazardly and visually checking stuff:

• I loaded the DynDOLOD plugins in xEdit and applied a filter by references with EDID containing "DYNDOLOD_PARENT".
• Then I applied a custom script to list all records that have an Enable Parent.

Notes:

• My cities are vanilla with minor changes, mostly various small fixes.
• I always use the default NoCellsWithNAVM=1.

Results:

• A total of 993 references were copied, which is a pretty high number, but not too bad.
• Most of the copied references are vanilla stuff for Civil War sieges, and Khajiit Caravans.
• The rest of the copied references are from mods which in my case are not at all close to the cities, the changes are at least 3 or 4 cells away from the city walls. Such as Goldenglow Estate in Riften, or the Western Watchtower in Whiterun, or a buildable house on the road up to Riverwood, at the foot of the mountains.

Next Steps:

• It should be fairly easy to check the Khajiit Caravans when they're in town, so I'm going to do that.
• As for the Civil War siege stuff, I think each city is controlled by its own enable parent common to all the changes, more or less - I hope - so I should be able to toggle them and check them out.
• In order to save time, I don't think it's worth checking the copies that are far away from the walls. It may be important for players who fly/glide, but I don't. Even if I did, it doesn't make sense to me to fly out of cities. Once the player reaches the border of the child worldspace, there is nowhere else to go.

Questions:

• Are there other types of references beside Enable Parent that have dynamic LOD and that I should look for copies in DynDOLOD plugins?
• Any thoughts, comments, advice?

Thanks.

Full logs here if you'd like to take a look: https://drive.google.com/file/d/1HBzSJ56QkptARN150kduGita9awnWx77/view

The covered area is the bounding box of cells with navmehes +- (uLargeRefLODGridSize/2)+1  or (uGridsToLoad/2)+1 

Dynamic LOD is done for references with enable parent or initially disabled flag. Also for animated models based on mesh mask or reference rules or via dynamic LOD asset filename matching, in this case waterfalls.

I am rather testing visually with mods that I know add stuff around towns that have enable parents, like LOTD. I am testing with NoCellsWithNAVM=0 to make sure fires/glows for example do not get duplicated.

[Mousetick]

I don't know what happened but the first post of this topic, authored by sheson and containing important README and BEFORE YOU POST type of information, has disappeared. Now there is an old 2019 post from user 'Caaros'.

Latest Wayback Machine capture: https://web.archive.org/web/20230530205331/https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-128/

[sheson]

35 minutes ago, Mousetick said:

I don't know what happened but the first post of this topic, authored by sheson and containing important README and BEFORE YOU POST type of information, has disappeared. Now there is an old 2019 post from user 'Caaros'.

Latest Wayback Machine capture: https://web.archive.org/web/20230530205331/https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-128/

That post got accidentally merged into this thread. I am hoping z929669 can fix it. I only know of a time consuming way.

[Mousetick]

2 hours ago, sheson said:

The covered area is the bounding box of cells with navmehes +- (uLargeRefLODGridSize/2)+1  or (uGridsToLoad/2)+1 

Sorry, I don't understand. Would you mind clarifying what covered area is referring to?

Let's say I'm standing on a city wall or atop a building at the edge of the city and looking at the surroundings. If the dynamic reference copy is outside the active cells grid, I'm not going to see its full model, I'm going to see its dynamic LOD instead. Unless the reference is a large reference. So it seems like a waste of time to visually check these dynamic reference copies that are too far from the cells containing the city limits.

2 hours ago, sheson said:

Dynamic LOD is done for references with enable parent or initially disabled flag. Also for animated models based on mesh mask or reference rules or via dynamic LOD asset filename matching, in this case waterfalls.

Ok. Animated models would be things like windmills I assume. I reran my filters to include initially disabled flag and that didn't change the results, in my case.

The reason I'm filtering to get the list of enable parent or initially disabled reference copies is so that I can identify which ones are dynamic, where they are, and how they are enabled. If I'm peaking over a city wall, and everything is looking fine because all the dynamic references are disabled and therefore not visible, it's not going to be a very good test, is it?  Like the Civil War stuff, it's always disabled except during sieges.

On second thought, the number of added dynamic reference copies is not a big deal in regards to performance, as most of them, at least in vanilla, are disabled most of the time.

Thanks for your input.

[sheson]

25 minutes ago, Mousetick said:

Sorry, I don't understand. Would you mind clarifying what covered area is referring to?

Let's say I'm standing on a city wall or atop a building at the edge of the city and looking at the surroundings. If the dynamic reference copy is outside the active cells grid, I'm not going to see its full model, I'm going to see its dynamic LOD instead. Unless the reference is a large reference. So it seems like a waste of time to visually check these dynamic reference copies that are too far from the cells containing the city limits.

Ok. Animated models would be things like windmills I assume. I reran my filters to include initially disabled flag and that didn't change the results, in my case.

The reason I'm filtering to get the list of enable parent or initially disabled reference copies is so that I can identify which ones are dynamic, where they are, and how they are enabled. If I'm peaking over a city wall, and everything is looking fine because all the dynamic references are disabled and therefore not visible, it's not going to be a very good test, is it?  Like the Civil War stuff, it's always disabled except during sieges.

On second thought, the number of added dynamic reference copies is not a big deal in regards to performance, as most of them, at least in vanilla, are disabled most of the time.

Thanks for your input.

I only explained how the size of the area around a city into which references are copied is determined. You seemed to wonder why things 3 or 4 cells away are being copied. Large references at 11 means 6 cells from the outer cells with navmeshes. This is unrelated to how you test.

Windmill fans happen to be an example of references that are not copied, because the dynamic LOD uses the full model and stays enabled also when active cells attach for continues animation.