Skyrim TVDT - Occlusion Culling Data

[sheson]

  On 11/9/2024 at 8:16 PM, Elaura said:

Thank You. I guess Occlusion.esp isn't for me, then. I spend more time patching than playing. Thanks again!

Expand  

This has nothing to do with Occlusion.esp

The game only uses the data from the winning record of the winning plugin. This applies to all plugins, no matter how they are created. If you want the winning overwrite to contain changes from earlier plugins, you will have to create conflict resolution patches. There are only a few exceptions https://www.afkmods.com/index.php?/topic/6083-skyrim-se-sseedit-records-that-merge-at-runtime/

[Elaura]

I didn't mean to say it is an issue with Occlusion. It's my issue, most definitely.

I suppose in my dreams I imagine a patcher that allows me to choose which mod I want each type of record to to use.
Currently, I use:

Realistic Water Two
Unique Region Names
Missing Encounter Zones

As well as various mods which alter specific Editor IDs of Worldspaces. 

While I'm dreaming, I'd love to have a feature that could read my mods and choose the ones that change a record and ignore the ones that don't, regardless of load order. Sadly, they can't all load last.

[sheson]

  On 11/10/2024 at 5:58 PM, Elaura said:

I didn't mean to say it is an issue with Occlusion. It's my issue, most definitely.

I suppose in my dreams I imagine a patcher that allows me to choose which mod I want each type of record to to use.
Currently, I use:

Realistic Water Two
Unique Region Names
Missing Encounter Zones

As well as various mods which alter specific Editor IDs of Worldspaces. 

While I'm dreaming, I'd love to have a feature that could read my mods and choose the ones that change a record and ignore the ones that don't, regardless of load order. Sadly, they can't all load last.

Expand  

That is what tools like Wrye Bash, Smash, Synthesis, xEdit etc. are for.

You do not want to change the Editor the IDs of worldpace records with LOD. That will cause the game to not be able to load LOD files.

[Elaura]

That's what I'm doing. I couldn't tell you why the mod authors change the worldspace editor IDs, but on the outside chance it has something to do with a script, I am loathe to change them back. In any case, Let's let this go. I am using xEdit to try to fix these issues. I'll just have to back up this Occlusion.esp so I can bring the changes forward whenever I have to re-generate it.

[sheson]

  On 12/12/2024 at 12:04 AM, Elaura said:

That's what I'm doing. I couldn't tell you why the mod authors change the worldspace editor IDs, but on the outside chance it has something to do with a script, I am loathe to change them back. In any case, Let's let this go. I am using xEdit to try to fix these issues. I'll just have to back up this Occlusion.esp so I can bring the changes forward whenever I have to re-generate it.

Expand  

If you follow basic modding practice and create all patch plugins beforehand to finalize the load order, then there is no reason to do unnecessary things like keeping old plugins and redo the patching/forwarding of records every time. You would have made a patch plugin, automatically or manually, that contains all the required changes and be the last plugin from which LOD and Occlusion generation gets the already corrected/conflict resolved records.

If a plugin changes the EditorID of a worldspace, especially with LOD,  it is typically an error or an unintentional wild edit.

[Elaura]

  On 12/12/2024 at 7:22 AM, sheson said:

If you follow basic modding practice and create all patch plugins beforehand to finalize the load order, then there is no reason to do unnecessary things like keeping old plugins and redo the patching/forwarding of records every time. You would have made a patch plugin, automatically or manually, that contains all the required changes and be the last plugin from which LOD and Occlusion generation gets the already corrected/conflict resolved records.

If a plugin changes the EditorID of a worldspace, especially with LOD,  it is typically an error or an unintentional wild edit.

Expand  

Honestly, I can patch the few mods that make editor ID and location additions. I didn't want to name the mod authors, but the editor ID changes are from mihail and Arthmoor. They aren't wild edits. For example, Tamriel "Skyrim" [WRLD:0000003C]
Bring Out Your Dead changes this cell from [CELL:00008E83] (in Tamriel "Skyrim" [WRLD:0000003C] at 26,26) to ARTHBOYDWinterholdHoD [CELL:00008E83] (in Tamriel "Skyrim" [WRLD:0000003C] at 26,26)

The real issue comes up when multiple mods add Regions. Since there can be multiple Region entries and Occlusion only takes the last one, I inevitably have to manually bring forward the regions from mods earlier in the load order.

For example, Tamriel "Skyrim" [WRLD:0000003C]
Bring Out Your Dead changes this cell from [CELL:00008E83] (in Tamriel "Skyrim" [WRLD:0000003C] at 26,26) to ARTHBOYDWinterholdHoD [CELL:00008E83] (in Tamriel "Skyrim" [WRLD:0000003C] at 26,26)

AND Unique Region Names adds two new Region entries that aren't in BYOD. Occlusion doesn't bring forward the changes from both mods

The same is true for Unique Region Names and Missing Encounter Zones.
Unique region Names adds a XCLR Region entry, while Missing Ecounter Zones adds XEZN subrecord.
They both can't load last so Occlusion doesn't bring forward both changes.
 

I'm simply wishing Occlusion could bring forward all the added XCLR Region entries and all the added XEZN, from all the mods in my load order, instead of taking the last one and blanking out the changes from the others.

As it is, I either have to make my own patch to load last or bring forward the ignored changes after Occlusion.esp is generated. It's one of those "wouldn't it be great if?" scenarios. Not something I truly expect someone to make happen.

[sheson]

  On 12/17/2024 at 12:36 AM, Elaura said:

Honestly, I can patch the few mods that make editor ID and location additions. I didn't want to name the mod authors, but the editor ID changes are from mihail and Arthmoor. They aren't wild edits. For example, Tamriel "Skyrim" [WRLD:0000003C]
Bring Out Your Dead changes this cell from [CELL:00008E83] (in Tamriel "Skyrim" [WRLD:0000003C] at 26,26) to ARTHBOYDWinterholdHoD [CELL:00008E83] (in Tamriel "Skyrim" [WRLD:0000003C] at 26,26)

The real issue comes up when multiple mods add Regions. Since there can be multiple Region entries and Occlusion only takes the last one, I inevitably have to manually bring forward the regions from mods earlier in the load order.

For example, Tamriel "Skyrim" [WRLD:0000003C]
Bring Out Your Dead changes this cell from [CELL:00008E83] (in Tamriel "Skyrim" [WRLD:0000003C] at 26,26) to ARTHBOYDWinterholdHoD [CELL:00008E83] (in Tamriel "Skyrim" [WRLD:0000003C] at 26,26)

AND Unique Region Names adds two new Region entries that aren't in BYOD. Occlusion doesn't bring forward the changes from both mods

The same is true for Unique Region Names and Missing Encounter Zones.
Unique region Names adds a XCLR Region entry, while Missing Ecounter Zones adds XEZN subrecord.
They both can't load last so Occlusion doesn't bring forward both changes.
 

I'm simply wishing Occlusion could bring forward all the added XCLR Region entries and all the added XEZN, from all the mods in my load order, instead of taking the last one and blanking out the changes from the others.

As it is, I either have to make my own patch to load last or bring forward the ignored changes after Occlusion.esp is generated. It's one of those "wouldn't it be great if?" scenarios. Not something I truly expect someone to make happen.

Expand  

Those EditorID changes seem to be to cell records and not wrld worldspace records.

Occlusion generation uses the record and data from the winning plugins. Make sure the winning plugin contains all the desired records, data and conflict resolution you desire. Occlusion generation will only update the records and data that are relevant for LOD occlusion and nothing else.

Use the appropriate and specialized tools or scripts to merge and conflict resolve the entire load order. Feature requests should go towards tools that already do similar or related work to the desired feature.

[Elaura]

  On 12/17/2024 at 7:49 AM, sheson said:

Those EditorID changes seem to be to cell records and not wrld worldspace records.

Occlusion generation uses the record and data from the winning plugins. Make sure the winning plugin contains all the desired records, data and conflict resolution you desire. Occlusion generation will only update the records and data that are relevant for LOD occlusion and nothing else.

Use the appropriate and specialized tools or scripts to merge and conflict resolve the entire load order. Feature requests should go towards tools that already do similar or related work to the desired feature.

Expand  

I wish there was a script. I'm having to do it all "by hand" in XEdit. It's what I get for running 1070 Active plugins eh?

Edited December 19, 2024 by Elaura
typo

[sheson]

  On 12/19/2024 at 4:21 AM, Elaura said:

I wish there was a script. I'm having to do it all "by hand" in XEdit. It's what I get for running 1070 Active plugins eh?

Expand  

If you require help with xEdit scripting, then you might want to check #xEdit-Scripting channel on the xEdit discord.

[Elaura]

  On 12/19/2024 at 9:23 AM, sheson said:

If you require help with xEdit scripting, then you might want to check #xEdit-Scripting channel on the xEdit discord.

Expand  

Thanks! I shall!

[ra2phoenix]

Noticed some values were not being copied from the winning plugin into Occlusion.esp.  By looking through the missed forwards in my large load order, the pattern is that every Cell with missing data has DynDOLOD.esm in the overrides but not DynDOLOD.esp.  I'll try to generate this on a smaller load order that isn't 2k plugins, but maybe it's enough to go on - I believe that since the ESM is generated at the bottom of the "stack" during the DynDOLOD session, that it's treating it as the winning record for Occlusion.esp unless DynDOLOD.esp was also generated for that cell.  There must be some mechanism that it uses to skip this new record when copying the base data for DynDOLOD.esp (or we'd see this problem there, and I don't based on Water for ENB waterflow edits etc.) that isn't replicated for Occlusion.esp generation.

Tldr is that in a large load order there are many instances of the winning record's non-vanilla XLCN, EDID, XCWT not being correct in Occlusion.esp and in every single case there is a DynDOLOD.esm with vanilla data higher in the overrides.

I'll try to replicate in a controlled fashion with logs tomorrow unless this is enough to identify a code problem.

[sheson]

  On 2/15/2025 at 8:43 AM, ra2phoenix said:

Noticed some values were not being copied from the winning plugin into Occlusion.esp.  By looking through the missed forwards in my large load order, the pattern is that every Cell with missing data has DynDOLOD.esm in the overrides but not DynDOLOD.esp.  I'll try to generate this on a smaller load order that isn't 2k plugins, but maybe it's enough to go on - I believe that since the ESM is generated at the bottom of the "stack" during the DynDOLOD session, that it's treating it as the winning record for Occlusion.esp unless DynDOLOD.esp was also generated for that cell.  There must be some mechanism that it uses to skip this new record when copying the base data for DynDOLOD.esp (or we'd see this problem there, and I don't based on Water for ENB waterflow edits etc.) that isn't replicated for Occlusion.esp generation.

Tldr is that in a large load order there are many instances of the winning record's non-vanilla XLCN, EDID, XCWT not being correct in Occlusion.esp and in every single case there is a DynDOLOD.esm with vanilla data higher in the overrides.

I'll try to replicate in a controlled fashion with logs tomorrow unless this is enough to identify a code problem.

Expand  

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts.

Provide cell coordinates of one effected cell as example.

There is no need for you trying to troubleshoot this., reporting with  required logs and requested information would be sufficient.

Probably related to what we are already troubleshooting here https://stepmodifications.org/forum/topic/20542-weird-water-seam-non-lod-at-docks-only-appears-when-dyndolod-output-is-enabled