Here is a list of some known factors that can affect the performance of the XMesh Saver:
*By default, the option in the Save Meshes dialog to Save Velocity is checked. This is because we assume you want to do motion blur most of the time. But, if the topology of your mesh is changing somewhere within the sampling interval (typically 1 frame long), there will be no way to determine a correct velocity. The XMesh Saver will attempt to evaluate the geometry at shorter and shorter intervals from the base sample in hopes to find a small sub-interval where the topology is not changing. This can cause multiple evaluations of the geometry and slow down the processing several times.
SOLUTIONS:
-If you know your topology is not consistent between frames (in other words, if Point Cache wouldn’t even work with it and VRay would refuse to motion blur it in the first place), you should disable the Save Velocity option.
-If the topology is not changing but you want to speed up the saving at cost of loading, you can save without Velocity channel and create the velocity data on the fly in the XMesh Loader using the “Frame Interpolation” or “Subframe Interpolation” options. The benefit of this approach is questionable though, since the saving happens just once but the loading multiple times.
*As mentioned already elsewhere, the XMesh Saver is a special kind of a Renderer in that it calls the same GetRenderMesh functions the Scanline Renderer would call before rendering the scene. This implies that render-time processing like Displacement Mapping (Texture Map placed in a Displacement slot of a Material) will cause a huge hit during the evaluation, and will also affect the vertex positions being saved to XMesh. The hit can be significant (orders of magnitude slower!)
SOLUTION: It is very important to disable or remove any Displacement maps from the objects to be saved. (in the future, we might attempt to solve this internally, but in the current build you have to deal with this yourself).
Having both these situations in the same scene could cause a mesh that would normally save in one second to take several minutes.
Here are some base numbers:
*Teapot, 16 segments (16,384 faces), animated Bend modifier, Displacement Texture Map in Standard Material, saved from frame 0 to 30:
**Bend Off, Velocity Off, Displacement Map Off: 0.219 seconds
**Bend On, Velocity Off, Displacement Map Off: 0.562 seconds
**Bend On, Velocity On, Displacement Map Off: 2.016 seconds
**Bend On, Velocity Off, Displacement Map On: 28.968 seconds
**Bend On, Velocity On, Displacement Map On: 58.828 seconds
*When saving Thinking Particles, the Velocity channel is read directly from the particle system and the above issue with multiple evaluations does not occur. But since Thinking Particles is history-dependent, sending a live TP system for saving to Deadline for example would cause each render node to pre-calculate all past frames as it goes from frame to frame out of order.
SOLUTION: The typical workflow would be to cache the TP system to its native TP Cache first. Put the cache on the network where all render nodes can see it, then submit the scene for caching to multiple machines (assuming Deadline is being used). Each machine will be able to jump to any arbitrary frame without recalculating the preceding frames and the saving performance will be improved significantly.
Same applies to Particle Flow using for example the Box #3 Disk Cache operator, except that PFlow is not supported by XMesh Saver as a Velocity source yet and the Velocities will be acquired the same way as with regular deforming geometry (supporting Velocities from PFlow is on the Wish List).