FleetFeet/Volumental BMF file format
Written by Paul Bourke
December 2020
The following defines the BMF format as used to represent foot scans by either, or both,
FleetFeet and Volumental. The format is, as far as the author is aware, not made available
publicly and what follows is a determination of the format using standard investigative methods.
The files are required to define a 3D mesh which typically includes a list of the vertices and
triangular faces. The faces are defined, in efficient formats, in reference to the vertices.
This is exactly what the BMF format does, and it also defines a normal at each face vertex.
The high level layout of the file is as follows:
- Header
- The number of vertices followed by a list of vertices
- The number of faces followed by a list of faces
- The number of normals followed by a list of the normals
- Footer
While not explicitly defined in the format, the units for the vertices are meters.
More detail of the file format is shown in the figure below.
Notes
The x,y,z components of the vertices and normals
are 4 byte floating point values.
The face vertex indices are 2 byte short ints,
mostly likely unsigned.
Each data group (vertices, faces, normal) is
surrounded by a start and end identifier. For example,
SoV = Start of Vertices, SoF = Start of Faces, SoN = Start of Normals.
The exact purpose of the SoG which is imagined
to be Start of Group is unknown. It possibly allows for the identification
of a different groups of faces within a single file. This is only a
theory until a file is produced that has multiple face collections
within the same file.
The various instances of 2 byte short int
values that are always 0 would only seem to serve to realign the
file structure to 4 byte boundaries.
The vertex indices defining the faces should
only require 2 byte short ints but instead use a pair of 2 byte
short ints. In all the files tested so far this second superfluous
short int is always zero so it is also possible just a filler to
realign to 4 byte boundaries.
More usual for these types of 3D mesh
descriptions would be to define a normal for each vertex, rather
than for each vertex of a face. That is, shared vertices of a
face would normally share the same normal. So the method used
here is somewhat inefficient. It is postulated that there
will always be 3 times the number of normals as faces, since each
face is a triangle.
Sample file decomposed into sections, is shown below.
Magic number header: "BMF0"
22064 ("V" "0" = 86 48)
21359 ("S" "o" = 83 111) Start of vertices
2550
0
Read 2550 vertices
22064 ("V" "0" = 86 48)
17775 ("E" "o" = 69 111) End of vertices
18224 ("G" "0" = 71 48)
21359 ("S" "o" = 83 111) Start of group
17968 ("F" "0" = 70 48)
21359 ("S" "o" = 83 111) Start of faces
5096
Read 5096 faces
0
17968 ("F" "0" = 70 48)
17775 ("E" "o" = 69 111) End of faces?
20016 ("N" "0" = 78 48)
21359 ("S" "o" = 83 111) Start of Normals
15288
0
Read 15288 vertices
20016 ("N" "0" = 78 48)
17775 ("E" "o" = 69 111) End of Normals
18224 ("G" "0" = 71 48)
17775 ("E" "o" = 69 111) End of group
Magic number EOF: "FMB0"
|