[size=150]Here is some more info on the XMesh Saver.[/size]
*It is a script. The XMeshSaver exposes an Interface whose functions can be used to develop CUSTOM savers. The provided UI is something that has been used internally by Frantic Films / Prime Focus, but as you can see from the bottom rollout, it has not been updated in a while (it lists Deadline 3.x which is a couple of years old). This script will be updated during the Beta, but you are free to write your own if you wish/can.
*The objects list shows the objects that were selected when the UI was open, but only the objects that are highlighted on the list will be saved. This means that you can select 10 objects when opening the UI, but then save one XMesh with 5 of them and then each one of the other 5 to its own XMesh without restarting the UI by just changing the highlights on the list.
*It supports three different saving modes:
**Save ALL Objects to ONE MESH In WORLD SPACE Coordinates - this option takes all highlighted objects on the list and combines them into a single geometry cache, storing the vertex data in object space. When loading, you have to put the XMesh Loader at the world origin [0,0,0] and the geometry will align correctly to the original.
**Save EACH Object to INDIVIDUAL MESH In WORLD SPACE Coordinates - this option saves each highlighted object to a separate XMesh file sequence (the name of the object will be appended to the specified output file name). If the “Save Each Object To An Individual Sub-Folder” checkbox is checked, each sequence will go into a sub-folder named after the object being saved. When loading each XMesh cache, each XMesh Loader must be placed at the World Origin to align to the source.
**Save EACH Object To INDIVIDUAL MESH In OBJECT SPACE Coordinates - this option is similar to the previous one, but the vertex list will be stored in object space, not in world space. As result, loading an XMesh will require the XMesh Loader to be placed exactly where the original object was. The toolset does not provide means to store / restore this data, it is up to the user to align the XMeshes in world space to place the caches as needed. (Some in-house tools existed that would deal with this, there might be added later to the toolset).
*Save Velocity option - when checked, the XMesh will generate a Velocity channel. This will allow the XMesh Loader to interpolate geometry on sub-frames according to the vertex velocities to produce motion blur, but it can be slower to generate. By default, the XMesh Saver will try to evaluate the geometry on the full frame and at a sub-frame and if the topology is the same, it will extract the velocities based on these two snapshots. But if the sub-frame sample has a different topology, the XMesh Saver will attempt to move closer to the full frame and attempt again. This will continue until a valid matching topology is found OR the velocity generation fails due to changing topology in the very vicinity of the full frame (zero velocities will be saved in that case). Thus, saving changing topology with the “Save Velocity” option on can become very slow - if you know that your geometry is changing topology on most frames, you might want to disable this option.
An exception to the rule is the saving of Thinking Particles geometry where the velocities of the particles will be used to generate the mesh velocities which is very fast.
When saving Frost geometry with the XMesh Saver, be sure to use the “Frame Velocity Offset” option in the Frost > Meshing > Motion Blur Mode controls to ensure consistent topology on sub-frames!
*Ignore Empty Meshes - when checked, objects that have no geometry (zero vertices and faces) will be skipped. When unchecked, empty objects will produce an error and no data will be saved.
*Ignore Topology Changes - when checked, objects with changing topology will be saved. When unchecked, changing topology will produce an error and no data will be saved.
*Save Frame Range - when opening the dialog, the From and To values will be set to the current scene range. You can change them as needed. The Step value is set to 1.0 by default (this is the max. possible value). A Step value of 1.0 produces one file per frame. A Step of 0.5 will produce files on full frames and half sub-frames, with the file name using a comma delimiter for the sub-frame info, e.g _0001,5.xmesh. Sub-frame sampling is useful when caching fast-moving or fast rotating geometry. For example, to capture the rotation of particles and interpolate better motion blur from the rotation, using a Step of 0.5 or 0.25 would be good idea.
The “Get Current Range” will reset the controls to the scene range. The “Get Current Frame” button will set both From and To to the current slider time, useful for caching a single frame.
[size=150]Some info on the data being saved:[/size]
*The XMesh file is a simple XML file which describes the current frame and the data channels to be loaded. It contains references to other files with .XMDAT extension saved by the XMesh Saver which contain the actual data in zipped binary streams, including Vertex and Face lists, Material IDs, Velocities, Texture Coordinates etc. This means that just like with the PRT or OpenEXR file formats, the data occupies the least disk space possible. For example, a default Teapot with 1024 faces and two mapping channels saved to XMesh occupies 18,874 bytes on disk, zipping all its files produces an archive with a size of 18,193 bytes (due to the .XMesh XML file being uncompressed). In other words, it hardly compresses any further.
The XMesh file can use references to previous frames if a channel has not changed over time. For example, if the topology is not changing relatively to frame 0 (the object is not moving or deforming), most data channels will be saved on frame 0 and recycled on the following frames until a change is detected and a new set of data files are saved out. This ensures once again the smallest possible file size of disk. Using the above static Teapot example, saving frames 0 to 100 produces only data for frame 0 plus 101 XMesh files referencing the same data for a total of 166,868 bytes (1011,479 bytes per XMesh file + the data files).
*The XMesh Saver is a KIND OF RENDERER. In other words, it will evaluate the geometry using the same calls as the Scanline Renderer, mental ray or VRay would, and save to disk exactly the same data these renderers would normally get from 3ds Max. You should always THINK of the XMesh Saver as of a renderer to avoid surprises. For example, caching a geometry object that has a Displacement Map in its Material can kill performance because Max will evaluate the geometry for displacement and might save distorted vertices even if displacement is disabled in the actual production renderer!
*The XMesh Saver will save every channel found in the render-time TriMesh, but only if it is allocated AND USED. So for example if you add an UVW Map modifier to a Teapot, set the Modifier to Channel 10 and save as XMesh, the channels TextureCoord and Mapping10 will be saved, but the mapping channels 2 to 9 which are allocated by Max according to the Channel Info Utility but are NOT used will NOT be saved.
[size=150]Dealing With Materials[/size]
*The XMesh Saver will save the Material IDs of the original object(s) to disk, but it does not save the actual material(s) assigned to the original objects. It is up to you do reassign materials and make sure the right Material IDs are assigned.
For example, if a Box and a Sphere are assigned the same Multi-Material with 6 sub-materials, saving a single XMesh out of the two and then loading with an XMesh Loader and assigning the same Multi-Material will produce the correct results. But if the Sphere had a separate Standard Material assigned to it, its Material IDs will be still the same and the resulting XMesh will show the sub-material from the Box on the Sphere instead. To solve this, adding a Material Modifier to the Sphere to increase its MatID to 7 and then putting the Sphere’s material into the Box’ Mutli-Material as MatID 7 would produce the right result.
*When caching Thinking Particles, a special TP Multi-Material is being created and can be accessed from the TP object. This is a hierarchical Multi-Material that can contain other Multi-Material. It turns out that assigning that same material to an XMesh Loader of the TP cached geometry will produce perfectly correct material assignments in the XMesh geometry, making XMesh a great tool to pass massive TP simulations to Lighting and Rendering department without passing the actual TP setup.
*If you have a bunch of objects with unique materials (esp. Multi-Materials), saving each object to a separate XMesh sequence and reassigning the original materials to the respective XMesh Loaders might be the easiest solution.
*Plan For The Future: Use the existing Frost feature for building a single Multi-Material out of the materials of all objects selected for saving, then save that Material to a MAT library and shift the Material IDs in the XMesh to match. Provide a script that creates an XMesh Loader from a given sequence AND re-applies the material from the library to it automatically.
[/:m]
[/:m]