The world of voxel models is characterized by a wide variety of formats, each revealing its own strengths and weaknesses. While formats like .vox or .qb have established themselves in certain niches, they quickly reach their limits when faced with more complex requirements – such as flexible layer management, extensibility or the integration of metadata. The goal of this project is to design a new, modular and open voxel format that not only meets current demands, but is also prepared for future requirements in terms of post-processing, modding and interoperability.

Analysis of Existing Formats

Format	Description	Strengths	Weaknesses
.vox	Proprietary MagicaVoxel format for voxel models	Widely used, supports colors and layers, many tools support it	Limited metadata, partly proprietary
.qb	Qubicle Binary Format, specifically for voxel models	Large models, layers, colors, export to many formats	Less common, partly proprietary
.obj	Polygon-based standard format, can store voxels as points	Very widely used, colors (with .mtl), many 3D tools	Not a native voxel format, no layer structure
.binvox	Binary voxel format, often for scientific purposes	Simple, open, supports large models	No colors, no layers
.gox	Goxel format, open and optimized for voxel models	Open, colors, layers, unlimited scene size	Less common, little standardization
netCDF	Multidimensional scientific data format, supports voxel layers	Open, large datasets, metadata, layers	Complex, mainly for scientific data

Historical Development and Status Quo

Voxel formats such as .vox and .qb have significantly shaped the creative scene, making it easy to store and share colored 3D structures. However, the technical foundation of these formats is typically tailored to a specific use case: they store voxels as simple colored blocks within a fixed grid, leaving little room for additional information like layer structures, material properties or complex metadata.

Typical Limitations

These limitations become especially apparent when models need to be systematically processed or modified. Layers are often hardcoded or not supported at all, color information is tied to a rigid palette and adding extra data such as animations, physical properties or user-defined attributes is difficult without bending the format. Proprietary specifications further complicate integration into open workflows and prevent modders and developers from implementing their own extensions.

Guiding Principles for a Modular Voxel Format

The modular voxel format (.mvox) is conceived as a response to these challenges. At its core is the idea of understanding voxel models not as rigid, self-contained data blocks, but as open, structured and extensible information spaces. Each model should be able to represent not only its geometric and color properties, but also its internal logic – such as layers, materials and metadata – in a clear and transparent way.

Modularity as a Fundamental Principle

Instead of compressing all information into a single block, the modular voxel format naturally relies on a modular structure. The core components – voxel grid, color table, layer structure, metadata – are clearly separated from one another and can be extended independently. This not only makes it easy to adapt to new requirements, but also allows for targeted development of individual aspects without having to redefine the entire format.

Openness and Future-Proofing

A central goal is the openness of the format: the specifications should be freely accessible and understandable, enabling developers and modders to create their own tools, plugins or extensions. At the same time, the format is designed with future expansions in mind – such as support for animation, physics or new attribute types – from the very beginning.

Basic Structure of the .mvox Format

Header

The header forms the foundation of every .mvox file. It contains essential information for identifying and interpreting the file: format identifier, version number, chunk size and optional details about voxel resolution. These details make it possible to clearly recognize the format and distinguish between different versions.

Voxel Grid

At the heart of the format lies the actual voxel grid. It is stored as a three-dimensional array, with each voxel carrying not only a color index but also a layer ID and, optionally, further attributes. The position of a voxel is implicitly determined by its location within the grid – a proven method that saves memory and simplifies processing.

Empty voxels are not stored explicitly. Instead, only occupied voxels are recorded – for example, using sparse arrays, hashmaps or a compressed list of occupied voxels with their coordinates. This reduces file size and speeds up processing, especially for large models that are mostly empty.

Color Table

Colors are managed in a separate palette, which can contain any number of entries. Each voxel references this palette by index. Optionally, a model can also reference external palettes, which is particularly interesting for modding and creating variants.

Layer Structure

Layers are a central structural element in the .mvox format. Every model has at least a base layer, which is always present and serves as the foundation for additional layers. Extra layers can be added optionally, each receiving a unique ID, a name and a type (e.g. bone, muscle, skin). Attributes such as visibility, opacity or user-defined properties are also supported and can be added as needed.

Metadata

Metadata gives each model context and identity: name, author, description and creation date form the foundation. Beyond that, any additional metadata can be attached at the model, layer or voxel level in the form of custom properties. These custom properties are designed as flexible key-value pairs, allowing to store individual attributes – such as physical values, game mechanics or specific notes – directly within the data model.

Extension Block

The extension block is a reserved section within the format, intended for future, structurally new or complex extensions. While custom properties specifically add individual attributes, the extension block provides space for entire data blocks – for example, for animations, complex physics data or plugin-specific structures. An example of this would be an “Animation-Chunk”, which stores motion data for different layers or the entire model in its own, clearly defined block. This way, the format remains open and adaptable in the long term, without affecting existing data structures.

Outlook and Next Steps

The .mvox format is designed as a living, open system. The next development steps include the detailed elaboration of the specification, the implementation of a reference library, as well as the creation of sample models and test data. Special attention is given to documentation and the active involvement of the community, in order to continuously develop the format and adapt it to the needs of users.

The vision: A voxel format that not only meets today’s requirements, but is also ready for the future – modular, open, extensible and prepared for creative post-processing.