When an application uses complex Customizable Objects with many parameters, updating the instances may be a costly process that takes many milliseconds. However there are some usage scenarios for games that require these updates to be interactive, and big delays are not acceptable. In order to optimize your data to solve these problem, Mutable has the concept of States.
A State represents a specific use case of a Customizable Object in your game. For example, at some point during character creation you may want to let the player customize the face and hair of a character. During this stage, you show a close up camera of the character head and display a user interface for the related parameters: hair color, nose size, hair style, etc. During this stage, you will not be modifying other parameters, like t-shirt color, torso tattoos, etc. In order for Mutable to provide maximum performance, you can create a State in your Customizable Object, indicating that the subset of parameters that you will modify in these stage, and the system will generate an optimized version of the data that updates faster.
In the Editor Preview Instance, you can choose which state to use by using the State combobox located at the top.
States also give you more options in order to optimize the instance construction time. For instance, in the previous example of the head customization stage, your game may have more graphic resources available because, instead of being inside a level, you are in a smaller lobby scene. This means that you can afford to temporarily use more memory for your character. For each individual State, Mutable gives you these optimization options:
- Do not Compress Runtime Textures: Avoid texture compression for textures that may change in this state.
- Build Only First LOD: Only generate the LOD 0 of the object.
- Forced Parameter Values: List of Enumeration Parameters that will be modified when the state is selected. For example, allows to hide the jacket when editing the underneath shirts. The first filed represents the Enumeration Parameter name, while the second field is the forced value.
States are created in any Base Object Node. If no state is created, a default state with no optimized parameters and sensible optimization options will be automatically created. A Child Object can can contain its own States. A State defined at a Child Object functions identically to a states defined at the Base Object.
Ideally, a game should have an "in-game" state with no optimized parameters, and several "customization" states to create and update objects in the different in-game customization scenarios.
The Runtime Parameters array defines which parameters are going to be optimized for a given State. Each of these parameters can be of the following types:
- Group Object Nodes
- Float Parameter Node
- Enum Parameter Node
- Color Parameter Node
- Texture Parameter Node
- Projector Parameter Node
- Group Projector Parameter Node.
The Runtime Parameters array be found on the bottom of the Base Object and Child Object properties details: