Soft Skinning in Silverlight

Soft skinning is feasible in Silverlight with important limitations.
Silverlight has fantastic features and tools for creating and blending animations. This can be leveraged to create more complex animations than it was intended to create.
This is the same technique used to animate most characters in 3D movies and 3D games. I just implemented it in 2D in Silverlight.

You can see my test case below. Yes, it is as ugly or uglier than this webpage.
I'm not an artist and prettiness was not a part of this prototype. The prototype was a Silverlight coding learning exercise and a tech demo of soft skinning.

The input to this Silverlight application is Xaml created entirely in Expression Studio 2, with only one manual step in the Xaml source. This is important because it means that the artists can develop the content largely using existing tools and therefore their skills with those existing tools can be leveraged for this technology. From another perspective, it means that if you needed to hire 5 more artists, you will be able to find artists who are already trained on your tool chain.
The code identifies the skeleton of red Canvas elements by the name of the topmost Panel, "skeletonRoot". All UIElements parented to a Panel underneath that root bone is considered a bone. It similarly identifies the Path's to skin as the children of a named Panel, "shapes". The points of the paths are considered the vertices of the skin. On initialization, for each vertex the code finds the two closest bones. It determines a per-bone weighting factor based on distance from the vertex to the two closest bones. This can easily be extended to other schemes but should also be persisted (see Future Work below). As the animation runs, the code updates the transforms for the bones and sends those transforms to the skinning system. The skinning system updates the vertices of the paths based on the bones's transforms and vertex to bone weights.

Future Work

• Artists must have a way to manually weight vertices to bones. No automated system will satisfy all artists' needs all the time. You can see what can go wrong with such algorithms as a torso vertex is pulled up by the elbow bone.
• Support more line segment types. The unified class for all path segments is too abstract to contain a unified vertex data property. This makes sense as an object model. The consequence is that my code would need to contain a special case for each type of segement. I implemented one for LineSegment. PolyLineSegment would be trivial to support. BezierSegment would be more challenging.
• Better skeleton animation authoring tools. Normal skeleton movement is purely rotational. Your arms and legs, after all, don't stretch and shrink, they just swing around. What this means in terms of transforms is that the RenderTransformOrigin for each bone should be its' parent bone's location. The default in Expression Studio is for RenderTransformOrigin to be the middle of its UIElement. I moved these manually in Expression Blend, which is not a good solution for a variety of reasons.
  3D artists are used to being able to copy poses, anchor bones in space (keep feet on floor), and much more. Existing Silverlight tools don't do these things and should not be expected to do them.

Grievances, Festivus-style

• I wanted to make that animation look better by inserting some delay before the first keyframes. I could not figure out how to feasibly do this in Expression Blend 2. I found no way to insert time into a storyboard or to select all keyframes to drag them. I could have selected all keyframes manually and dragged them, but that also entails expanding the entire tree of bones and bone transforms to expose all keyframes first. Too much work and not necessary to prove the tech works.
  This seems to me like a very basic operation, so maybe it's in there and I couldn't find it.
• Expression Studio always uses the Path Data special markup language to store paths, with one known exception. This is a good thing for many reasons, and it is what I want it to do. However, in Silverlight 2 there is a huge difference between a Path loaded from Data markup language and the same Path loaded from Xaml with explicit segments.
  You cannot read the Data at runtime if it was loaded using the special markup language.
  I can't find the link for the workaround to give proper credit, but the workaround is to create a storyboard targeting the Path then move a point on the Path in Design or Blend. This forces the Xaml engine to not use the special Data markup language. It is not feasible to expect all artists to remember to do this all the time. In my opinion, the proper fix is within Silverlight 2 not Expression.
• If the bones are not visible, the animation for them does not alter their RenderTransform's. This is a fantastic thing for all other uses of Silverlight animation but causes problems for this usage. To workaround this, one would need to push the bones behind the skin in z-order and design the art so that the bones are never outside the bounds of the skin. It might be possible to use a clipping path on the bones to workaround this.
• I could discover no method by which my code could receive a callback when a UIElement's RenderTransform was altered.
  There is no DependencyPropertyDescriptor.AddValueChanged in Silverlight. Jafar Husain blogged about one workaround for this, but my investigations (thanks again Reflector) led me to conclude that his workaround only works for value-types.
  The base classes for RenderTransform (GeneralTransform and Transform) expose no data that can be compared, such as a Matrix. This is a proper design for most use cases, but means that my code cannot detect changes from frame to frame.
  The end result is that my code is polling all bones for transforms (using TransformToVisual) on every frame and altering all segments' points on every frame. That is bound to cause performance problems. I'm so certain that this is a bad idea that I didn't bother finding the limits.
• Altering a PolyLineSegment's Points collection does not cause the owning Path to re-draw.
  Calling InvalidateArrange each frame crashes things. Calling InvalidateMeasure each frame does not cause a redraw. The workaround I am using is changing Figure.StartPoint then setting it back to its original value. This is done every frame, though I could detect whether the figure's points had changed before doing this.
• TransformToVisual is awesome! Except that it's incomplete.
  I'm sure there are many special cases that it misses, but one of them caused me problem. Stretched canvases have a scale transform applied that TransformToVisual does not include. I suspect that it's also missing Path.GeometryTransform. Even if these were part of TransformToVisual, PathGeometry.Transform should not be part of it but does influence my algorithm.
  I suspect that there are more special cases not handled by TransformToVisual that would have to be worked around by my code.