Jump to content

Skyrim TVDT - Occlusion Culling Data


sheson

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by sa547
Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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 by sa547
Link to comment
Share on other sites

  • 1 month later...
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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by mattski123
Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.