This project has moved and is read-only. For the latest updates, please go here.
The SDKMesh format is a sample runtime format that was created for Direct3D 10 as a replacement for the legacy X File format for use in the DirectX SDK samples.

SDKMESH is supported as a runtime format by DXUT's CDXUTSDKMesh loader class and DirectXTK's Model class.

DirectX Tool Kit

DXUT for Direct3D 11

Samples Content Exporter


To aid in debugging, here is a simple console program for dumping out the content of a SDKMESH/SDKMESH_ANIM file in a human-readable form.

File Format Details

Disclaimer: The DXUT Mesh format (.sdkmesh) is not a recommended file format for shipping titles. It was designed to meet the specific needs of the SDK samples. Any real-world application should avoid this file format in favor of a destination format that meets the specific needs of the application.

The SDK mesh format used in the samples is a binary format created for the sole purpose of providing an easy way to get mesh data into the SDK sample and tutorial applications. Because of this, it is a very simple format that will not meet the needs of most game developers.

The file consists of multiple fixed sized structures that contain offsets to any variable sized data that may be associated with the structure. For example, the main file header contains a count for the number of materials stored in the file as well as an offset from the beginning of the file to the first material.

File Layout

The mesh file format is laid out as follows:


The SDK mesh format contains two main sections of data: Static Data, Buffer Data.

Static Data

The static data is first in the file. This contains the overall file header as well as vertex buffer, index buffer, mesh, subset, frame, and material information. The mesh class loads all of this into memory as one giant chunk of data an sets some internal pointers to various parts of the data in order to reduce load times. Note, that this technically may load more information into memory than is absolutely necessary. Real-world applications should ensure their file format meets their needs perfectly in order to avoid loading unnecessary information into memory.

For the SDK samples, it was best to lay out the data in the following order.
  • Main file header
  • A Vertex Buffer description structure for each VB
    • This structure contains an offset to the actual vertex data
    • Vertex buffers can be shared between meshes
  • An Index Buffer description structure for each IB
    • This structure contains an offset to the actual index data
    • Index buffers can be shared between meshes
  • A Mesh structure for each mesh in the file
    • This structure contains a list of vertex buffers references and one index buffer references
    • This structure contains an offset to a subset index list
    • This structure contains an offset to a frame/bone influence list
  • A Subset structure for each subset in the file
    • Subsets can be shared between meshes in this format
  • A hierarchical list of Frames
  • A list of Materials
  • Subset index data: pointed to by the Mesh structures
  • Influence index data: pointed to by the Mesh structures

Buffer Data

The remaining information in the file is the vertex and index data. In the mesh class in DXUt, this buffer data is loaded into memory and consumed by the vertex and index buffer creation calls before being discarded.

Supplemental Animation File Format

In addition to the SDK mesh format, some samples will also use a supplemental animation file format to load animation data. The layout of this format is simply a header followed by a list of frame references that should match up with the frames in the mesh file. Each frame reference contains an offset to a list of keyframes. For the purposes of the samples, all frame references have the same number of keyframes.


Last edited May 1, 2015 at 10:21 PM by walbourn, version 11