RSS< Twitter< etc

<< Back To XMesh Index

XMesh Saver MX Output Files


XMesh was designed to store the geometry data using multiple files per frame.

This provides several benefits over a single file solution: 

  • If a channel is not changing over time, later frames can easily reuse the previously saved sample by simply pointing at that file. 
  • It enables the parallel processing of a single sequence on multiple network nodes
  • It allows the resaving of sub-ranges or even individual frames to fix errors or replace missing files without resaving the complete sequence.
  • It enables XMesh to easily mix human-readable text files and compact compressed binary files within the same system. 

Below is a description of the various files and how XMesh Saver and Loader use them.

The XMesh File 

Each geometry sample (typically one per frame, but sub-frame samples are also supported) has an .XMESH header file which defines the channels and data files used by the mesh at that time.

The .XMESH file is a human-readable ASCII XML file:


<?xml version="1.0" ?>
        <minimum>[-86.8285, -92.2029, 2.24088]</minimum>
        <maximum>[106.156, 98.5331, 210.439]</maximum>
        <value>12/01/2012 1:43:21 PM</value>

When the topology of the mesh is consistent over multiple frames, any related channels will be taken from the first frame of the validity range. For example, a moving or bent sphere primitive will only save unique vertex lists on each sample, but reuse the first frame's face list and all other face-related channels.

The XMDAT binary files

Each mesh channel saved by the XMesh Saver is stored in a separate .XMDAT binary file per sample. 

The file name is based on the XMESH base file name plus underscore and the name of the channel, for example "XMesh_MultiWS1__verts0060.xmdat"

The .XMDAT file is deflated using ZLib compression.

Here is some of the typical channels saved:


This file contains the vertex positions of the mesh on frame 60. 


This file contains the face definitions of the mesh on frame 60. 


This file contains the mapping channel 0 vertex values on frame 60. This channel is called "VertexColor" in 3ds Max and "Color" in Krakatoa.


This file contains the mapping channel 0 face definitions of the mesh on frame 60. 


This file contains the mapping channel 1 vertex values on frame 60. The channel is called "TextureCoord" in 3ds Max and in all Thibkbox products like Krakatoa.


This file contains the mapping channel 0 face definitions of the mesh on frame 60. 


 This file contains the per-vertex velocity vectors on frame 60.


 This file contains the 3ds Max per-face Smoothing Groups (32 bit ints) on frame 60.


 This file contains the 3ds Max per-face Material IDs on frame 60. These values describe the material assignments, pointing into the sub-materials of a 3ds Max Multi-Sub Material.

The MAT Library File

When XMesh Saver MX saves geometry to disk, it also produces a Multi-Sub Material corresponding to the geometries being cached. This is especially important when combining multiple geometry objects into a single cache, since each object might have its own unique material using the same per-face Material ID. XMesh Saver MX will combine all Materials and Multi-Sub Materials used by all objects to be saved and will stack them to produce unique Material IDs for each, then increment the face Material IDs to match. 

Thinking Particles uses its own TPMultiMaterial class which is a multi-level hierarchical material (think Multi-Sub Materials nested inside Multi-Sub Materials at any depth). XMesh Saver MX will expand the TP MultiMaterial into a standard 3ds Max Multi-Sub Material while preserving the mapping to the geometry faces of the particles, thus making the XMesh Loader MX independent from a Thinkinb Particles installation - the saved XMesh sequence should be playable in 3ds Max even if TP is not installed there and the TPMultiMaterial is not available. Note that it is technically possible to assign the TPMultiMaterial from the original TP system to the XMesh Loader via MAXScript or manually if this is desired, but the XMesh Saver MX automation does not do that.

Objects that have no material assigned can be handled in various ways - see the Advanced Settings rollout for the available options. Usually, a stand-in material will be assigned to the object before saving to give the geometry a valid representation when loaded back.

Once the single material to be assigned to the XMesh Loader MX has been created, it is saved into a 3ds Max Material Library .MAT file in the same folder as the XMesh file sequence and using the same base name minus the frame counter.

The library will always contain a single top-level Multi-Sub Material which can be assigned automatically via MAXScript or manually by loading the library from disk and assigning to the XMesh Loader. When an XMesh Loader is created by the XMesh Saver after saving, the material stored in the library is assigned to the XMesh Loader directly, but the Material Library is still created for backup and future reference.

The MatIDMap File

In addition to the 3ds Max Material Library, an INI file with the same name as the XMesh sequence minus the frame counter and with extension .MatIDMap will be saved in the output folder.

This file maps the material names to the Material IDs. This is useful for the future XMesh Loaders for other 3D Applications like Autodesk Maya and Autodesk Softimage which use named material groups instead of indices.

An example of such a file's content would be 


The CREATE_*.MS Script File

Another useful file created by the XMesh Saver MX script is the CREATE_*.MS file where * stands for the sequence's base name, e.g. "CREATE_XMesh_MultiWS1_.MS".

This script file contains instructions to 3ds Max how to create an XMesh Loader MX object using the saved sequence, material and other settings. The script can be executed by simply dragging it over the 3ds Max Viewports, or by running it via 3ds Max Main Menu > MAXScript > Run Script.

Here is an example script created while saving individual objects to XMesh sequences, in this case a  Teapot in Object space:

local theXMeshLoader = XMeshLoader()
local theXMeshLayer = LayerManager.getLayerFromName  "XMesh Loaders" 
if theXMeshLayer == undefined do theXMeshLayer = LayerManager.newLayerFromName "XMesh Loaders" 
theXMeshLayer.addnode theXMeshLoader 
theXMeshLoader.viewportSequenceID = 0 = uniquename "XMesh_SingleOS_Teapot001_" 
at time 0 theXMeshLoader.transform = (matrix3 [1,0,0] [0,1,0] [0,0,1] [-55.4235,2.03241,0]) 
theXMeshLoader.wirecolor = (color 6 135 113) 
theXMeshLoader.enableViewportMesh = true 
theXMeshLoader.displayMode = 0 
theXMeshLoader.displayPercent = 5.0 
theXMeshLoader.limitToRange = true 
select theXMeshLoader 
theXMeshLoader.rangeFirstFrame = 0 
theXMeshLoader.rangeLastFrame = 100 
theXMeshLoader.viewportSequenceID = 0 
theXMeshLoader.proxySequence = "" 
theXMeshLoader.renderSequence = @"C:\Temp\xmeshes\Untitled\Borislav\v0049\Teapot001\XMesh_SingleOS_Teapot001_0000.xmesh" 

Note that evaluating the script multiple times will create new XMesh Loaders with unique names (001, 002 etc.), while running the XMesh Saver MX multiple times will UPDATE the existing XMesh Loader after each saving operation if its name is found in the scene.

Check out the following video tutorial to see the creation script in action.