bMesh - themeldingwars/Documentation GitHub Wiki

bMesh files, which I assume stands for Binary Mesh are used for the majority of the meshes in Firefall, with R5A files holding some UI meshes and the terrain geo being in another.

The .oMesh extension refers to the same format. It is what shows up in pfx <Model> references and in the bMesh refMeshFileName field.

• bmesh.bt

• Reader and Writer have been implemented in FauFau: BMesh.cs / BMesh32.cs

• bMesh-Noesis-plugin

Version 32 is what the later builds ship and is the version documented below. Anything older is out of date and the engine will attempt to update it on load.

Older versions are not documented. An earlier, partly guessed description of a pre-32 layout used to live on this page. It did not match version 32 and has been removed because it was misleading, but the version 32 layout below is still the best starting point for an older file since the order of the sections has been fairly stable.

The whole file is little endian. Every array is preceded by an int32 count, and the sections always appear in the order below. There are no offsets or chunk markers anywhere in the file, so the only way to reach a later section is to walk every preceding one.

Each row is an int32 count followed by that many elements, in this order:

Then the reference mesh block, which is not an array:

And then three more counted arrays:

Two uint32 values per entry. The two known readers disagree on what they mean:

• FauFau reads them as startWeight and weightCount, where the count is 1 to 4. That makes the array a per-vertex range into boneWeights, which matches how the four influence slots of a skinned vertex are normally stored.
• The 010 template reads them as weightIndex and vertexIndex.

Both readings consume the same bytes, so either one parses the file. Treat the meaning as unconfirmed until it has been checked against a skinned mesh with known weights.

Normals and tangents are not compressed, they are quantised. Each component is one unsigned byte covering the range -1.0 to 1.0:

float Decode(byte b)  => b * (2.0f / 255.0f) - 1.0f;
byte  Encode(float f) => (byte)(((255 * (Clamp(f, -1, 1) + 1)) / 2) + 0.5f);

The fourth byte differs between the two:

• For a normal it is unused padding.
• For a tangent it is a flag. 255 means the bitangent is reversed/mirrored, 0 means it is not.

A "base variant" is for instance a head type: there is a base head and several variants of it. baseVariantDiffs encodes the positional difference from this mesh to that base head, as a uint16 face index followed by two half floats holding barycentric weights.

Conform meshes are meshes such as hair or beards. conformWeights holds three pairs of uint16 geometry index plus half float weight, and is what lets a hair or beard mesh be reshaped to fit any head.

refMeshFileName points at the mesh this one is a variant of or conforms to, and meshType says which of the two roles this file plays.