Avatar standard

Standardization is required for collaboration and shared assets. This is a proposal made by Colin The Cat which standardizes a list of Dynamic Variables on the "Avatar" namespace to make avatar systems interoperable and portable and enables artists to create assets which can easily be installed on avatars without using any developer tools.

Avatar systems are anything that goes on top of an avatar base. This includes ProtoFlux logic and other assets such as clothing or body parts.

All variables must be defined including their namespace to avoid them accidentally binding to the wrong namespace: Avatar/VariableName. The namespace must not rely on non-direct binding of variables (direct binding: Avatar/IsAway, non-direct binding: IsAway).

Dynamic Variables

Name	Type	Purpose
Root	Slot	Root slot of the avatar.
User	User	The user that has the avatar equipped as assigned by the Avatar User Reference Assigner.
HasUser	bool	If the avatar is currently equipped.
IsAway	bool	If the user of the avatar is shown as away.
Base	String	Name of the avatar base. Examples: Davali, Mayu.
Name	String	Name of the avatar slot.
Bone.Name	Slot	All bones of the rig using the original bone names.
BodyNode.Name	Slot	All armature body nodes using Body Node names.
BodyNode.Name.Bone	Slot	The associated fake bone, if one is being used.
BodyNode.Name.Hidden	bool	If the body part should be hidden.
Proxy.Name	Slot	Proxies using the Body Node names.
RigCollidersEnabled	bool	As set by Component:VRIKAvatar rigCollidersEnabledStates.
Renderers	Slot	All renderers are children of this slot, if possible. See the #Renderers section.
Renderer.Mesh	SkinnedMeshRenderer MeshRenderer	! Make sure to name it "Renderer' and not "Renderers"
Renderer.Mesh.Enabled	bool	Defaults to true.
Material.Name	IAssetProvider<Material>
Material.Name.Away	IAssetProvider<Material>	Material version when IsAway is true.
Blendshape.Name	float bool	A Dynamic Field on the corresponding blendshape or dynamic blendshape driver value. Use a bool for blendshapes which can only be 1 or 0, such as those used to hide parts of the mesh.
Visible	bool	Drives the enabled state of the renderers slot and defaults to true.
Menu	Slot	Radial menu items root slot.
Menu	colorX	Avatar menu color.
Menu	IAssetProvider<Sprite>	Avatar menu icon.
Systems	Slot	All systems are children of this slot.
Voice	IWorldAudioDataSource	Assigned by Avatar Voice Source Assigner.
VisemeAnalyzer	VisemeAnalyzer
Volume	IField<float>	The volume output of the Volume Meter (used for face tracking).
VisemeAnalyzer.Silence	IField<float>	The silence output of the Viseme Analyzer (used for face tracking).
VisemeAnalyzer.Strength	float	Drives the viseme driver's strength and defaults to 1.
VisemeAnalyzer.VoiceOverride	IWorldAudioDataSource	Drives the viseme analyzer's voice and defaults to Voice. Useful for spoken audio effects.
Avatar/Anchor.Point.Chirality	Slot	Points to the Slot of an Avatar Tool Anchor.

Systems

Avatar systems can be installed by moving their root slot under Avatar/Systems. They can be deleted by moving them out of the avatar and deleting them after at least 5 ticks. This ensures that all driven parents are moved under the system slot.

Systems can install slots anywhere on the avatar by creating a Dynamic Reference Variable Driver for the parent field of the slot that needs to be somewhere outside of the system's hierarchy. The driver needs to stay under the system's hierarchy and the default value needs to be under it as well to ensure that all slots are removed from the avatar when the system is moved out. It is also recommended to add Destroy Proxies for all slots which are moved outside of the system's hierarchy.

A system can be used to store any customizations such as custom materials (including textures), avatar slot name, menu color/icon by creating a dynamic field on an asset loader (for assets) or a dynamic reference variable which have override on link enabled.

Tools

The process of creating the dynamic variables can be partially automated. A tool for creating them and for moving and installing systems can be found at the following record:

resrec:///U-1QbdepR26LI/R-7dc75818-8a95-4a6d-b3b8-3a9010cbf0af

Blendshapes

Blendshapes should preferably be driven through a Dynamic Blendshape Driver component on a system, which then also contains blendshape variables for adjusting at least the cosmetic ones (eg. body shape). Having these blendshape variables is useful for clothing items to adjust to the body of the wearer to avoid clipping. For example, if an avatar has a "Breasts" blendshape, a shirt item could use the variable "Blendshape.Breasts" to drive their own blendshape for adjusting the size to avoid the body from clipping through it. Since blenshapes are usually very specific to an avatar base, just like bones, they should follow the exact naming scheme of the avatar mesh(es).

Note that adding every blendshape as a variable is discouraged, such as visemes, because it can significantly increase the amound of variables on the avatar.

Some blendshapes are strictly binary, which means they should only have the values 0 or 1, like those hiding parts of the body. For such blendshapes, a boolean variable should be used instead of a float. The variable should for example drive a Boolean Value Driver which then drives the blendshape and default to false. This allows multiple systems to control the same blendshape by creating a true variable for the blendshape when it should be 1 and removing it otherwise. This makes sure that systems don't interfere with each other by aggregating the value.

Renderers

The "Avatar/Renderers" Slot should contain all mesh renderers such that it can be disabled to make the entire avatar invisible using the "Avatar/Visible" variable. If a mesh renderer cannot be on this Slot (such as for avatars not using skinned meshes), they can still respect the visibility variable using a dynamic driver. Hiding an avatar can be used for visual effects. It is also possible to intentionally not hide some renderers for visual effects. For example, spiders in the game Minecraft, when made invisible, still show their glowing eyes.

Standard proposals

Booper

Many boopers are simple buttons that make a sound or trigger some other action, these can be standardized through specifying a slot on the avatar that is positioned over the nose, enabling them to be freely migrated between avatars.

Dynamic Variables

Name	Type	Purpose
Booper	Slot	Slot under which boopers can install themselves. This should be positioned over the nose such that a box collider with size set to 1 would roughly cover the entire nose if placed under this slot.
IsBooped	bool	Variable indicating if the avatar is currently being booped (usually the IsPressed field on the button).

Avatar2 proposal

Avatar2 is a dynamic variable often used by 989onan that is used specifically for items that like to make slots that "Jump" from inside of it to slots on the avatar. Issue with these items is that they loose their content that is inside when saved via grabbing, due to the jumpiness nature of their slot hierarchy. That is why these would use "Avatar2" with a dynamic variable space of such on the grab anchor slot. The item will place the slots properly when in avatar hierarchy, but put them back when taken out. This helps for items like hats that change color when held, but parent themselves to the head when their driver flux/Component is in avatar hierarchy (A mix use case of Avatar and Avatar2)