Summary
Code for the Transition Libraries examples.
Class Types
| Class | Summary |
|---|---|
| SerializablePose | Animancer's flexibility is usually quite helpful, but that's not the case in situations where you need to serialize the animation details because anything that can be changed will need to be serialized somehow. There are two main reasons you might want to serialize the current details of Animancer, each with different priorities in their implementation: - Files - When saving a file, the most important factor is generally forwards compatibility, i.e. the ability for files saved in an old version of your application to be loaded in a newer version. - Networking - When synchronising animations over a network, you can generally force everyone to be using the same application version so it's generally much more important to minimise the amount of data you need to send in order to maximise speed. Networking is a much more common use case for animation serialization so that's what this example focusses on. However, actually setting up networking stuff is far beyond the scope of Animancer so the data structure focuses on efficiency but is then simply saved to a file for the sake of demonstration. The reason that distinction is important is because data efficiency can be greatly improved by limiting what it can represent. For example, you could write a script to create 7 different `AnimancerState`s on the same layer, set some of their weights to 0.1, others to 0.2, have some states fading to other weights, some playing, some with different speeds, and so on. If you do that, then your serialized data would need to include all of those values. But most applications just stick with calling `animancerComponent.Play(transition)` which reduces the required serializable data to something like this: - Number of active states - Usually 1, can be 2 during a fade, or more if a fade is interrupted by another fade. - Remaining duration of the current fade - 0 when a fade isn't in progress. - Identifier of each state - This is an index retrieved from the Transition Library. - Current Time of each state. - Current Weight of each state. That allows the data to skip some things which can be inferred or recreated on the other side: - If a fade is in progress, sort the states so that the first one is the one that's fading in. That way the data doesn't need to include the target weight of each state. - If speeds aren't being controlled, they can just be initialized from their transitions. Or if they are, then the systems controlling them will probably also need to be synchronised so those systems can simply control the speed value in the same way on the other side. - If multiple layers were being used, then we would also need data for their weights and states. |
| Serialization |
An example component that manages save and load buttons. |
| Transition |
An example component which creates buttons for playing each transition in a library. |