=======================================================================

Skyrim TVDT - Occlusion Data

This option is available for Skyrim (TES5), Enderal (ENDERAL), Skyrim VR (TES5VR) and Skyrim Special Edition (SSE).

=======================================================================

TVDT

The TVDT - Occlusion Data record defined on a CELL record defines the visibility of terrain and object LOD for that cell. 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.

The vanilla game only includes this data for the Tamriel worldspace. Notably it was also not generated for DLC2SolstheimWorld. The vanilla pre-computed occlusion for Tamriel is famously wrong for several cells, resulting in rectangular holes in the LOD. Any attempts to generate the data with the CK seem to be unsuccessful.

The TVDT - Occlusion Data is a z-order curve bitmap lookup table for each quad (LOD) level up to a maximum of 256x256 of cells. The area is fixed (each quad always uses the same bit regardless of the relative position to the current cell) and has its origin at the south east cell defined in the lodsettings. The actual maximum is defined by the stride value also defined in the lodsettings file.

In order for TVDT occlusion to be applied, the CELL record also needs to have the MHDT - Max Height Data. Based on this data the engine knows if the player is the "same" elevation as the terrain/objects that were used to calculate the occlusion. If the player is higher - for example because of flying with a dragon - then all TVDT occlusion is ignored. MHDT - Max Height Data on the worldspace record seems unrelated/unneeded in this context.

=======================================================================

Generation

xLODGen calculates the TVDT - Occlusion Data based on the current terrain height data from the loaded plugins and complements it with the height data from the existing terrain (in case of cut content) and object (to determine the maximum height of things) LOD meshes. Thus object LOD should be generated for the current load order before generating occlusion data. LOD files found in the output folder take precedence over files in the data folder, so occlusion can be generated in the same session as object and terrain LOD.

It is suggested to only generate the data for large worldspaces like Tamriel or DLC2SolstheimWorld or large new world mods. It seems futile to generate it for small worlds like Blackreach, SkuldafenWorld etc.

As a rule of thumb, the world space needs to be large and has terrain elevation changes which potentially cover distant LOD. Use tll in console to see if turning off LOD results in better FPS or less CPU/GPU usage to determine if calculating occlusion may help performance. Afterwards use tfc in console to verify if rectangular patches of terrain and object LOD are disabled (works better in Skyrim, as Skyrim Special Edition cycles through LOD levels rapidly).

If a cell record is missing its MHDT - Max Height Data, xLODGen also calculates it from the terrain height data and the object LOD as a best effort so that the occlusion works in the cell. CK calculates the MHDT - Max Height Data using the terrain height data and the collision meshes from full models - which seems more thorough as it covers more objects. For now it is recommended to use the CK to generate MHDT - Max Height Data if it is important for correct dragon flight or if unforeseen issues arise from the data calculated by xLODGen. Missing MHDT - Max Height Data on the worldspace record is not generated as it seems unrelated to occlusion.

If there are child worldspaces (e.g. walled cities) using the selected worldspace for LOD, their TVDT data will be updated as well.

=======================================================================

Occlusion.esp

When running in xLODGen mode or if generating LOD/occlusion for Skyrim.esm or several plugins at the same time in xEdit mode, a new plugin Occlusion.esp will be generated. It will contain the WRLD/CELL records from the winning overwrite with the updated TVDT data.

If Occlusion.esp already exists in the load order, and it already contains data for the selected worldspace, that content will be replaced. That means, first the selected worldspace will be deleted from the Occlusion.esp and then the WRLD/CELL records will be copied from the winning overwrite again and then updated with the new TVDT data. If the specific chunk option is used, then only the affected CELL records are replaced. The WRLD records and all other CELL records are left untouched. For occlusion generation the "empty" dimension drop down means to update the cell with the coordinates entered into the W and S form fields.

To update the CELL records in a specific plugin, start in xEdit mode, right click the desired plugin, select Other, Generate LOD. Note the text next to the Occlusion checkbox mentioning the plugin that is updated. Skyrim.esm can not be updated, so instead it will create the usual overwrites in Occlusion.esp.

In case an Occlusion.esp has been generated for the current load order, it typically should be the last plugin to overwrite, so its CELL records with the updated TVDT are not overwritten. Alternatively it can be used to update or merge with other plugins. For Skyrim Special Edition the plugin is automatically flagged as ESL as it only contains overwrite records.

=======================================================================

Options

Hover the mouse pointer over the dropdowns to see additional hints.

Quality - samples per cell. The more samples are used the more distant cells are potentially disabled. Generally use 2 for a quick update. Use 3 if time permits - it typically results in a few more areas that are disabled. Total time depends on selected mode (number of cells that need to be updated) and hardware. Quality 2 is reasonable quick with a large worldspace may be taking a minute or two. Quality 3 can easily be a couple magnitudes slower than quality 2. It may have to compare up to 256 (16 x 16) samples between two cells instead of 16 (4 x 4).

Height - the algorithm uses the highest point of the height map or object LOD between two samples points. Since the player itself could be standing on the highest point, this can add a bit of additional height if required.

Radius - the engine renders about a 100 cells into the distance, so there is no need to show or calculate the visibility of  cells beyond that limit. Could be used to artificially limit render distance of LOD for potatoes.

Mode - helps to limit the amount of CELL records that need to be processed. This either applies for all available CELL records for a worldspace (LODGen mode) or just for the CELL records that already exist in the highlighted plugin(s) (Edit mode) - regardless if the records are added or overwritten. CELL records without terrain height data are always skipped. -Flat means to skip cells with terrain height data that is perfectly flat - it typically means the cell is way outside the playable area. +Border means to only process cells if they are linked to a region that has the Border Region flag set - since the player is normally restricted to cells inside the border region. Do not use +Border for plugins which require to disable borders in the Skyrim.INI. Do not use if no suitable cells are found in case the worldspace has no border region defined. +TVDT will update cells that already have TVDT data and -TVDT will update cells that do not already have TVDT data. +Border is ignored for child worldspaces that use the selected worldspace for LOD.

Specific chunk - use the option to limit TVDT updates to a specific area of 1 (empty), 4x4, 8x8, 16x16 or 32x32 cells starting with the lower left coordinates entered into the W and S form fields.