The VIM format is a modern and efficient open 3D data interchange format designed for BIM and manufacturing data optimized for efficient loading and rendering on low-power devices.

Characteristics of the VIM format:

Unlike other 3D data formats, VIM is designed to carry substantial amounts of complex relational data and instanced geometry in an efficient and standardized manner with minimal pre-processing.

A sample validating VIM reader can be found at: https://github.com/vimaec/vim/blob/master/VIMReference/Program.cs.

This is the specification for version 1.0.0 of the VIM data format. It is divided up into the following parts:

At the top level, a VIM document conforms to the BFAST (Binary Format for Array Serialization and Transmission) binary data format. A BFAST is conceptually similar to a ZIP or TAR archive without compression, just an array of named data buffers. Physically it is laid out as a header, an array of range structures (each containing offsets to the beginning and end of a buffer), and then the data section. The following structures assume 64-bit or more minor alignment.

The first structure in the VIM file (or any BFAST) is a 32-byte header.

At byte number 64 starts an array of N range struct (where N = NumArrays in the Header). Each range struct specifies where the data begins and ends for a particular buffer as an offset from the beginning of the file.

The data section starts at the first 64-byte aligned address immediately following the last Range value.

The range structs are expected to satisfy the following criteria:

The first data buffer in a VIM file contains the names of the others buffers as NUL character delimited UTF-8 encoded strings. The number of strings should always equal the number of data buffers specified in the header minus one.

There are five expected top-level buffers in the VIM file with the following names. Their order is not essential, and only the header is optional. Additional buffers are allowed for custom purposes but will not be parsed by most readers.

The header section contains the VIM file version and additional metadata as a sequence of newline (\n) terminated sets of key/value pairs denoted by <key>=<value>.

The following is an example:

The field names are case insensitive. The only required field is vim which must have the value in the format <major>.<minor>.<patch> representing the file format version. The id field should be a uniquely generated GUID created the first time a VIM is created but is not changed when the file is modified or saved.
The revision field if present should be a new GUID created anytime a VIM is modified or updated. The created field should contain a date in ISO_8601 format. The generator field contains the program's name used to generate or edit the VIM. The schema field contains the version of the object model schema.

The assets section of a BIM is also a BFAST container. It may contain any number of buffers with any names. Buffers prefixed with the name textures\ are assumed to be texture files. By convention, buffers prefixed with the name renders\ contain image files.

The geometry section of a VIM contains the merged geometry and basic scene graph information for an entire VIM document using the G3D format.

The G3D format is a binary format for 3D geometry that encodes data in an array of attribute buffers. G3D is based on the BFAST binary layout and uses a naming convention to identify the layout of each attribute buffer and how it is used.

Each attribute buffer is associated with a component of a geometry:

G3D attributes have names to identify them (e.g., position or UV) and use indices to distinguish when multiple attributes share the same name (e.g., uv:0 ... uv:8). They can be of one of the following core data datatypes: float32, float64, int8, int16, int32, int64.

More information on G3D is available on its Github repo at https://github.com/vimaec/g3d.

The geometry in a VIM contains the following attributes:

Additional attributes are possible but are ignored and may or may not be written out by any tool that inputs and outputs VIM files.

Conceptually, the geometric objects in a VIM file are related in the following manner:

Columns and tables in the entity buffer should never be assumed to be present by an application consuming a VIM.

The entities section of a VIM contains a collection of entity tables. An entity table is a combination of a relational table alongside a collection of key-value pairs about a particular data entity. Examples of data entities include geometry, nodes, materials, cameras, assets, and various BIM elements such as Elements or Products.

Each relational table consists of three types of columns:

For more information on what the expected entities are and what columns they are expected to contain in this version of VIM, see the VIM Data Model Section of the documentation.

The entities section is encoded as a BFAST, with each buffer containing an entity table. Each entity table is also encoded as a BFAST, with each column as a named buffer and a collection of key/value pairs encoded in its column.

The strings buffer contains a sequence of strings of zero or more length, with no duplicates, delimited by the "NUL" character. There may or may not be a trailing "NUL" character. The zero-based index of each string is used by the string columns of entity tables.

The VIM format version uses the Semantic Versioning scheme: MAJOR.MINOR.PATCH.

Similarly, the object model has its semantic versioning scheme.

The object model refers to the schema of entity tables. This constitutes the name of each table, the name and type of each column in each table, and the relationship between tables (as specified by index columns).

The VIM file format is independent of the object model.

The current object model is documented here as a C# file: https://github.com/vimaec/vim/blob/master/object-model-schema.cs.

The C# file describes the table as a set of objects. Compound types, for example, say a field named Location of type Vector3, is represented as multiple columns in the table (e.g. Location.X, Location.Y, and Location.Z).

The VIM C# API allows users to efficiently access data as tables and columns (represented in memory and on disk) or, more conveniently, as dynamically created objects as expressed in the C# object model file.

The VIM format allows for additional geometry attribute buffers beyond the minimum required. Tools should be able to read and write additional buffers, even if there is no deeper understanding of the buffer.

Software loading VIM files should be robust in the absence of tables and columns, never assuming any table or column is present.

Additional tables and columns can be added as desired, and all software supporting VIM files should be able to read and write that data without loss.