• 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".
  

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.

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, its XCRI becomes current.
• If the Cell override is not flagged PartialForm its XPRI and 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 'Deleted' flag, nor have the X,Y coordinates set outside this Cell, or be set as 'Persistent' (if in an Exterior 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.

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.
• 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 .csg/cdx file names.
  
  

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" option to true in CK Fixes ini (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 HIGHLY recommended to also use the latest version of F4 CreationKit Fixes mod (V2.0.1),
OR the new version of it called "Creation Kit Platform Extended" (CKPE) V0.2 build 734 or later.
This fixes a great number of issues with generating Precombines and is a "Must Have".

BenRierimanu/Starhammer (of PRP fame) has available on the Collective Modding Discord a tuned config ini (for CK Fixes) that is also recommended. I have include this 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).

Apart from the above mentioned occasional crash when using the GUI method, here are a few other 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).
• It will be hard to find (as the CK log will not include what crashed it, only what didn't). HOWEVER, the CK log will end on the Cell it is building so at least you will know which CELL has the problem reference(s). Look for the last "DEFAULT: Generating for cell <cell EDID>..." line. This log will be called CK.log in the same location as creationkit.exe (if you use my suggested CK Fixes ini).
• Focus your attention on 'new' meshes provided by user plugins (as the Game supplied ones are ok) that are used in Precombineable references.
• You should also take notice of what Cells successfully created precombines, either earlier mesages in the CK log, or by looking in the Data/meshes/Precombine directory to see what Cells had precombines generated so far,  and exclude STATic meshes they use from consideration.
• I have created a script (FO4FindNewPCStatics.pas) you can run in FO4Edit against your problem cell that will list the most likely 'new' meshes, and allow you to exclude them from being precombined.
• You MUST run it against the problem CELL in your seed, as it can also update that selected Mod (so DONT run it against Fallou4.esm etc):
  
  • Open FO4Edit with your full Load order (normal way it opens) and select the problem cell (put it in the Formid box in the top left).
  • Now make sure the actual Cell override you are displaying is the one from your 'seed' . The simplest way is to right-click on the last column in the right hand pane (your Seed's override) and select "Jump to...". This will place the cursor on that Cell override in your Seed mod.
  • Right-click on it and select "Run script.." and specify FO4FindNewPCStatics and OK.
  • It will scan all references for that cell (from ALL mods), determine which are precombineable, and where their mesh came from.
    It will then only list those STATics that use a mesh NOT supplied by the base game, DLCs, or PRP (i.e. new modder created).
  • I would now (initially) select (tick) ALL of the Statics you are unsure about (i.e. have not been used in a Cell that successfully precombined).
    This will put an override in that mod for those statics with an "FTYP" to "NoObjectCombinationRefType". so it will never be precombined.
  • Now manually (via the CK gui) build precombines for just that cell (See above "Building Precombines Manually" point 2). Make sure you load JUST the seed mod into the CK!
  • Hopefully the CK won't crash (if it does the problem may be an SCOL - which is WAY more difficult to diagnose!).
  • Now you can just finish at that point, OR you could try and reduce the number of STATics you disabled, by redoing the above process and 'unticking' one static at a time, re-running the manual CK precombine build of that cell, and repeat until it crashes. Retick that static and move on.
    

• Once you have found the STATics with problem models (Meshes), you have 3 options:
  
  • 1) Get the Mod's Author to fix them (unlikely to succeed).
  • 2) Fix the mesh yourself using Elric and this guide by Jonathan on creating new collision
  • or 3) Leave the Static override (with FTYP of NoObjectCombinationRefType) you created in the seed via my script.
    

• You then re-run the Build Precombines phase of your process (if using GeneratePrecombines, restart (C) from the "Generate Precombines via CK" phase).
  

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

This is caused by your Seed Plugin (and every plugin master it uses) 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.
My only real recommendation is to use CK Fixes (which I also recommend) and set the "BSHandleRefObjectPatch=true" ini setting.

"ERROR: visibility task did not complete." entry 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').
At this time I have no idea what causes it as normally all 9 Cells in that Cluster will have had no problems generating their Precombines...

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).

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.
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).

The solution in this case is to rebuild just Cluster B's Previs manually.

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.
Your only option is to find and remove this reference from being precombined, and rebuild the precombines.

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.