• Previsbines are pre-generated CELL information and files that the game uses to reduce what it needs to render and thus increase the game FPS (especially on Systems with low end Graphics).
• Previsbines are either On or Off for each Cell in the game, and this is determined during Game startup (based on the plugins loaded), not as you are playing - and is not kept in the saves.
• A Cell can have Precombines and no Previs, but it seems the game does not allow Previs without Precombines.
• Precombines (and thus Previs) can be deliberately disabled per Cell by removing either of the Cell's XCRI or PCMB Fields.
• Previs can be deliberately disabled on it's own by removing the Cell VISI field, or by setting the Cell flag "No Previs".
• The game can also decide to disable Precombines (and thus Previs) for a Cell during Game startup. See "Game Startup Previsbine checks".
• Previsbines can also be completely disabled for the whole game via an ini setting ( "bUseCombinedObjects=0").
  

The Game will run fine with Previsbines disabled for a Cell, just your FPS will probably drop when that cell is rendered.
Remember all Cells are rendered within "uGridsToLoad" range. This means you can get FPS drops from Cells (with disabled Previsbines) that are a distance away from you.

NOTE: The Game does not support previsbines for new cells created (mastered) in an "ESL" flagged plugin, so don't create new worldspaces or interiors in a ".esl" or esl flagged .esp plugin and expect to be able to create previsbines for them. This is a Game bug.

A Precombined reference is a reference on a Cell (master or override) that places a precombineable object into the Cell, and

• Is specified in the XCRI field of the (winning) Cell override as being included in a Precombine Mesh.
• Is NOT rendered, because the Precombined mesh it is included in is rendered instead (which contains a snapshot of this reference).
• This means subsequent changes to this reference are ignored (until you rebuild the precombine containing it).
• It is therefore UP TO YOU to make sure you rebuild Precombine meshes if you (or a mod) changes the references in it.
• The game has a check if such changes are made, but relies on the VCI1 of the reference being updated (see "Game Startup Previsbine checks").
• Manual editing of a Precombined Reference via FO4Edit will normally set VCI1 to 'None' (which is interpreted as a far future date).
• Editing via the CK will set the VCI1 date to today.
  

A Precombine Mesh is basically a single mesh built from all the individual meshes of the Precombined Objects it contains.

• Apparently displaying this one big mesh is less GPU intensive (fewer Draw calls) than lots of smaller ones.
• Both the Precombine Mesh, and the precombined References they are built from, MUST be declared in the Cell's XCRI field for the game to use them.
• Precombine meshes (the files with extension ".nif") are actually stored in the "Data/meshes/precombine" directory (or the equivolent path in a plugin's "- Main.ba2" archive).
  

The Previs file is mostly like an 'index' into all the Precombine meshes of a Cluster, and

• Contains 3D positional information of every object in those Precombine Meshes. This means you cannot correctly build a Previs File until you have built all the Precombine Meshes it will use first.
• The Game uses this Previs information to only render those parts of these Precombine meshes that are in front (visible to the Player).
• This also means that a Previs file will only work correctly with the Precombine meshes it was built with.
• A mismatch will mean parts of objects will be displayed incorrectly based on the Player's view (flickering).
• The Previs file also includes all the Landscape heightmap information for a cluster, so hills etc  will occlude objects behind them.
• This is why changing a Cell's Landscape (LAND) record can also cause flickering (until you rebuild Previs).
• Lastly Previs contains occlusion information for some Static but non-precombineable objects (like Furniture).
• These objects are listed in the XPRI records of cluster cells, and they are only rendered if not occluded.
• Moving such objects without rebuilding Previs will cause them to 'disappear' at incorrect viewing angles.
• Previs files have the extension ".uvd" and are actually stored in the "data/Vis" directory (or the equivalent path in a plugin's "- Main.ba2" archive).
  

A Previs Cluster is 9 Exterior Cells (3x3) that share a common Previs file (<ClusterCenterID>.uvd), and

• The Cluster Center Cell ID will be specified in the RVIS of every cell in that Cluster (mostly, but sometimes is missing)
• This Center Cell has a Grid (XCLC) X,Y coordinate that is a multiple of 3 ("0,0", "-21,12" etc) with the remaining cells at +1 or -1 (X and Y) from it.
• A Cell cannot be part of more than one cluster (obviously), and Interior Cells are not in a Cluster (basically they are their own Cluster).
  

Note that removing the RVIS field on exterior cells does nothing (but is not recommended).

The Game follows a "Rule of 1" for everything it uses, so only the last override of a Cell matters (wins).

• This override specifies the PCMB/XCRI/XPRI etc Fields the game uses.
• This also applies to Previs Files and Precombine Mesh files. The file in the Archive of the lowest Plugin (with that file) is used.
• A Plugin's archive can contain these files even if it has no relevant CELL records in it's esp file.
• However, doing that makes tracking down the plugin supplying the 'winning' version of these files difficult, so ill-advised.
  

Note that a loose version of these files (in the Data/Meshes/Precombines for Precombine Meshes, or Data/vis for Previs files) will ALWAYS be used instead.

Interior Cells can use an older system of "Roombounds & Portals" if standard Previs is not enabled.
Roombounds determine the boundaries of a room in the interior, while Portals are gaps in them that you can see through to other rooms.
They are used to limit what needs to be rendered (you don't render past the roombounds unless you have line-of-sight through a Portal).
If the Interior Cell was meant to use Previs, but a mod has disabled/broken it, then you may find "voids" in the walls/doors.
This indicates the Roombounds have not been set up properly (as they were not expected to be used) but the game is trying to use them.

Note that lack of Previsbines in an interior cell is normal. Many interior cells do not benefit from the optimization so Bethesda didn't bother,
or perhaps the Dev involved wanted to use RoomBounds instead. Who knows...
The issue comes when they DO have previsbines and a Mod override has disabled/broken them so it drops back to Roombounds.

The following process occurs when EACH cell override (in a Plugin) is read, so the precomb/previs state changes after each override.
There appears to be an internal 'NoPrecomb' and 'NoPrevis' state maintained during this process for each Cell.
The game DOES NOT just look at the winning override to determine this state.

The first Plugin to declare cell is considered the Master (and must not be set Partial), otherwise the Cell record is an override.
Plugins are read in the order they appear in FO4Edit (which is not necessarily what you see in your Mod Manager).
On loading of each subsiquent Cell Override the current Cell settings are updated:

• If the Cell override is not flagged PartialForm its Record Header flags becomes current. The 'No Previs' flag sets the internal 'NoPrevis' state.
• If the Cell override is not flagged PartialForm then its PCMB becomes current (even if blank).
• If the resulting current PCMB is blank then the internal 'NoPrecomb' state is set (otherwise it is cleared).
• If the Cell override is not flagged PartialForm, AND its XCRI is not blank (missing), its XCRI becomes current.
• If the Cell override is not flagged PartialForm, AND its XPRI is not blank (missing), its XPRI becomes current.
• If the Cell override is not flagged PartialForm its VISI become current (even if blank).
• If the resulting current VISI is blank then the internal 'NoPrevis' state is set.
• If the Cell is not a Persistent Exterior Cell then each Child References in this Cell override is checked, but ONLY IF:
  
  • The Child Reference is an Override, and type LAND, or REFR with a base type of STAT or SCOL.
  • The Child's Master is the same as this Cell's Master.
  • If the Child is a REFR then it must be listed as a reference in the current XCRI,  not have the X,Y coordinates set outside this Cell, be set as 'Persistent' (if in an Exterior Cell), or be in a different Worldspace/Interior cell.
    
• If a checked Child reference has a VCI1 date of 'none' then the internal 'NoPrecomb' state is set.
• If a checked Child reference has a VCI1 date > the current PCMB then the internal 'NoPrecomb' state is set.
• If the resulting internal 'NoPrecomb' state is set, then 'NoPrevis' state is also Set.
  

Note that All Previsbines in the entire game can be disabled via the "bUseCombinedObjects=0" ini setting (Don't do this!).

Also the console command "tpc" can be used to toggle Previs off and on.
If Previs is disabled by the game you will not be able to turn it on (you get a message saying this).
This is a useful way to know if previs is disabled in your current cell.

Another useful console command is "tb" (toggle borders). Yellow borders will be visible on cells if Previs is disabled.
Note: Borders will appear, even if Previs is enabled, if you fly.

If Precombines are enabled:

• NO references in the Cell's resulting XPRI or XCRI 'references' list are rendered.
• All remaining objects (except LANDscape) are rendered normally.
• All Collision is enabled, however the collision of Precombined objects comes from the precombine meshes/physics files, not the references.
• The current state of the precombined objects (REFR) are ignored (even if deleted/moved) as they will be rendered from the precombine meshes.
  

THEN, If Previs is enabled:

• System dynamically renders those parts of the precombined meshes that are not occluded.
• It dynamically renders references in the XPRI list if they are not occluded.
• It (dynamically?) renders those parts of the LANDscape that are not occluded.
  

Otherwise, If Previs is disabled:

• All LANDscape and Precombine meshes/XPRI objects are fully rendered

Nothing. Precombined references will ALWAYS be rendered in the original location, as they are snapshoted into the precombine mesh.
It does not matter what you do to the reference via overrides - even deleting them, or moving them to another Cell/worldspace.
HOWEVER the object reference will ALSO be rendered in it's new location (i.e. duplicated) if the winning override:

• has not deleted/disabled it AND
• changes it's coordinates such that it moves into a different cell OR
• moves it to a cell in a different Worldspace OR
• changes it from interior to exterior (or Visa-Versa)
  

Note1:  Changing the Ref's persistence is ignored (even in exteriors), the above still applies.
Note2:  The Ref's VCI1 is no longer checked during game startup (so can't disable Precombines) if the move is to a different Cell (including the Persistent Cell).

References listed in the XPRI of a CELL are non-precombineable, non-moveable, non-scrapable objects that also have occlusion information in the uvd file.
Such references are only rendered if they are not 100% occluded by another object - thus reducing the cell rendering load and improving FPS.
So far the game has used the following types of base objects in XPRI: STAT,SCOL,FURN,CONT,MSTT,ACTI,TACT,FLOR,HAZD,PROJ,TERM.
Both Persistent and Temporary references can be in XPRI, reguardless of whether it is in an interior or exterior cell.

References in XPRI are only rendered if the information in the uvd file says they are not occluded.
This means adding objects to XPRI, that the uvd knows nothing about, will cause that reference to NEVER be rendered (invisible).
Such invisible objects can still however be interacted with (sat on, Activated, collided with, etc).

Game (and CK) XPI Bugs:

1) A CELL override with a blank (empty) XPRI field is IGNORED , meaning that a Cell's current XPRI list will be from the previous override.
This will be an issue if an empty XPRI is meant to mean 'no XPRI references' (as is normally generated by the CK).
What then happens is the previous override with non-empty XPRI field will be used - which commonly means those XPRI entries will not be in the winning uvd and thus be invisible.

2) There is a bug in the game where XPRI (and RVIS) local formIDs are NOT mapped  to Load Order ID.
This means If the internal 'local' FormID of an XPRI reference is not the same as it's Load Order ID then it will be basically ignored (as it will now be for an object not in that cell - if it is even valid). As a consiquence all CELL overrides with XPRI need to have the same Masters list (and in the same order) as the Load order for their XPRI references.
This is easy to manage with Base Game and DLC's (just include them all), but almost impossible with Mod supplied new Cells/references.
Generally this only means such cells do not get a performance benefit from references in XPRI.

As different Plugins can "win" different parts of a cell's Precombine (the CELL information, the files, etc) - mismatches can occur and thus Previsbine faults
(as long as precombines remain enabled for that cell).

In Precombines, faults can show up as 'missing' objects, but most generally appear as missing changes (Changes to objects by a Plugin aren't seen in
the Game):

1) If a Plugin "changes" (deleted/moved/disabled, or changed base form etc) a Precombined Reference, but with no corresponding change to the Precombine Mesh, then that change is ignored.

2) Conversely, if you have a Cell Reference in the XCRI that isn't in the Winning Precombine Mesh, then that object will not be seen in game (invisible).

3) BUT, Invisible objects you can still interact with (like an invisible chair you can sit on, or select in the console) are not precombine issues but Previs. If
an object is listed in the XPRI of a cell, but the previs (uvd) is mismatched (was built without that object), then that object will be invisible.
NOTE that you can still get this if the winning CELL override's XPRI is empty - as a blank XPRI is ignored so the game will use the last non-blank XPRI override.

As mentioned previously - precombined References are not rendered, instead only the Precombine Mesh they are in is rendered. This is why overrides to Precombined References are ignored - even If an override moves a precombined reference into a different cell/the persistence cell.

The Basic rule is the winning XCRI must match the winning Precombine meshes it specifies, and the winning Precombined References they are
composed of.
NOTE that blank XCRI fields are ignored, so the 'winning' XCRI is from the last override with an actual XCRI field.

4) Just misplaced Collision (invisible walls) is less common but can occur as some precombined objects have their collision moved into a separate "Physics" file (one per cell). If a Mod overrides/replaces this improperly then weird collision issues can happen.

5) Duplicated Objects will happen if an override moves a precombined object to a different Cell (by changing it's x,y coordinates). It will stll be rendered in it's original location (as it is still in the precombines & XCRI of that original Cell), but also in it's new Cell (as normal).

6) Texture "Smearing" (an object turns into a sky high wall). This is actually a problem with a malformed mesh on a precombineable Static Object. When that object is put into a precombine mesh by the CK it causes this 'wall/smear' effect. The only solution for this is to fix the mesh (run it through 'Elric'), or exclude it from precombines entirely, before building precombines. FO4FindPCStatics.pas script should find these Bad meshes and allow you to exclude them.

In Previs (occlusion):
As Previs in Exteriors is generated from 9 Cells (a Cluster) worth of Precombine Meshes, you now have 9 times more mismatch opportunities - which is why Previs faults are very common.

Previs faults show up as 'flickering' (parts of structures disappear/reappear as you move). Basically the Previs (Occlusion) information points to the wrong Precombined Objects so hides/Shows the wrong things.

A common situation is a Plugin changes Precombines in one Cell of a Cluster (whose Previs File was built without knowledge of that change) - now you have Previs faults (flickering) in that cell.

Alternatively, that Plugin may also supply an updated Previs file (To fix that Cell) but now the other 8 Cells could have Previs faults.

A less annoying category of faults is objects apparently being occluded by "nothing" from certain angles.
This tends to happen if the Landscape for a Cell has been changed (say removing a hill) but the Previs not rebuilt. The Previs still encodes the old landscaped hill - which would have 'hidden' objects.

Adding/Removing XPRI entries (or moving the object they point to) can cause the same thing. The Previs system will still think the original object is in the same location, so 'hides' things behind it. Worse, objects in XPRI that are not known to the previs system will be invisible (say you update the uvd but not the XPRI).

Another common issue with Previs is failure to build Previs. The CK can just time-out while building Previs because it gets itself into a loop. Generally this occurs if too many objects exist in the same location. This is very common with some 'object sink' locations in every worldspace near the 0,0 Cell as it seems the CK will place deleted objects there. Look for a lot of objects in any cell you cannot create Previs for...
This Cell of Atomic World had 286 objects at(1128.798340,-1837.827637,-938.216370) of Cell 0,-1 of zzwestward (xx67622C) failed to generate Previs...

Firstly only Cell references with a "base type" of Static (STAT) or Static Collection (SCOL) can be precombined, and even then they will be excluded if the Cell Reference (REFR) is:

• Disabled or Deleted
• Has any of the following fields - XESP, XATR or XEMI
• Has Linked References (XKLR) with a keyword of anything other than MultirefLOD
• Has a Location Ref Type (XLRT) of NoObjectCombinationReftype or BlockPreVis (seems ANY value in this field will exclude it)
• Is flagged Persistent (only in an exterior Cell and only in a "Master" plugin) - meaning if an override sets it persistent it will still be precombined.
• linked to by another linked ref (e.g. on another linked reference)
  

The Reference will also be excluded if it's "base type" has any of:

• A Workshop recipe (but only for Cells in a Settlement)
• The "Forced Location Type" (FTYP) set with ANY value.
• The mesh used (MODL) has certain configurations (visible in NifScope):
  

• BSXFlags with settings "Animated", "External Emit", or "Havok"
• Has Nodes with Block types of NiBillboardNode, NiSwitchNode, or NiParticleSystem
  

Note that a Reference flagged "Persistent" is handled differently based on whether the Cell is interior or exterior.

All "Interior" references (temporary or persistent) are precombineable.
In "Exteriors",  when a Persistent reference is defined it is actually placed in a special "Persistence" Cell. As this is now a different Cell it is not precombineable.
HOWEVER it gets messy if you 'overide' this Exterior reference (in a plugin) to change it's persistence:

• A Persistent REFR changed to Temporary will still not be precombined (as it's 'home' Cell is still considered to be the special 'Persistence" cell).
• A Temporary REFR changed to Persistent will still be Precombined, but may cause display issues as the Renderer will not consider it precombined.
  

There are only 2 ways to generate Precombines and Previs - via the Creation Kit GUI or via the Creation Kit command line.
Generating Precombines or Previs are 2 seperate operation either way.

The Creation kit GUI can only create "Filtered" Precombines, whereas the Command-line can generate them "Clean" or "Filtered".
The same options exist for Previs but are meaningless (Previs files are basically only "Filtered").

• "Clean" Precombine meshes are effectively 'de-duped' so common object meshes are contained in a separate "Plugin - Geometry.csg" file - thus reducing the overall size of the Cell Precombines. "Clean" Precombines are only possible via Commandline options.
• "Filtered" Precombine meshes are not, so will generally be much bigger (5-10 times) than "Clean".
  

 
NOTE: XBOX does not support Previsbines built using the "Clean" method (because Bethesda.net won't allow you to upload .csg/.cdx files).
         
The CK's Precombine generation process has a couple of bugs you should allow for:

• Material Swaps only on the Base Object of a Precombineable reference are ignored. This means these references will revert to default (Mesh specified) textures. There are scripts available that will add such Base material swaps to the Precombineable references so they get their correct textures. My seed builder does this automatically.
• The Alpha channel field (XALP) of Precombineable references are ignored. An exampe is paintings that use the alpha channel to give them a 'moth eaten' look will become 'pristine' in Previsbines. The only solution is to exclude these from being precombined. My Seed builder script also does this automatically.
• Static Meshes created from SCOLs, or by "kitbashing" a number of objects together, can crash the Precombine Process. These will need to have their collision rebuilt, and changed from being 'high precision'.
• If using the "Clean" method you cannot have spaces in the name of the mod your are building Precombines for as the CK does not support spaces in the .cdx file name.
  

Note also: The CK commandline build option WONT build precombines for Exterior CELLS outside of the Border Region(s) used in that Worldspace.
i.e. If your worldspace has a border region that only covers half of it's cells, and at least one cell in the worldspace includes that region, then you will not be able to make the CK build precombines for those cells outside that border. Why? Ask Bethesda...

The CK's Previs generation process has some issues too:

• During Previs building the CK must be able to see all the precombine meshes (nif files) of all the 9 Cells it is built from.
• These meshes can be in BA2 archives (to speed up the Previs generation) or as loose files.
• Also the Previs operation does NOT use any textures so you can remove these to reduce the amount of memory the CK uses.
     This can be critical as the Previs operation itself generally requires A LOT of memory.
• Some (unknown) conditions can cause the CK to hang when building some clusters. These will timeout eventually with an error in the log.
  

IMPORTANT: The (unpatched) CK has a limit on the number of unique references it can load (2097152), after which it will ignore the excess (and thus make corrupted previsbines).
As the Base game and DLC's is 86% of this limit - adding new game content will generally exceed this limit.
The only recommended solution is to set the "BSHandleRefObjectPatch=true"  (in CKFixes) or bBSPointerHandleExtremly=true (in CKPE), which vastly increases the limit.

Finally, the CK is a delicate beast - DO NOT do anything else on your computer while running these previsbine tasks.
Running out of memory (because you have 10 browser windows open too) is a sure fire way to generate corrupted previsbines.

The original Bethesda version of Creation Kit has been extensively tested for building previsbines.

However, the new Steam version can be used, but you must make sure it can determine it's steam 'appid' otherwise it will fail/prompt.
Make sure you have file "steam_appid.txt" in the same directory as the steam "CreationKit.exe", and that it contains the single line 1946160
If you run the CK via MO2 then you also need to specify that appid in the settings for that external Creationkit.exe program.

It is recommended you use the latest version ofCreation Kit Platform Extended (CKPE), V0.4 in an FO4/CK NG environment.
This fixes a great number of issues with generating Precombines and is a "Must Have".
Note that as of Jan 2025, this version does NOT work well with OG version of CK (building Previs). V0.3 (NG archives) or V0.2 (Pure OG) is better.

Make sure you edit it's Config file (CreationKitPlatformExtended.ini) and set bBSPointerHandleExtremly=true so that it can handle your full load order. I have include my version of this file as an optional file download as well.

• It is best to do this in Clusters to reduce the build time, so group the Cells you plan to generate Precombines for into the Clusters they are part of.
• For each such Cluster, find the Cell in the "Cell View" list you want to build precombines for, select 'view' and wait for it to be rendered, then select "Precombine Geometry for Current Cell" off the "World" Menu.
• The Cell Preview window will freeze during this so wait for it to become active again, then Repeat with the next Cell in that Cluster, etc.
• I suggest you regularly "save" after each cell as the CK is prone to crashing.
• Once you have done all the Cells you plan to in that Cluster, Select "Generate Precombined Visibility for Current Cell" off the "Visibility" menu. This will take a long time and finish with a confirmation box.
• Save again and repeat for the next Cluster until you are done.
  

Note that due to a current bug, the achives of the currently "active" Plugin will not be used by the CK, so you need to extract them out as loose files.

The Creationkit.exe has 2 options for this, -GeneratePrecombined and -GeneratePreVisData, however this process has many more steps and involves merging the results of these steps back into your Previsbines Plugin.

I will not go into it here as Myself and others have created procedures for this. My process (in this Mod) handles ALL those steps (including Material Swaps, Alpha Channel, and many edge cases). Check out my article on this subject for more information.

If you want to do things manually, or use some old scripts you found mentioned elsewhere, then good luck...
However, you need to know how the Commandline determines what Cells to build previsbines for:-

• The Plugin you specify when running these command line arguments (generally refered to as a seed mod) must contain a Cell record (override or Master) for EVERY Cell you wish to build Precombines for.
• Those Cells must each contain AT LEAST one Cell reference (does not need to be precombineable). This will trigger the CK to build Precombines for it.
• Similarly the Cluster that Cell is part of, AND ANY OTHER CLUSTERS IT IS ADJACENT TO, will also have Previs built for it (-GeneratePrevisData).
  Note that this means a Cluster 'corner' Cell will potentially cause 4 Clusters to have their Previs generated, while a 'middle' cell will only generate Previs for it's own Cluster.

Note1: -GeneratePrecombined creates a mod "CombinedObjects.esp" that contains ONLY cells the CK has generated new Precombines for. Also note that only the PCMB, XCRI, and Cell VCI1 are valid (the rest is rubbish).

Note2: -GeneratePrevisData REQUIRES the cells of your seed to have these new PCMB and XCRI values BEFORE it runs (otherwise it won't work properly). It creates a "Previs.esp" mod containing Cells for every cluster it creates Previs for, but only the VISI, RVIS, and XPRI fields are important.

Note3: Generating Previs takes A LOT of memory, and if you run out you will end up with corrupted Visibility (or a crash). You can reduce the chance of this by temporarily removing all <mod> - Textures.ba2 files before generating Previs (as that process does not require textures, but the CK will load them).

A full guide to resolving CK crashes is in a seperate article. This is just a brief list of common failures you may get:
- Access violation 0xc000005 (or similar) during Precombine building

This is normally due to a corrupt/incompatible Mesh on a Precombineable Reference (i.e. a REFR with base type STAT or SCOL).
Almost always from a new mesh/object introduced by a Mod, however using the mesh of an SCOL as a STAT will cause this.
 Mesh with 'high precision' set (such as above mentioned SCOLs) will always cause a CK crash.
 A rarer situation is a bad Texture on a Precombineable object (from a texture replacer Mod)

- Error -1073740771 (or STATUS_FATAL_USER_CALLBACK_EXCEPTION or 0xC000041D) at the end of a CK phase

If you see the CK saving successfully beforehand, then you can probably ignore this.

- Hundreds of "DEFAULT: OUT OF HANDLE ARRAY ENTRIES" errors in the CK log during Precombine building

This is caused by having a total of more than 2 million (2097152) Cell references.
Just the Main program and DLC's account for 1.8 million so it is easy to exceed with Plugins that add new content.
The only real solution is to use CKPE and set the "bBSPointerHandleExtremly=true" ini setting.

- "ERROR: visibility task did not complete." message  in the CK log during Previs building

This means a Cluster Previs file could not built because the CK hung during that operation.
This does not crash the CK, or stop other Clusters Previs from being built, but that one Cluster will have no Previs file (basically as if set to 'no Previs').
The cause of this is some NON-PRECOMBINED , enabled reference(s) in those 9 Cells of that Cluster has a problem with the Occlusion build process.
One common cause I have found is too many objects in exactly the same location (usually under ground as some sort of unused reference dumping ground).
Using the CK to visually examine every Cell in the Cluster usually shows these up. Disabling these unwanted Refs should resolve the issue.

- Running out of memory during Previs building.

The Previs build phase is at least twice as long as the precombine phase, and can consume a huge amount of memory.
48GB of memory usage is not unknown. Even though you may have a lot of 'virtual' memory, physical memory limits (working set) can cause issues.
Try to have as little as possible running at the same time, and possibly disable your Antivirus.
Another option is to remove all Texture archives before building Previs, to stop the CK loading them and consuming memory.

You built your new Previsbines and yet one area of a Cell still flickers. How annoying!
If you are 100% sure no errors occured during the build process, you left your computer alone, and followed all the guides, then it may not be your fault.

Some objects just don't work well with preculling, such as particularly thin objects or see through railings, and can cause Previs faults.

You may just have to give these Precombineable References a Location Ref Type (XLRT) of BlockPreVis so they are excluded from Previs,
 then rebuild that Previs file.
Alternatively you exclude the Base object of this reference from all Previs by setting the Base Object's "non-occluder" Flag.

Severe flickering can occur when large precombineable objects straddle two adjacent clusters (such as a buildings in a Town).

This occurs because the object is in the precombines of the Cell in one cluster (A), but that precombine mesh extends into the
 neighboring cell in a different cluster (B). See this example of Cliff Edge Hotel:


In these cases Cluster B's Previs will include some information from those precombines in Cluster A.
Now if you rebuild Cluster A's precombines, The information in Cluster B's Previs no longer matches it and you get classic Previs faults.

(You can see the cluster border in purple nearby - generated by AutoCellDisplay Ring you can download here)

This occurs quite commonly if you Rebuild Previsbines for a whole Cluster, but the adjacent cluster is from a different Mod (say PRP), and you have
 a building, road section, etc with parts from that cluster appearing in your rebuilt cluster.
I suspect this is the reason the CK always wants to rebuild previs for all the Clusters that are adjacent to the Cell (to catch this one case).

Unfortunately the solution is you need rebuild the Previs for your cell while that other cluster/mod is also loaded. If it is (say) PRP then you need to make
such a PRP specific version of your Previsbines. HOWEVER, if it is just one reference that overlaps (say a road chunk),  then you could exclude it from
 precombines entirely (meaning you still need to rebuild your Precombines/previs).

This only works for your cluster previs if the reference is declared outside your cluster.
If the reference is in your Cluster and extending into another Cluster, then unfortunately you will have to rebuild that Cluster and include it in your mod.

Transparent Windows are another cause of Previs issues.

As you walk past them some may not accurately render the view (or render no view).
This can also happen when windows are close together.

The only real solution is to exclude the problem window from Previs via the above "BlockPrevis" method
 (or any other method to remove it from Previsbines).

Smeared Textures (sky-high black or coloured walls)

This is due to a faulty Reference (Static Mesh) that has now been included into your Precombines.
Such meshes break the resulting Precombined mesh and cause this error. High Precision meshes will always do this.
This commonly occurs if you use the mesh from an SCOL as a STAT (as such meshes are 'High Precision' so cause this issue).
Your only option is to find and remove this reference from being precombined, and rebuild the precombines.

This is possible but requires extra work, but also is not recommended (or useful) if those precombines were generated 'Clean' (with a .csg file).

This is because 'Clean' (shared Geometry) precombine meshes contain "BSPackedCombinedSharedGeomExtraData" nodes which contain the "hash" of the filename of the shared Geometry (.csg) file it uses.

This means you cannot rename the "<plugin> - geometry.csg" when you rename <plugin>.esp - so you still need a <plugin>.esp file in your load order (so the game loads the csg file) making renaming useless.

At this time it is unclear what renaming the "<plugin>.cdx" would do, but due to the above any attempt would also be pointless/cause issues.

If you are using "Filtered" precombines (no shared Geometry), however, then you CAN rename the plugin,
HOWEVER, if that plugin 'mastered' any cells (i.e. added new interior Cells or exterior Worldspaces) then you need to also rename the subdirectory all it's precombined meshes (nif) AND previs (uvd) files are stored under (whether loose or in ba2 archives).

This is because the game looks for these under the paths "Meshes/Precombined/<MasterModname>/" and "vis/<MasterModname/" respectively.
So if you renamed the <MasterModname> plugin for these cells then you MUST rename these subdirectories too.

Note that these paths are NOT stored in the Plugin itself but are determined at runtime. xEdit just displays these paths (for instance in XCRI) for your convenience. There is NO need to try and edit these in xEdit (in fact you cannot).

All that is actually stored in the XCRI "Combined Mesh" field is the 'Hex ID' used in the mesh's filename "<CellFormID>_<HexID>_OC.nif"

The Previs (Occlusion) filename is "<PrevisCellFormID>.uvd" where <PrevisCellID> is the Interior Cell ID or the Exterior Cell ID of the Center cell of the Cluster.

Note that (strangely) the game does NOT use the RVIS field as this <PrevisCellID>, instead it works it out at runtime (RVIS is ignored).

To add any Object into a Cell you need to create a Cell Reference, as well as an override on the associated CELL record, in your Plugin.

Your Plugin could have the winning Cell override in someone's Load Order - so then you will override that Cell's PCMB etc fields and so possibly cause Previsbine mismatches/ visual faults.

Adding the "Partial Form" flag to your Cell override tells the game to ignore that override, which would prevent this issue.

However, this is NOT a good idea unless you know 100% that the cell's override before yours was from an "esp" type plugin (such as PRP.esp).

This is because using "Partial Form" has problems if your plugin has the only override for this Cell, and that cell was created in an "esm" type plugin (like fallout4.esm).

For this reason I would not reccommend using "Partial Form" on the cells in your mod unless you are making a Patch that requires PRP.esp.
There are some odd effects with persistence that will allow Partial Form to work otherwise, but I would not rely on it.