Limitations and Workarounds

Many simulation parameters should only be changed on the start frame.
Many parameters can only be changed on the start frame because it is technically difficult to change them on the fly (e.g. tet mesh resolution). To indicate this, these attributes are not keyable. However, changes to these attributes made on other frames should take effect once the solver is put back to the start frame. If they do not, this may indicate a bug in the software. To workaround it, go to the start frame, change the value to something else, and change it back again. Alternatively, run ‘ziva -refresh’ to rebuild the entire solver. If all else fails, try saving and reloading the scene. If you encounter this, please file a bug report letting us know how to reproduce the failure by emailing support@zivadynamics.com.

Quasi-static solves are not always stable.
If there are insufficient constraints (attachments to bones) in the system, a quasi-static step can explode because the physical quasi-static problem is not well-posed. To solve this, add more attachments. In other cases, instabilities are a weakness of our current implementation and taking more substeps should resolve the issue.

Selecting Ziva nodes in the viewport doesn’t work in Viewport 2.0.
Selecting Ziva DG nodes (eg: zAttachment, zTet, etc.) by clicking in the viewport doesn’t work with Viewport 2.0 in Maya 2016.5, 2017 and 2018. One workaround is to switch to a legacy viewport. Another is to use the “Launch Scene Panel” capability on the Ziva menu (available since v1.4).

Ziva Logging
Ziva VFX writes a log file that can be consulted for additional information should Maya crash. The log file’s location is printed in the Maya script editor as soon as the plugin is loaded, so look there to learn where your log files are going. On Windows, a typical log filepath is:

C:\Users\JohnSmith\AppData\Local\Temp\ziva-maya-log-1f52-836a-6dfe-8bc1.txt

On Linux, a typical log filepath is:

/usr/tmp/ziva-maya-log-660b-29e4-b27b-414d.txt

Changing mesh topology *after* applying a warping deformer (zRBFWarp, zHarmonicWarp, zBoneWarp) is not supported.

We do not support source and target cage meshes with different mesh topology. Also, we do not support changing the source mesh, target mesh or the input mesh topology after it has been added to a warping deformer. Undefined behavior may occur if this is attempted.

For anatomy transfer, source and target cages must be in correspondence.

Ziva Anatomy Transfer tools require source and target meshes (“cages”) to be in correspondence. Undefined behavior may occur if this condition is not satisfied.

We do not provide motion retargeting tools.

We provide tools (zHarmonicWarp) to warp joint hierarchies from the source to the target creature. We also provide tools to transfer the Maya skin clusters from the source to the target creature. See Transferring Maya skin clusters. However, the motion of the target creature must be computed using external tools (motion retargeting).

Do not provide both the shape node and transform node of a mesh as arguments to zBoneWarp.

Doing so confuses the warping node and produces incorrect results. Always provide just the shape node, or just the transform node. Note that this error can occur if you grouped your meshes in Maya, select the transform node of the group, and then ask Maya to select the entire hierarchy. Then, both the transform nodes and shape nodes will be selected, leading to the error. A workaround to this issue is shown in the MEL example below:

// Suppose myGroup contains several bone meshes to be warped with zBoneWarp.
// Select the entire hierarchy. The hierarchy flag selects both the transform and shape nodes
// for each mesh in myGroup, which causes zBoneWarp to fail.
select -replace -hierarchy myGroup;
// Remove all non-shape nodes from selection:
select(`ls -sl -exactType mesh`);
// Now, we can safely warp:
zBoneWarp ...