Morph Target Community Proposal

This page is to contain the overall community proposal for "Morph Targets".

Please do not add to this page without authorization from a co-chair or a co-chair's assistant from the Content Creation Improvement User Group first. Please discuss any relevant points in the discussion tab in the wiki.

What is a Morph Target?

A morph target, also known as a blend shape, or a shape key in some 3D applications, is a special kind of "vertex map" containing the positions of vertices in relation to their original position on a mesh. They are relatively easy to work with, only requiring the content creator to "sculpt" or otherwise move the vertices on their meshes to the positions they'd like for a morph target.

Most 3D applications support authoring morph targets, such as Luxology Modo, Autodesk 3ds Max, Autodesk Maya, and Blender. The Collada file format also supports morph targets.

What are they used for?

Most modern video games use morph targets for complex animations that would otherwise be hard to accomplish with skeletal animation, such as facial animation, and even things like character customization. The viewer its self actually uses morph targets to enable avatar customization as-is.

A a small list of examples of what they could be used for in the context of Second Life include:

• Complex facial animations on rigged meshes
• Additional ways for a user to customize the appearance of their avatar
• Animating the surface of a prim without the need to use a custom skeleton
• Fine grained control for content creators over how their clothing deforms

Caveats of Existing Techniques

Existing techniques, such as RedPoly's proposed cBones technique and Qarl Fizz's Mesh Deformer, have their own disadvantages that morph targets are intended to either mitigate, or solve completely.

"cBones" as they're called, have the caveat of requiring content creators to rig many more bones than what would otherwise be necessary for simply animating a rigged mesh. It extends the workflow of rigging a mesh substantially into taking several hours of work; sometimes with a significant amount of trial and error. On top of that, a content creator sometimes is working "blind" with regards to what the final outcome will be in-world. This is not seen as an ideal workflow, as it increases the burden on content creators to produce this content. It does, however, provide more control over the deformation process, and is potentially faster than Qarl's mesh deformer.

Qarl's mesh deformer has the benefit, and caveat, of deforming a rigged mesh in accordance to the avatar's current shape automatically. The reason why some may see this as a caveat, is because this doesn't ensure correct deformation all the time. An example of where this may be undesirable can include custom mesh avatars, where the entire avatar mesh is replaced. A content creator may want to make their avatar's belly deform differently than the avatar mesh's belly does, or may want to have their avatar's breasts deform differently. This is a problem that morph targets could easily solve, by putting content creators in control of how a rigged mesh deforms. The mesh deformer also currently depends on the content creator making their content around a specific shape for it to work properly. Morph targets would lessen the need for this to some degree.

Morph Target Advantages

There are a few advantages of morph targets that existing solutions do not provide.

Workflow

Morph targets allow a content creator to literally "sculpt" how a morph target should appear, directly within their 3D application of choice. This gives them the ability to directly control over how a mesh "deforms" around the avatar, or in the context of rigged mesh replacement avatars, how an avatar "deforms". An ideal workflow would enable content creators to create a "morph map", a special vertex map in their 3D application of choice, and begin sculpting how that morph target should look in-world with respect to the associated avatar mesh morph target.

Each morph target currently should correspond to an existing morph target on the avatar mesh. Some examples include:

• Belly size
• Torso muscularity
• Saddle bags
• Body fat
• Breast size

There are already several pre-existing tools that can work with morph targets, and there's several ways morph targets can be tested. 3D modeling applications such as Autodesk Maya, Autodesk 3ds Max, and Luxology Modo all support morph targets out of the box, and the Collada file format also supports morph targets. One could effectively test different morph target combinations directly within their 3D modeling application of choice, or even existing game-engine toolsets. This would allow for content creators to rapidly iterate with their work, making adjustments on the fly with minimal slow down by cutting out the need to upload meshes to test their work.

Another workflow possibility is one could effectively "bake" the different potential morphs of a mesh, and simply tweak them until the content creator has the general effect they're looking for.

Performance

Morph targets do have some performance implications, however they're largely mitigable. Depending on the implementation, morph targets could have a very small performance impact that could be less than that of Qarl's deformer. This would mean more avatars could be in view using morph targets on more rigged meshes, enabling more people to experience the benefits of mesh clothing that fits properly.

Furthermore, morph targets could some day become an optimization to Qarl's deformer by precalculating the morph targets for a mesh on import. This would provide the potential performance benefits that morph targets provide, while still enabling an automatic solution for content creators to make use of.

Morph Target Disadvantages

Morph targets are not entirely a perfect solution. There are a few notable disadvantages relating to bandwidth usage, and potential workflow disadvantages relating to specific implementations.

Bandwidth

Morph targets require additional information to be encoded either within a mesh, or within a texture. This means that additional bandwidth will be required to transmit any mesh with morph targets.

The bandwidth cost could be mitigated by either determining what vertices have a "similar" position across different morph targets and simply reusing those values, by only including a partial vertex map for the morph target by excluding vertices that don't have unique positions in the vertex map, or by even using textures that can be loaded progressively.

The amount of bandwidth required to support morph targets will vary depending on the implementation approach taken.

Workflow

Although the workflow is largely more streamlined than that of rigging a mesh, it does require content creators learn how to efficiently create morph targets. This will vary largely upon the implementation approach taken to support morph targets on Second Life.

Implementation Approaches

There are a few possible implementation approaches. They each of their advantages and disadvantages associated with them.

Vector Displacement Maps

A vector displacement map encodes the positional information for a given vertex on a mesh. They can operate with relatively low overhead, and can be accessed through a vertex shader to displace an object's vertices. They can also be "baked" and transmitted to other viewers after a morph has been finalized. They're also capable of working with or without tessellation, and can operate reasonably well at lower resolutions.

They would also benefit from progressive loading, and could effectively function as a regular texture on the asset backend. Being regular images effectively means they can also take advantage of image compression.

They can also be used on practically any prim face as well, potentially paving the path towards a general purpose solution in the future for assigning morph targets to standard primitives, and virtually any arbitrary mesh in-world furthering the overall customization of in-world content.

The primary disadvantage to this technique, would be the ability to "copy" the content without the creator's permission by simply using the UUID to the VDM.

Vertex Map Pruning

Vertex map pruning would work by comparing the vertices in a morph target's values against the original positions of the associated positions of the vertices on the mesh. If they're within a particular threshold, those vertices could be discarded from the vertex map. An extension of this method could be to create a list of "similar" vertex positions, and having an optimization process in place that will "link" similar vertices across the vertex maps based upon their position.

This would help mitigate the bandwidth concerns, while also mitigating content theft concerns as meshes are not currently trivial to "copybot".

The downside would be that this requires extensions to the mesh format that could create problems for older viewers that wouldn't support the new morph target functionality. Fallback mechanisms may need to be devised to ensure backwards compatibility. Performance may also become an issue, but ways to mitigate it is to expose a single vertex map to the GPU that contains interpolated vertex positions, from which the GPU can apply within a vertex program better enabling hardware acceleration on a wider range of hardware.

Morph Extensions

TBD

Proposed Initial Feature Set

TBD

Conclusion

TBD