Different motion management at different parts of the site

[Last update: 10/06/2022]

Cubism SDK for Java is currently in alpha version, and the specifications may change in the beta or official version.

This page is intended to help you achieve different motion management for the right and left hands.
As an example, let's increase the CubismMotionManager holdings in LAppModel and incorporate 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 Motion Manager are prepared and
Motion managers can be separated to achieve parallel motion playback.


Increase CubismMotionManager

Add Motion Manager

First, we will look at the implementation on the program side.
The first step is to add a management class to the model.
We will add CubismMotionManager to the sample LAppModel.
Also, add the generation process to the constructor.



Update process

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

When adding inside LAppModel.update, make sure to place the updateMotion between _model.loadParameters(); and _model.saveParameters();.
Also, if updateMotion is executed multiple times, the parameters to be updated may be duplicated.
Note that in this case, the contents of a later updataMotion will take precedence.


Playback start

Then, the motion manager added in the form of a duplicate or modified startMotion-type function can be used to direct motion playback.
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 tap.



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, it is necessary to decide which motion manager is responsible for which part of the body, and thus which parameter operations.


The video above shows an example where the parameters of the left and right arms were updated by a motion manager with a lower priority (in charge of idle motion for the entire model) immediately after the motion manager with a higher priority (in charge of motion for the left and right arms) finished playback.
This is not a desirable representation if you want to keep parameters that are updated by a high-priority motion manager in the state they were in immediately after the motion playback ended.
This phenomenon is seen when a reference value is set for a parameter that is not intended to be updated in the motion data to be played back by the 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.