UMA - Unity Multipurpose Avatar

UMA version 1.0.1.0R Unity 4.3

What is UMA?

UMA - Unity Multipurpose Avatar, is an open avatar creation framework, it provides both base code and example content to create avatars. Using the UMA pack, it ?s possible to customize the code and content for your own projects, and share or sell your creations through Unity Asset Store.

Overview

Avatars generated by UMA framework

Close on detailed avatar

UMA results on PRO and Free licenses are meant to be as similar as possible, however calculating a UMA atlas can be handled differently. For PRO it ?s possible to create the atlas using RenderTextures, so texture calculation is very fast. For Free license, it requires processing each pixel individually, so it takes considerably more time and processing power. It ?s possible to split this calculation over as many frames as necessary to avoid drastically lowering frame rate, but higher resolution textures will require a considerable amount of time to be processed. The gameObject UMAGenerator provides an option for using PRO or Free, I ?ve left this as a way PRO users testing performance of content on indie projects, for example. The Free license users need to uncheck the usePRO checkbox on UMAGenerator.

How does UMA work?

Creating 3d characters is a time consuming process that requires a number of different knowledge areas. Usually, each character is created based on an unique mesh and rig and is individually skinned and textured.

When developing games that might require a huge amount of avatars, it ?s expected to develop a solution to handle avatar creation in an efficient way. Usually they start from a set of base meshes and follow standards to be able to share body parts and content. Each project ends up with a different solution, and it ?s hard to share content or code between them.

UMA is meant to provide an open and flexible solution, which makes it possible to share content and code between different projects, resulting in a powerful tool for the entire community.

UMA has two main goals: Sharing content across avatars that uses same base mesh and optimizing created avatars, while providing the ability to change avatar shape in realtime.

To achieve that, I ?ve created a special rig structure that handles bone deformation in a strategic way that makes it possible to deform UMA shape based on changes on bones position, scale and rotation.

UMA example avatars are based on two base meshes, a male and a female. Each of them can share clothing and accessories, and can be used as a base on the creation of new meshes for different races.

Because clothes and accessories are skinned to UMA base mehes, they receive the same influece of UMA body shape, so any mesh deforms to any UMA body.

All UMA content that provides a mesh is a slot. Slots are basically containers holding all necessary data to be combined with the rest of an UMA avatar.

For example the base meshes provided are normally split into several pieces, such as head, torso and legs... and then implemented as slots which can be combined in many different ways.

An UMA avatar is in fact, the combination of many different slots, some of them carrying body parts, others providing clothing or accessories. Lots of UMA variation can be created simply by combining different slots for each avatar.

Slots also have a material sample, which is usually then combined with all other slots that share same material. Female eyelashes for example, have a unique transparent material that can be shared with transparent hair. It ?s necessary to set a material sample for all slots, as those are used to consider how meshes will be combined. In many cases, the same material sample can be used for all slots.

UMA standard avatar material uses a similar version of Unity ?s Bumped Specular Shader, but UMA project provides many other options.

The big difference between body parts and other content is that body parts need to be combined in a way that the seams wouldn ?t be visible. To handle this, it ?s important that the vertices along mesh seams share the same position and normal values to avoid lightning artifacts.

Example of Male slots.

To handle that, we provide a tool for importing meshes that recalculate the normal and tangent data based on a reference mesh. UMA MaterialBuilder will be explained in following pages.

Each slot requires at least one overlay set but usually receives a list of them. Overlays carries all the necessary textures to generate the final material(s) and might have extra information on how they are mapped. The first overlay in the list provides the base textures, and all other overlays included are combined with the first one, in sequence, generating the final atlas.

UMA standard shader requires two textures provided by overlays, one texture for Diffuse color (RGB) + overlay mask (A) and one texture for Normal map(GA), Specular (R) and Gloss (B). These non-standard textures let us compress a lot of information in only two textures, reducing final memory usage.

Together, Joen Joensen and I have worked on “UMA u ”,
that receives 3 standard textures for Diffuse(RGB) + mask(A), Normal map(RGB) and specular(RGB) + gloss(A), and compacts the data into the two textures described above. In the process, the specular color is reduced to one channel of data, the resulting average color of the 3 channels provided.

FwgPT‘ “BfC Au M ” http://www.manufato.com/?p=902, Joen and I worked together to reach two shader that handle specular color based on diffuse color reference resulting in Dielectric and conductor materials.

I ?ve already managed to integrate some of the most common Unity shaders into UMA and the adjusts required are quite simple. Even more advanced shaders can be integrated and used, keep in mind it ?s possible to provide extra textures on each

Example of overlay composition

Both UMA male and female base textures have a specific resolution. Below is the list of those base texture sizes in
pixels:

- Head : 2048x1024
- Body : 2048x2048
- InnerMouth : 512x512 - Eyes : 512x512

Male body UV layout

Those values are specific to the provided base meshes as a standard for anyone creating content for them. If you plan following a different standard, it ?s possible to use any different resolution.

When creating new content for UMA, if you ?re aware it will be covering an area of UMA body texture, it ?s possible to use that UV area for the new content texture, if it offers enough space. This example can be seen on Female tshirt and hair, both of them save atlas space, having those textures as overlays for body base texture instead of being base textures themselves.

Also, any overlay texture and it ?s covered base textures don ?t need to keep the same size. For example, FemaleUnderwear01 overlay covers only the left half of the base, so it ?s possible to have that overlay with half the width of body base texture.

The Rect provided together with the overlay elements is responsible for keeping information of the positioning adjust of the cropped overlay, relative to base texture coordinates.

It ?s possible to provide overlays that will receive color adjusts at atlas creation. In those cases, usually the predominant color is white or gray in those areas, to have a neutral influence over final color.

This is where all the UMA magic happens. All shape variations we can achieve on UMA avatars are a consequence of changing bone scales, positions and rotations. A mesh correctly following those changes depends on rigging and skinning entirely and an incorrect skinning process might lead to issues such as a clothing pieces not following the same shape variation as the body.

I ?ve provided base meshes with rig and skin data because most 3d software has specific tools that allow users to transfer bone weight data between different meshes avoiding most of the time consuming process involved. I ?ve shown this being done in Blender at some video tutorials (http://www.youtube.com/watch?v=ImD6APS0xek), but the same can be done with XSI Gator or other specific solutions.

For dresses or armor, simply projecting those values might not be enough, and skinning knowledge may be necessary for best results following body variations. fu guwg f wuf-

uf g T f UMAg,f u able to change the arm scale both in uniform and non-uniform ways, but having an non-uniform scale deforms all child bones too, so those changes need to be applied to the child bones working in pair. It ?s also important to keep in mind it ?s always these child bones that carry the skinning data, as it will always change directly, and under the influence of the parent bone.

Male jeans skinning and male base mesh skinning. Skinning Data has been projected with Blender Transfer weights tool

Importing files: I ?ll focus on gf f “Content

creator pack”, w exported from blender, there ?s a small change required when importing base mesh fbx files to 3 ,u “units” “Centimeters”
size.

As you can see on the
following image, the fbx file (upper
mesh) has the correct rotation and
is fully rigged and skinned. The Obj (lower mesh) file requires manual rotation adjusts after importing process.

3 f “skinwrap” u
for copying skinning data between UMA base mesh and your own content.

Exporting files: The same warning I ?ve provided for blender users apply here too: It ?s very important when exporting content being sure both it ?s position, rotation and scale are normalized. It ?s possible to adjust mesh pivot using

“Affect Pivot Only” u T ? f ju required when creating your own content, the Z rotation value of the mesh should be set to 180 degrees, this is usually done entering Affect Pivot Only mode and rotating the pivot itself.

When exporting the fbx files, you need to have both your content mesh and rig selected. It ?s usually a good idea not including the cameras and lights on the fbx files. For

g, u “automatic” “Up Axis” “Z up”

UMA is integrated with an humanoid mecanim avatar, opening a huge list of animations that can be retargeted to any UMA avatar. Both Male and Female UMA prefabs had their mecanim avatar settings adjusted. UMA rig provides enough bones do handle facial animation, the same techniques required for facial animation on any mecanim avatars apply to UMA.

Slots that provide extra bones not linked to humanoid mecanim avatar require extra adjusts to properly receive animation, as animation data won ?t be retargeted to those bones.

Mecanim avatar creation API

Example of bone driven facial animation

Mecanim

Unity 4.2 provides an Mecanim avatar creation API, this is necessary to recreate mecanim avatars based on changes UMA rig might have received. Before unity 4.2, this was not possible and I had to use LateUpdate to keep bone changes, consuming extra processing time and possibly breaking Mecanim IK depending on the kind of changes bones received. UMA latest version already integrates Mecanim avatar creation and provides full suport to IK and Root motion thanks to Joen Joensen and Mecanim team help.

UMA Components

Joen provided a diagram for the beta group showing the relationship between the various parts of the UMA framework. I ?ve included a new version here to help explaining how avatars are created.

Libraries

All avatars created need to have access to a set of necessary data: Races, Slots and Overlays. Each library provides a list of each of those within an dictionary, being the key an string with the name of the element, and the value the element data itself.

For projects with big amount of content as mmo games, you probably don‘t want everything loaded in memory and loading/unloading assets might become necessary, this case requires implementing custom libraries.

Each RaceData on the race library provides a prefab with all shared scripts, avatar data and etc, one or more DNAConvertes and a list of the name of bones that require being updated.

As you ?ve noticed, I ?ve separated male and female as two different race datas. This is because each race provides an specific base mesh and rig/skinning data, and usually require specific content. Using unique base meshes for male and female gave me the possibility of reaching a better silhouette and topology for each of them.

DNAC g u “height” “armSize” to bone deformation and shape changes. It ?s possible to have two different races with u “height” “armSize”, u f erting those values

in different ways.

- Slot library

Each slot provides a skinnedMeshRenderer and a material sample, as explained earlier. If you ?re planning on inluding extra bones on any Slot, it will be necessary to u J ? “UMA u ” for generating the slotData, as it is responsible for identifying if there ?s any extra bone and listing all their transforms.

The first overlay in the slotData ?s overlayList provides the base textures, and all other overlays included are combined with the first one, in sequence, generating the final atlas.

Overlay library gives access to all available overlayData , This library might use a huge amount of memory depending of the project, as it keeps direct reference to texture files. By default all UMA textures are provided with read/write tag checked, but this is only necessary if you ?re using free license.

Each overlay have an color that can be used to tint it ?s first texture on textureList. Usually this value is set by code, at the moment the overlay is being included on the slot.

The Color32 arrays channelMask and channelAdditiveMask gives exceptional control over adjusting texture channels. Each color here will change the overlay texture from overlayList sharing the same index. With this, it ?s possible to adjust each texture channel of each overlay of an atlas.

For example, if we consider reducing the gloss value of a hair texture, we could set an channelMask second color (index 1, relative to second texture, where normal map,s u g ) “” wervalue.

Functions public void SetColor(int overlay, Color32 color) and public void SetAdditive(int overlay, Color32 color) on overlayData are responsible for setting those values. We could have something like hairOverlay. SetColor(1 , new Color32(255,255,50,255)); to reduce gloss value on above mentioned example.

The rect value is specially useful if you ?re providing an overlay that covers a small area of the base texture. Both male and female
eyebrows cover only a small part of the head base
texture, and it would be a waste of memory having a

huge texture with most of it ?s area completely masked.

The x value is the horizontal offset of the cropped overlay, y value is the vertical offset, and width/height are relative to cropped overlay size.

cropped overlay being combined to base texture

I ?ve managed to include on Overlay library a set of buttons to adjust all overlay textures in a single click, this is specially usefull to reduce the resolution of all textures or set their compression.

- UMADna

Being able to adjust avatar shape in real time, even if the avatar share both texture atlas and mesh is very powerful. This is possible because we use bone changes to deform both the avatar body mesh and it ?s clothes. To archive those bone changes, we need to know both which bones should be adjusted and how this should happend.

UMADna holds the values from changes an avatar can receive, and we provide an UMADnaHumanoid class inheriting from UMADna as example of how this works. Both male and female avatars uses this UMADnaHumanoid to define their shape values.

If you consider the winged humanoid on the diagram image, it might be possible to have a single UMADnaWinged being used by both male and female wings. This class would

u“z”,“z”“lg”

- DnaConverterBehaviour

The DnaConverterBehaviour is responsible for converting the Dna values to bone changes, This is where the code for deforming bones is kept. We provide both an HumanFemaleDNAConverterBehaviour and HumanMaleDNAConverterBehaviour inheriting from DnaConverterBehaviour and as you can see, male and female avatars share the same shape values, but resulting bone changes are specific to gender.

Creating UMA avatar

UMAGenerator

UMAGenerator provides all necessary functions and methods to handle avatar creation. Creating an avatar is done in 3 steps: calculating it ?s final mesh and rig, processing it ?s texture atlas and updating it ?s shape.

umaDirtyList keeps track of all UMA avatars that need to be created or updated, in documentation following pages it will be clear how and avatar is included on list.

Both usePRO and convertRenderTexture visible as checkboxes on unity editor are very important. If you have an Unity PRO license and usePRO enabled, it ?s possible to create the atlas using RenderTextures, so texture calculation is very fast. For Free license, it requires processing each pixel individually, so it takes considerably more time and processing power. It ?s possible to split this calculation over as many frames

FitAtlas Forces final atlas to fit Atlas resolution in case the resulting atlas size would be larger than maximum size.

AtlasCrop Final atlas unused texture space will be cropped. If you need the resulting atlas being a square texture, this is not recommended.

UMAGenerator

UMACrowd is an example of how UMA avatars can be randomly created based on content we have on libraries. Both colors and shape values don ?t have any elaborated creation method. In most games you will need a color palette and more control over shape and cloth combinations.

First of all, UMACrowd needs to keep track of SlotLibrary, OverlayLibrary, RaceLibrary and UMAGenerator. You can consider UMACrowd as a chef with access to all necessary ingredients and tools to cook an unique meal. Each UMA avatar, or meal if you wish, is created based on an specific recipe the chef writes based on available ingredients and how they are combined. UMAGenerator is the available tool the chef uses to actually cook the meal, and bake an UMA avatar.

atlasResolutionScale This value changes the overall texture size of all overlays an UMA avatar receives, reducing final atlas size. If you ?re planning on having a lot of UMA avatars with unique atlases, it might be necessary considering a lower value here. Usually the values we set here are 1.0f, 0.5f, 0.25f, 0.125f and 0.0625f, as those are also the values for getting the correct mipmap on Free license. As default, it ?s set to 0.5f, with atlas resolution of 2048.

generateUMA , visible as a checkbox at Unity Editor, checking it generates one random UMA avatar.

generateLotsUMA, visible as a checkbox at Unity Editor, checking it generates a groupd of random UMA avatar, based on below Vector2 value.

umaCrowdSize defines the amount of UMA avatars created on column and row. Default values are 4x4, resulting in 16 UMA avatars.

randomDNA visible as a checkbox at Unity Editor, checking it generates random shapes for avatars, otherside all avatars will have neutral shape.

useLegacyCombine On UMA latest version, the old CombineInstance() code is still available in case there ?s no intention on using extra bones that would be dinamically included on avatar. The legacy code requires less processing time, but provides limited results.

zeroPoint Defines the position where UMA avatars are created. If it ?s empty, defaulf value is Vector3.Zero.

UMACrowd

UMACustomization exemplify changing avatar shape after it ?s creation. Following the same concept, it ?s possible to change UMA slots and overlays, triggering them to update with the new content. At the example scene, right clicking on any UMA avatar updates UMACustomization sliders with its specific shape, after that it ?s possible to use sliders to change any shape value.

UMACustomization generates a rough example of sliders based on GUITextures as reference of how to handle changing UMA shape based on user input, but it ?s clear each project will require a custom approach to handle both GUI and user input.

Exchanging UMA cloth and acessories means changing the array of slots used for creating an UMA avatar and including that avatar on umaDirtyList at UMAGenerator to get updated.

UMACustomization

UMAData

UMAData provides many functions, methods and classes being used on avatar creation as an standard for sharing information.

Each avatar has it ?s own UMAData, that ?s why manually duplicating avatars on Unity editor might generate errors when trying to access any avatar data, as their UMAData has not been properly set.

? f “ ” UMAData. Both isShapeDirty, isMeshDirty and isTextureDirty are responsible to keep track of what needs to be updated or recalculated on this UMA avatar.

isShapeDirty means shape data needs to be recalculated. This is usually set when any DNA value received changes that require updating UMA bones.

isMeshDirty should be set true when UMAData received slot changes and avatar mesh requires being baked again. This also applies if overlays have changed as most likely atlases and in consequence mesh uv will require to be recalculated.

animationController can be an unique animator for each avatar. This is necessary because when the avatar shape changes and a new mecanim avatar is created, the animation controller need to be set back.

umaPackRecipe was created considering that all necessary data to recreate an UMA avatar might need to be saved or shared on multiplayer games. What umaPackRecipe provides is the minimum necessary data for serialization, usually an array with the names of slots, overlays and DNAs, and the extra changes that had been applied to those. All this data can then be unpacked into an umaRecipe. In the process, respective libraries provides elements based on serialized names and extra changes are applied to those.

UMAData