[size=150]XMesh Loader Features Overview[/size]
*The XMesh Loader displays an Icon at the Pivot Point. The Icon will disappear if any modifiers are added to the stack. Like with Frost, only procedural modifiers make sense due to the potentially changing topology. For example, you can change the Material ID of faces from 2 to 5 by adding a Volume Select in Face mode, select by Material ID 2 and add a Material Modifier with ID 5 on top of the stack. OTOH, adding an Edit Mesh is a bad idea because it would try to snapshot the incoming geometry, but that geometry can change from frame to frame.
*The “Mesh Scale” option lets you scale the incoming mesh without applying object-level transforms. This means that the mesh will be scaled at base level and pass as scaled through any modifiers on the stack, while object-level transforms are applied after the modifiers. This is useful when loading geometry saved at different units (e.g source in inches, current scene in cm).
*The “Keep Mesh In Memory” option keeps the current frame’s geometry in memory, so the XMesh Loader wouldn’t reread the data from disk when updated. If unchecked, the file will be read each time an update happens (which can be useful if the files are being constantly updated from another copy of 3ds Max, for example).
*The “Velocity To Map Channel” option lets you copy the velocity info into a mapping channel. This can be useful when converting an XMesh to a PRT Volume, for example - the particles will sample the mapping channels and a KCM could be used to assign the mapping to Velocity again, thus transferring the velocity from the mesh to the particles (same as with Frost).
*The XMesh Loader supports two file sequences - a Render Sequence and a Proxy Sequence. The Proxy sequence is optional and could be employed to display a lower-res. version of the geometry in the viewports. You have to produce the proxy sequence yourself using the XMesh Saver toolset. There are also controls at the bottom of the UI to determine which sequence should be used for rendering and which should be used for viewports. When there is no Proxy sequence specified, the Render Sequence will be used for both viewports and rendering.
*The “Timing” controls are identical to those in the Krakatoa PRT Loader and Frost - you can load the specific file name without changing the time, limit the loading range (YOU SHOULD limit the frame range to the valid interval saved to disk to avoid render frame failures - in fact, the XMesh Loader will set it automatically when you pick a sequence), offset and retime the animation using a Playback Graph.
*The “Loading Mode” options control the behavior when sub-frames are requested by the renderer to produce Motion Blur.
**“Frame Velocity Offset” uses the nearest full frame and the corresponding Velocity channel (if generated during the Saving process). The Vertices will be moved along the velocity vector. The result is linear interpolation between a full frame and half a frame later due to the linear nature of the velocity data.
**“Subframe Velocity Offset” uses the nearest sub-frame file and its Velocity channel (if available). If you have saved sub-frames by setting the Step value in the Saver to a value less than 1.0, the XMesh Loader will take full advantage of the sub-frame data. Switching back to “Frame Velocity Offset” will effectively ignore the sub-frame data on disk. Using sub-frames will allow you to produce more curved vertex motion between two frames thanks to the additional samples stored in the sub-frame files. The higher the number of sub-frames, the closer the vertex interpolation will be to the original motion, at cost of disk space. If only the vertices are changing position (all other channels like Face list, Material IDs, Smoothing, Texture/Mapping Coords etc. are the same), a sub-frame will contain just the Vertex list and Velocity channels, with all other channels reused from a previous frame. Thus, using multiple sub-frames does not necessarily cost too much disk space and is more similar to Point Caching.
A surprising comparison to 3ds Max Point Cache:
*Create a Teapot with 64 segments.
*Set the Scene Segment to 10 frames.
*Add a Bend modifier, animate to 90 degrees over 10 frames.
*Add a Point Cache modifier and cache to PC2 format - the resulting file is 16.9 MB and contains ONLY VERTICES - the actual geometry is still in Max.
*Now use the Save Meshes script to save the same object to XMesh over 10 frames - the resulting files contain the whole geometry including faces, texture coordinates, smoothing groups, material IDs and velocities plus the vertex data and occupy 22.6 MB.
*Now disable the saving of the Velocity and save again to a different folder - the resulting data is 15.1 MB! In other words, XMesh saving the complete geometry and the vertex data per frame uses less disk space that the PC2 cache which stores just vertices! You can enable the Frame Interpolation mode to produce sub-frames on the fly in the XMesh Loader just like the Point Cache modifier does.
*Note that attempting to save to the XML Point Cache format will most probably lead to crash (at least in Max 2010) - it is broken when the vertex count is higher than 64K or something ridiculous like that…
**“Frame Interpolation” uses the two surrounding full frames and, given consistent topology, produces the sub-frame vertex positions on the fly without the use of the pre-saved Velocity channel. If the two frames have mismatching topologies, no sub-frame data will be generated and the closest full frame will be used.
**“Subframe Interpolation” uses the two surrounding sub-frames, otherwise the same as the previous mode. If no sub-frames were generated at saving time, it behaves identically to “Frame Interpolation”. Switching to “Frame Interpolation” effectively ignores any sub-frame files on disk.
[size=150]Advanced Info for TDs and TAs:[/size]
*The XMesh Loader is CURRENTLY a hybrid C++ Base Plugin with a MAXScript Plugin Extension (exactly the same system as used by the PRT Loader in Krakatoa). We plan to replace it with a single C++ plugin like we did with Frost (which was originally a hybrid plugin, too).
*Thus, in order to create an XMesh Loader and set its path to an existing XMesh file sequence, you MUST specify the path in two places right now - in the UI and in the .delegate base plugin.
For example,
theXM = XMeshLoader()
theXM.renderSequenceName = theXM.delegate.RenderSequence = @"c:\temp\xmeshtest_0000.xmesh"