Starfield Notes

Special Considerations for Starfield NIFs

Starfield support as of 2026-09-25

WARNING: Unlike earlier games, the location of the ancillary files (mesh, materials, morphs) is NOT associated with the location of the nif. You MUST set them where you want them using the above properties. If creating a new model from an existing nif, you MUST change these paths or you'll overwrite the original.

Nifs and Meshes

• Basic import/export of bodypart nifs works. Other types of nifs may work but have NOT been tested.

• In Starfield, the mesh data may be held internal to the nif (as with past games) or externally in a .mesh file. We support both, though external meshes have gotten the most testing. There are reports that head parts must have external meshes to show in game.

• External meshes may be given a filepath or a default may be used. Properties -> Object -> Pynifly Block -> Starfield Geometry -> mesh_path

• Morphs may be imported and exported. Starfield morphs have the fixed name "morph.dat" and are in either a "performance" (expressions) or "chargen" (face shape) directory. Morphs may be exported with the mesh. The path must be set in the shape properties. Properties -> Object -> PyNifly Block -> Starfield Morphs -> chargen_path and performance_path

• We do not currently support LOD levels (just 0), collisions, physics, controllers, or constraints.

Material files

• Starfield materials can use other material files as templates - a form of inheritance. Most materials inherit most of their structure, with tweaks for the particular nif. The hierarchy goes individual material -> shader model -> root. Some individual materials depend on other individual materials (e.g. right eye inherits from left eye).

• Starfield materials files have multiple layers with blend modes to combine them. See the Bethesda Library for details. Often the layers are defined at the "shader model" level, with the individual material providing property values and texture paths. Individual materials will list all the layers they depend on whether they modify them or not - only the layers they list will be exported.

• On import the hierarchy is flattened. Each layer is represented as image nodes feeding a "SF Layer n" group node. Layers are combined with "SF Blend Skin" group nodes. The Blender representation is as close as we can get it to the in-game look. The pyn_sf_nodes and pyn_sf_origin properties show the provenance of the various elements.

• A "PyNifly Material Chain" panel in the shader editor sidebar shows, for the selected node, shows which material in the chain set each value, so you can tell what is yours from what you inherited. "Claim for this material" forces a value to be written even where it matches the parent — for when you set it deliberately and want it to stay put if the parent changes.

• SF Base group nodes show you what a material inherits. One group per material in the chain, nested — your material, the shader-model template it derives from, the root template under that. These are only for documentation, to show the hierarchy - don't try to modify them.

• The materials file location is recorded in Properties -> Custom Properties -> BSLSP_Shader_Name. Make sure to set this especially if you started with a vanilla material.

• We optionally generate a materials file on export (the default is OFF). We look for the same structure as we create on import--if not found we show a warning.

The skeleton file

Prior games kept their skeleton.nif files in game units. Starfield does not - it keeps the skeleton file in havok units. If you import it into Blender you'll get a stupid small skeleton. If you want the complete skeleton in Blender, import from PyNifly's reference skeleton at io_scene_nifly\skeletons\SF\skeleton.nif (or scale up by 70).