Different motion management at different parts of the site

[Last updated: 01/10/2020]

On this page, in order to realize that different motions can be managed in parallel with the right hand and the left hand,
using the case of increasing the number of LAppModel.cubismMotionManager and incorporating them into LAppModel.update,
we will look at some of the management and motion creation considerations.



Reasons to increase CubismMotionManager

CubismMotionManager has the ability to play multiple temporary motions to accommodate fades.
However, since the API for starting playback ends with a fade-out of the motion being played,
there is no function to keep playing motions in parallel.

To solve this problem, multiple instances of the motion manager are prepared, and
the motion managers to be played back is divided among them to achieve parallel motion playback.


Increase CubismMotionManager

Motion Manager added

First, we will look at the implementation on the program side.
The first step is to add a motion management class to the model.
We will add CubismMotionManager to the sample LAppModel.
Add creation and release processing to the constructor and release function as well.

Update process

Add it to the Update process as well, so that the motion played affects the parameters.


When adding inside LAppModel.update, between _model.loadParameters() and _model.saveParameters(),
make sure to install updateMotion.
In addition, when multiple motions are played back simultaneously, the same parameter values may be updated from two or more motions.
In this case, the content of the later updateMotion takes precedence.


Playback start

Then, motion playback can be directed by a motion manager added in the form of a duplicate or modification of a member function of the startMotion family.
Note that in the startHandMotion function, the motion manager is specified as an argument.
In the following example, only the motion specified in .motion3.json (the motion loaded by the preLoad function) is implemented for playback.


Motion playback adds a hit detection to the model so that it is triggered by a click.



Assignment of responsible parameters

As indicated in the update process, if parameters overlap among multiple motions to be played back, the update performed later takes precedence and the parameters are overwritten.
Therefore, when using multiple motion managers, which motion manager is responsible for which part of the body?
In turn, it is necessary to decide which parameter operations are to be handled.


The video above shows an example where the parameters of the left and right arms were updated by a lower priority motion manager (responsible for idle motion of the entire model) immediately after the higher priority motion manager (responsible for motion of the left and right arms) finished playback.
This is not a desirable representation if you want to keep parameters that are updated by a motion manager with a higher priority in the state immediately after the motion playback ends.
This phenomenon is seen when a reference value is set for a parameter that is not intended to be updated in the motion data played by a motion manager with a lower priority.
At this time, by separating the parameters to be updated for each motion data, the parameters that are updated by the motion manager with the highest priority can be maintained in the state immediately after the end of playback.


Do we keep it separate for each parameter or do we assume overwriting?
It is important to clearly define the specifications before creating the motion to avoid extensive revisions.

© 2010 - 2022 Live2D Inc.