ICE kinematics allows advanced riggers and TDs to create custom rigs using a minimal number of control objects. A rig can be composed of simply the manipulators and the deformers. There is no need for complex hierarchies of helper objects — instead, an ICE tree can implement complex behaviors for the deformers' transformations based directly on the manipulators's transformations. This can greatly simplify and speed up very elaborate rigs. It also allows for more portability and reusability.
Using ICE in this way can become very complex, especially if you are not familiar with the mathematics underlying transformations and kinematics. Typical animators are unlikely to create their own rigs in ICE — instead, they'd use any of a variety of rigs built by expert riggers for specific purposes.
The main thing that makes ICE kinematics different from using ICE to control particle simulations or geometry deformations is that it involves setting the transformations of objects. Almost everything else, including connections, context, data types, and so on, is exactly the same as in the rest of ICE.
However, there are some specific rules when setting objects' transformations:
You can write only to kine.global, not kine.local. However, you can get either matrix and use it in your calculations.
You can write only to the whole kine.global matrix, not to components like pos or posx. However, you can still get components like pos or posx directly — you don't need to get the whole matrix and decompose it in your ICE tree.
You can write to kine.global only once per object per tree. If you set an object's kine.global property and then get it later in the same tree, the original values from before the tree started to evaluate are returned. To workaround this, you can either use a second tree above the first one in the stack, or store intermediary transform values as a custom ICE attribute and then set kine.global at the end of the tree.
ICE writes transformations at the same priority level as constraints, so ICE kinematics takes precedence over other forms of animation such as fcurves, expressions, and mixers.
You need to be very careful about which ICE trees get and set data on which objects to avoid complex interdependencies that do not evaluate properly.
For some examples of scenes that use ICE kinematics, look at the Kinematics_* scenes in the ICE subfolder of the Scenes folder of the XSI_SAMPLES project. For some compounds that you can use when building your own scenes, use the plug-in manager to connect to the ICE_Kinematics workgroup located in the Application/Workgroups folder of the Softimage installation location (see Connecting to a Workgroup [Customizing Softimage]). After you have connected to the workgroup, the compounds can be found under ICE Kinematics on the Tasks tab of the preset manager.
Except where otherwise noted, this work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License
