Skyrim TVDT - Occlusion Culling Data

[z929669]

5 hours ago, sa547 said:

Ok, found that removing the TVDT in question from occlusion.esp resolved the savegame problem.

 

5 hours ago, sheson said:

Remove all other records but that one cell from the Occlusion.esp. Test if the problem still exists then.

In case it does, upload the file somewhere for review.

Also check the xLODGen log if there were any error or warning messages while generating occlusion.esp

@sa547 I know your issue is resolved, but taking this extra step is sort of obligatory, since you are participating in the alpha testing (by proxy of using DynDOLOD 3) and having the resulting info is valuable for movement towards beta, which benefits everyone.

[sa547]

20 hours ago, sheson said:

Remove all other records but that one cell from the Occlusion.esp. Test if the problem still exists then.

In case it does, upload the file somewhere for review.

Also check the xLODGen log if there were any error or warning messages while generating occlusion.esp

Did as directed, removed all records but the affected cell, then ran the quest as usual and was able to make a savegame without crashing. Repeated this sequence but with SSE Fixes savegame option disabled, and again, no CTD.

There were no warnings during occlusion generation with either utility.

14 hours ago, z929669 said:

I know your issue is resolved, but taking this extra step is sort of obligatory, since you are participating in the alpha testing (by proxy of using DynDOLOD 3) and having the resulting info is valuable for movement towards beta, which benefits everyone.

Yes, it's understandable. 

Been going through the video I recorded for tracking down the problem, and it appeared that a quest in Immersive Encounters, rather than 3DNPC

Immersive Encounters.esp (282E8155) \ Quest \ 73A970B4 <SetteBard01>

has, beyond my understanding, somehow affected gamesave function and occlusion data specific to that worldspace cell (6FE1).

I do also have to note the current version of Immersive Encounters is also a beta release.

[sheson]

16 minutes ago, sa547 said:

Did as directed, removed all records but the affected cell, then ran the quest as usual and was able to make a savegame without crashing. Repeated this sequence but with SSE Fixes savegame option disabled, and again, no CTD.

There were no warnings during occlusion generation with either utility.

Yes, it's understandable. 

Been going through the video I recorded for tracking down the problem, and it appeared that a quest in Immersive Encounters, rather than 3DNPC

Immersive Encounters.esp (282E8155) \ Quest \ 73A970B4 <SetteBard01>

has, beyond my understanding, somehow affected gamesave function and occlusion data specific to that worldspace cell (6FE1).

I do also have to note the current version of Immersive Encounters is also a beta release.

The only way I could imagine the TVDT data to cause any problems would be if the byte length of the entry would be somehow wrong in the plugin. The data itself is not part of the save file.

It is possible that other fields of the cell record might be wrong in some way (copied from last winning plugin) and just editing and then saving the record in any way rectifies that.

If you could just open the entire problematic Occlusion.esp in xEdit, find the cell record, in the left tree view right click it and set it "mark modified", then close and save it. See if that changes anything.

[sa547]

4 hours ago, sheson said:

If you could just open the entire problematic Occlusion.esp in xEdit, find the cell record, in the left tree view right click it and set it "mark modified", then close and save it. See if that changes anything.

After doing the above instructions, marking cell 6FE1 as modified, I ran the scenario to recreate the conditions which caused the CTD, and the game successfully produced a savegame.

Edited September 16, 2021 by sa547

[sheson]

1 hour ago, sa547 said:

After doing the above instructions, marking cell 6FE1 as modified, I ran the scenario to recreate the conditions which caused the CTD, and the game successfully produced a savegame.

If could upload both those esp that would be great. Use a PM if you do not want to share them publicly.

Also let me know which plugin is the last to modify the cell record which was used as the source to be copied into Occlusion.esp (other than DynDOLOD plugins)

[sa547]

Here's the files as requested:

https://mega.nz/folder/7YESWJAJ#h0NHfNrDFSORKb3spUE54A

12 hours ago, sheson said:

Also let me know which plugin is the last to modify the cell record which was used as the source to be copied into Occlusion.esp (other than DynDOLOD plugins)

As far as I have seen, 3DNPC modified the cell's navmesh, and Immersive Encounters added an NPC in that same area with the quest in question, but were not included in the occlusion generation.

Will try to run the quest sequence again with default values and settings, using the original occlusion plugin, and report my findings, as for all I know it could also been possibly a memory leak during the time it happened until I rebooted the PC later.

Edited September 17, 2021 by sa547

[mattski123]

Will having the mode on 3.00 set to 3 increase performance in game compared to mode 1 & 2? I know 2 is default, but just wondering.

[sheson]

1 hour ago, mattski123 said:

Will having the mode on 3.00 set to 3 increase performance in game compared to mode 1 & 2? I know 2 is default, but just wondering.

As explained before, read the included documentations of xLODGen/DynDOLOD. They explain each setting.

Quality - samples per cell. The more samples are used the more distant cells are potentially disabled.

[mattski123]

13 hours ago, sheson said:

As explained before, read the included documentations of xLODGen/DynDOLOD. They explain each setting.

Quality - samples per cell. The more samples are used the more distant cells are potentially disabled.

I see, and I read the documentation but didn't see anything refering to perfromance changes. If I want better performance in game which do I choose?

[DoubleYou]

It rarely affects performance significantly. Use 2 for testing and quick generation. Use 3 if you have the time and for your playthrough. 

[mattski123]

42 minutes ago, DoubleYou said:

It rarely affects performance significantly. Use 2 for testing and quick generation. Use 3 if you have the time and for your playthrough. 

If I understand this right, 3 would be if I wanted better culling, is that right? And does it improve the quality of the LODs?

[DoubleYou]

Simple answer is yes. 

[sheson]

9 hours ago, mattski123 said:

I see, and I read the documentation but didn't see anything refering to perfromance changes. If I want better performance in game which do I choose?

"... the more distant cells are potentially disabled."

xLODGen readme:
"The data is used to disable LOD meshes that are occluded by terrain. For example a big mountain hides any LOD behind it. Disabling hidden LOD meshes frees up draw calls and reduces poly count of a scene."

DynDOLOD_Manual.html/OcclusionCulling.html:
"Occlusion Data defines the visibility of terrain and object LOD for a cell. For example a big mountain hides any LOD behind it. Disabling occluded LOD meshes helps performance."

The more LOD is disabled the better for performance

2 hours ago, mattski123 said:

If I understand this right, 3 would be if I wanted better culling, is that right? And does it improve the quality of the LODs?

"The data is used to disable LOD meshes that are occluded by terrain."

Of course it does not change the quality of LOD meshes/textures.

[z929669]

On 11/7/2021 at 12:16 AM, mattski123 said:

If I understand this right, 3 would be if I wanted better culling, is that right? And does it improve the quality of the LODs?

Performance in game: use '3'

Performance of application (DynDOLOD or xLODGen): use '1'

In lay terms: You don't want the game to render content that you cannot see at a given position. That's effectively all this is doing. It's like an off switch for rendering content behind mountains and such. I think it can be said that using '3' yields the most accurate occlusion from player position in Cartesian space, so performance in game should be theoretically maximized relative to 1 or 2.

[mattski123]

19 hours ago, z929669 said:

Performance in game: use '3'

Performance of application (DynDOLOD or xLODGen): use '1'

In lay terms: You don't want the game to render content that you cannot see at a given position. That's effectively all this is doing. It's like an off switch for rendering content behind mountains and such. I think it can be said that using '3' yields the most accurate occlusion from player position in Cartesian space, so performance in game should be theoretically maximized relative to 1 or 2.

I'm using xLODGen, which mode will end up providing the best in-game performance? And is there a radius that you prefer to use other than 100?

Edited November 9, 2021 by mattski123