Since I've been making this all on a laptop device, I can't make a video guide, so a brief forum guide topic will be added later.
It took a really long even though the main decode work was done years ago - you've seen animations in OpenIV already. Another major step was done in CodeWalker that is able to decode YCD files to XML. To my surprise I haven't found a "YCD from XML" recreation feature there, as this would make the task much easier (an XML import/export).
Well, using the native YCD files was always a preferred choice for me, so I pinned to this approach.
YCD files can be imported with automatic parts/bones assignment. Playback is quite natural. A set of YCD features can not be mapped onto ZModeler's available tools set, so some data is ignored and lost on import. This is still a subject to decide whether this is an important data or not. Additionally, I've added user-defined options in animations and tracks, so they can hold some unknown data for later use. In particular, user-defined options are utilized for audio binding.
Features list:
Import of full YCD file or individual clips from a package.
Export of full YCD file only (several annimations in one YCD in a single export run). One clip (replacement/injection mode) will be added later.
Animation files do not contain bone names, so the model file (YFT) have to be loaded first, so you get a properly named tracks.
Animations use hashes all around, there is no any text references there except the clip name itself. Some hashes are resolved to object names from the scene, some have evaluated hashes coded in the filter already. However, you might have some settings that will still contain hash instead of a text representation. Hash could be either "Hash_2345DF01" or "0x2345DF01" (leading Hash_ and 0x are equivalent).
Animation events (key frame with event and event number in ZModeler) are used to insert properties and tags onto animation. Meanwhile, only tags (a property at some key time) is available, general-purpose properties are currently ignored. See a section about "Tags" below.
Animation quality and performance is not optimized. The file size of animation can increase because ZModeler does not utilize all possible packing and optimization of animation data, only some techniques are used. Performance can suffer too, as natural game's animation are made "low-resolution" with additional "high-resolution" (e.g. feet, hands and fingers movements are additional hi-res animation). ZModeler merges them together into a single high-resolution animation.
Key frames could be interpolated, it's not a must to create smooth curves with a dozen of key frames. Use available ZModeler animation features to create curves, exporter will do the rest.
Root (skeleton base) animation is also imported/exported as a "[root]" track. However, importer disables it by default on import, so playback will not affect skeleton position, only bones are animated. Most of ped's movement animations do use root animation (e.g. walking, start and stop of walking).
Some unknown properties are moved into animation's (and track's) User-defined options. So far I've seen them on "SKEL_ROOT" bone and unknown bone with ID "0x3cd2". The latest one has no animation keys, just property assigned.
My laptop dies of overheat while game is loading, so I run in-game test for just few seconds only and, in particular, have no idea how to test ped animations.
