fo76utils

No edits should be needed, you just need to install Qt 5.15 and C++ development tools, then run qmake and make. If you do get any compile errors on your distribution, I will update the sources on Git to fix them.

It does not for me on my build, I did not test dev7 though, so I cannot tell if it would have the issues you mentioned. I did encounter problems with the UI and rendering when running NifSkope under Wayland, which can be worked around by setting the environment variable QT_QPA_PLATFORM to xcb.

I have a fork of NifSkope that supports Linux, and is based on more recent code (dev9) with a number of fixes and improvements. I cannot reproduce the issue reported by DocClox, though, so I am not sure what may have been causing that. I use Linux myself and saving the paths works for me.

The list can be created with the mat_info tool that can be downloaded from here (note that you need to be signed in to a GitHub account to be able to access the packages). Use a command like shown below, changing the game data path as needed: mat_info -dump_list -all -o mat_names.txt D:/SteamLibrary/steamapps/common/Starfield/Data Or this to extract all materials to .mat files: mat_info -json -all D:/SteamLibrary/steamapps/common/Starfield/Data

More on the material database, it consists of two objects describing the list of materials, material objects and components, followed by all components. The first object in the CDB is of type BSMaterial::Internal::CompiledDB: BSMaterial::Internal::CompiledDB { String BuildVersion Map HashMap List Collisions List Circular } BuildVersion is the version of the game (currently "1.8.86.0"), and HashMap is a map from BSResource::ID to uint64_t. It maps material paths (represented as CRC32 hashes of the base name without the .mat extension and the directory name, and the extension that is always "mat\0") to an unknown 64-bit hash. Note that while the definition of BSResource::ID has the fields in Dir, File, Ext order, File is actually the first in the data. The second object is BSComponentDB2::DBFileIndex: BSComponentDB2::DBFileIndex { Map ComponentTypes List Objects List Components List Edges Bool Optimized } 'ComponentTypes' maps 16-bit component type IDs to string format class names. 'Objects' is a list of all material objects, in this format: BSComponentDB2::DBFileIndex::ObjectInfo { BSResource::ID PersistentID BSComponentDB2::ID DBID BSComponentDB2::ID Parent Bool HasData } PersistentID is similar to the keys used in HashMap above, and contains the same information for the externally visible layered material (.mat) objects. DBID is the internal 32-bit ID of the object (it cannot be 0), while Parent is used as the base object to construct this object from. HasData is true for all except 6 "root" objects from which all others are derived, and only for those, the Parent is 0. These 6 objects are for the 6 material object types, denoted by the base names "layeredmaterials", "blenders", "layers", "materials", "texturesets" and "uvstreams". 'Components' links material components to material objects: BSComponentDB2::DBFileIndex::ComponentInfo { BSComponentDB2::ID ObjectID UInt16 Index UInt16 Type } ObjectID is one of the DBID values from the object list, Index is a component slot for component types of which there can be more than one for a single object (e.g. a TextureSet object may have texture files associated with it at Index = 0 to 20), otherwise it is 0, and Type is one of the 16-bit component type IDs previously defined in ComponentTypes. Finally, 'Edges' describes how the material objects are organized in a tree structure: BSComponentDB2::DBFileIndex::EdgeInfo { BSComponentDB2::ID SourceID BSComponentDB2::ID TargetID UInt16 Index UInt16 Type } Index seems to be always 0, and Type is always the ID of BSComponentDB2::OuterEdge. This defines TargetID as logically the parent of SourceID. After BSMaterial::Internal::CompiledDB and BSComponentDB2::DBFileIndex, all material components are stored as OBJT and DIFF chunks, the total number and order of these is exactly the same as in 'Components' above. All components of derived objects are always stored after all components of their base object (the Parent in ObjectInfo), so they can be copy constructed using the data that has already been read.

For reference, here is a short description of the reflection data format. It consists of a set of chunks that begin with the chunk type (4 bytes, BETH, STRT, TYPE, CLAS, OBJT, DIFF, LIST, MAPC, USER or USRD) followed by the data size as a 32-bit integer, then the chunk data. The first three chunks are always BETH, STRT and TYPE, in this order: BETH: Header, the size is always 8 bytes, and the data consists of two 32-bit integers, a version number that is currently always 4, and the total number of chunks in the stream (this includes the BETH itself). STRT: String table, it is a set of C style NUL terminated strings concatenated to a single data block. In the rest of the stream, type and variable names are 32-bit signed integer offsets into the string table. There is also a set of pre-defined types that can be referenced with negative string table offsets (see below). TYPE: It contains a single 32-bit integer that is the number of CLAS chunks to follow. These are followed by class definitions (CLAS), the same number as specified in TYPE. The format of CLAS data is: Class name as string table offset. Class version/ID as a 32-bit integer, typically 0, 1 or 2. Flags as 16-bit integer, if bit 2 (0x0004) is set, then a USER or USRD chunk will be used to store the structure data. Bit 3 (0x0008) is set on certain structures, but its exact purpose is unknown. Other flag bits seem to be currently unused. Number of field definitions to follow (16-bit integer). The definition of a single field consists of the name and type (both as 32-bit string table offsets), then the data offset and size as 16-bit integers. The latter two refer to how the structure data is stored in memory in the game (with alignment etc. taken into account), and are not required for decoding. The class definitions are followed by the actual data. Each object is stored as an OBJT or DIFF chunk, which begin with the data type (as string table offset). The difference between OBJT and DIFF is that the former just contains all data fields as defined in the CLAS, while the latter uses a "differential" format that allows for encoding only a subset of the fields. In DIFF, each field is stored as a 16-bit signed field number (0 = first) followed by the data. A negative field number denotes the end of the structure. The differential format is not used within simple built-in types (like integers and floats) that are not structures, but it is inherited by sub-structures that are stored in separate LIST, MAPC, USER or USRD chunks. Regular structures can be nested within OBJT and DIFF, however, certain data types require additional chunks, which are stored separately after the parent object. These special types include: LIST: A list of objects, begins with the element type (string table offset) and the number of elements (32-bit integer), followed by the element data. MAPC: A map of objects, similar to LIST, but it contains key, value pairs, and it begins with the key and value types (two string table offsets) and the number of pairs. USER, USRD: Used for sub-structures with the "user" (0x0004) flag set, USER if the parent is OBJT, and USRD if it is DIFF. These allow for type conversions, and always begin with the class name (similarly to OBJT and DIFF) and end with an unknown 32-bit integer that seems to be always a small non-negative value, typically 0, 1 or 2. After the class name, the data is stored as type, value pairs. If the type is the same as the class name (no actual conversion is performed), then the encoding of the data is identical to OBJT and DIFF. Otherwise, a type, value pair is stored for each field of the structure, and the type seems to be always a built-in one (negative string table offset) based on the data I could test in the ESM and CDB. Note that in this case, there seems to be no difference between USER and USRD, and a value can be assigned even to an empty structure (0 fields). Finally, here is the table of built-in types: 0xFFFFFF01 (-255): Null, no data. 0xFFFFFF02 (-254): String, a 16-bit length value followed by the C style string data (including a terminating NUL character). 0xFFFFFF03 (-253): List, requires a separate LIST chunk. 0xFFFFFF04 (-252): Map, requires a separate MAPC chunk. 0xFFFFFF05 (-251): Pointer/reference to anything, stored as a pair of type and data (the type is a string table offset). 0xFFFFFF08 (-248): 8-bit signed integer. 0xFFFFFF09 (-247): 8-bit unsigned integer. 0xFFFFFF0A (-246): 16-bit signed integer. 0xFFFFFF0B (-245): 16-bit unsigned integer. 0xFFFFFF0C (-244): 32-bit signed integer. 0xFFFFFF0D (-243): 32-bit unsigned integer. 0xFFFFFF0E (-242): 64-bit signed integer. 0xFFFFFF0F (-241): 64-bit unsigned integer. 0xFFFFFF10 (-240): Boolean (0 or 1 as an 8-bit integer). 0xFFFFFF11 (-239): 32-bit float. 0xFFFFFF12 (-238): 64-bit float. The above is only a description of the general reflection data. However, the material database can be dumped in a human readable format with mat_info -dump_db, which could be of help understanding the structures it uses. The 32-bit hashes in resource IDs use CRC32, this sample code correctly calculates them (paths are expected to use lower case characters only, and backslashes as separators).

It is unrelated to other file formats with a ".cdb" extension, the format is actually the same as that of the REFL subrecords in Starfield.esm. These are used to serialize various data structures, and are not limited to materials. It is possible to dump the information using the mat_info tool from here, or with esmview or esmdump in the case of the ESM.

You can find a list of tens of thousands of material paths here: https://raw.githubusercontent.com/fo76utils/ce2utils/main/mat_names.txt The mat_info tool from here can also be used to print information about, or browse and view materials, although it cannot render multiple layers and some effects like translucency and parallax mapping.

It seems to be using these two materials (with the _n.dds and _s.dds textures under the same paths): materials/setdressing/boats/barge02.bgsm: textures/setdressing/boats/barge02_d.ddsmaterials/architecture/shacks/shackwoodplanks01.bgsm: textures/architecture/shacks/shackplanks01_d.dds

There is an updated (dev 10) version where saving is fixed: https://github.com/eckserah/nifskope_updated

There is no separate NIF, it is just the standard wood crate model with a material swap to setdressing/woodcrate/woodcrate_blueridge.bgsm.

If you only need to extract the textures for an existing asset, then check the material file used by the shader property of the BSTriShape, and use any BA2 tool to extract the DDS files. Unfortunately, NifSkope does not seem to show the contents of Fallout 76 material files, but most of the time, there is a BSShaderTextureSet block with an ID one higher than that of the shader property, and it contains the actual texture paths. Alternatively, it is possible to list the texture paths and extract files using my tools (fo76utils), although these are command line programs. nif_info prints information about NIF files, including the material and texture paths, and baunpack lists or extracts files from archives.

Having another look at the files, I think the problem could be that the Fallout 4 texture is in BC1_UNORM format, while the Fallout 76 one is in BC1_UNORM_SRGB (DXGI format codes 0x47 and 0x48, respectively). Fallout 76 shaders work in linear color space, which is what is physically correct, so the format code requests conversion from sRGB to linear on texture read (and the inverse is done when writing to the frame buffer), while the older game just uses the texture colors without conversion. With the Fallout 4 texture on a Fallout 76 mesh, NifSkope skips the first conversion but still does the second, making the image much brighter. So, changing the format code by saving the texture again as sRGB, or just editing the header, should fix the colors.

The alpha being 255 should be correct, something else may be causing the issue, or it could be specific to NifSkope. In the fo76utils NIF viewer, the model looks like this in the vanilla game vs. firstaidkitvandalized_d.dds swapped.

Fallout 76 introduced some changes to the texture system, and it implements lighting and PBR differently. I would at first try replacing only the _d.dds texture, and for the other three (n = normal, r = reflectance, l = lighting), keep the vanilla Fallout 76 files. Edit: for reference, these are the standard texture maps for Fallout 76 materials: _d.dds: Diffuse or albedo texture, typically in BC1_UNORM_SRGB or BC3_UNORM_SRGB format. Fallout 4 textures are not flagged as being in sRGB color space, which resulted in the gamma issue that can be seen on the above screenshots. Another notable difference is that in Fallout 76, this texture is black on pure metal surfaces._n.dds: Normal map in BC5_SNORM format (2 channels). Unlike in Fallout 4, the data type is signed 8-bit._l.dds: Lighting texture in BC1_UNORM or BC3_UNORM format, 3 or 4 channels:* R: smoothness map, low = rough, high = glossy* G: ambient occlusion map, applied to indirect lighting* B: subsurface scattering map, used optionally if enabled in the material file* A: grayscale emissive map (optional)_r.dds: Reflectance at normal incidence (table of reference values for common materials), usually in BC1_UNORM_SRGB (3 channels) or BC4_UNORM (grayscale) format. This is often just a 4x4 grayscale texture filled with a solid color of #0A0A0A, or about 4% reflected in linear color space.Optional texture maps include: grad.dds: Grayscale to palette map, it works similarly to Fallout 4. On shader materials, the U and V texture coordinates are calculated from the intensity of the original diffuse texture, and the product of the vertex color intensity and the grayscale to palette map scale parameter, respectively._g.dds: RGB emissive map._e.dds and _m.dds: Environment map and mask, unlike in Fallout 4, these are normally not used on shader materials (due to being unneeded with PBR and dynamic cube maps from Enlighten), but are sometimes used on effect materials like glass.The material (.bgsm and .bgem file) format version has been increased from 2 to 20. The differences between these can be seen in material.cpp in the source code of NifSkope.