About the model (Native)

[Last updated: 11/07/2019]

 

 

Editing Model Information

Model information is essentially created in Modeler.
The movement of vertices and other objects relative to the parameters is recorded in the .moc3 file.
Other physics operations and user data attached to the ArtMesh are output as separate files.
The .model3.json file is what keeps track of all file references related to the model.

You can output .moc3 files from Modeler at the same time. “Exporting Data for Embedded Use”
You can also use Cubism Viewer (for OW) to add built-in settings for motion and facial expression files and pose files.

 

Reading from .model3.json file using Framework

In loading using the Framework, the necessary information for the model is extracted from the .model3.json file.
It is assumed that instances inheriting from the CubismUserModel class will be maintained and used.

Each element extracted into the ICubismModelSetting class can be loaded with the CubismUserModel::Load~~~ family of functions.

The overall loading flow from the .model3.json file
is easy to grasp by following the flow from the LAppModel::LoadAssets function in the sample to the LAppModel::SetupModel function, CubismUserModel::CreateRenderer function, and LAppModel::SetupTextures function.

 

Instance creation (loading of .moc3 file)

First, load the .moc3 file into memory.
Pass the read buffer and size to the CubismMoc::Create function to first create a CubismMoc instance.
Next, call the CubismMoc::CreateModel function to create a CubismModel instance.
From this CubismModel instance, the user manipulates parameters and acquires information for drawing.

The CubismMoc::CreateModel function counts the number of models created by the function inside CubismMoc, and
When discarding a CubismMoc, all CubismModels generated from all CubismMocs to be discarded must be discarded.

 

 

Graphic Environment Associations

The Framework uses classes derived from the CubismRenderer class to make the model texture information independent of the graphics API.
All graphics-related information associated with the model is managed by classes derived from the CubismRenderer class.
By generating classes derived from the CubismRenderer class for the graphics API and
registering a CubismModel instance with the CubismRenderer::Initialize function, CubismRenderer and CubismModel instances are linked.

 

 

Texture association

The textures that models have in the Framework are managed by a class derived from the CubismRenderer class.
However, that functionality avoids dependence on the graphics API, so its methods are not registered in the CubismRenderer class.
Note the change in method specifications depending on the target graphics API.
The OpenGL process uses the CubismRenderer_OpenGLES2::BindTexture function in the CubismRenderer_OpenGLES2 class, which is derived from the CubismRenderer class, to register the textures.
The first argument is the texture number of the model, identified on the Editor by the number of the texture atlas.
The second argument is the texture's OpenGL management number.

The example below shows texture loading in Cocos2d-x.

 

If Texture is not managed by Cocos2d-x, but OpenGL alone, it is registered through application side management.

 

 

Specify display position and size

With the previous settings, the model can be drawn, but
in many cases, the display position and scale are too different to be shown on the screen as is.
See “DrawableVertexPositions Range” for the vertex range returned by the csmGetDrawableVertexPositions function.
To adjust the size, use the CubismModelMatrix class and the CubismModel::GetCanvasWidth and CubismModel::GetCanvasHeight functions.

This matrix is multiplied by the Projection matrix before drawing and passed to the renderer as an MVP matrix.

 

 

Vertex Update

Execute the CubismModel::Update function to reflect parameter operations on the CubismModel instance to the vertices of the ArtMesh.

 

 

Drawing

Drawing is not executed from the CubismModel instance, but by commanding the renderer associated with it.

 

 

Discard

Destroying an instance requires destroying all CubismlModels and then destroying CubismMoc.
To preserve this order, CubismModel is deleted by CubismMoc::DeleteModel.
If not via this function, a warning will be issued because the number of models checked inside CubismMoc does not match.

 

 

Using parameter IDs that do not exist in the model in the CubismModel class

The CubismModel class parameters and part opacity operations have the ability to handle IDs that do not exist in the .moc3 file.
This functionality is used by the CubismMotion class, the CubismPose class, and other classes, and
if creating a new mechanism using this function, be careful to use an ID that does not conflict with existing functions.
Also, when reading the Framework, keep in mind that it may be linked to other functions using created parameters.
* Accessing a non-existent maximum, minimum, or initial value will result in an error.

 

© 2010 - 2022 Live2D Inc.