Different motion management at different parts of the site

This page is intended to help you achieve different motion management for the right and left hands.
Using the case of increasing the CubismMotionManager holdings in LAppModel and incorporating them into LAppModel::Update as an example,
we will look at some of the management and motion creation considerations.

 

 

Increase CubismMotionManager

Adding managers to the model

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.
Add creation and deallocation to the constructor and destructor 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();,
UpdateMotion should be installed.
Also, if UpdateMotion is run multiple times, the parameters to be updated may overlap.
Note that in this case, the contents of the later executed UpdataMotion take precedence.

 

Playback start

Then, the motion manager added in the form of a duplicate and modified member function of the StartMotion system
should be able 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 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 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 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.