Harald Trailer

Here is the trailer for the last student short I worked on at Filmakademie. I was the Character/Animation TD and animated one shot.



It recently got the SIGGRAPH 2013 Best Student Runners-Up award, yay!
http://siggraphmediablog.blogspot.de/2013/06/european-directors-win-majority-of.html

The Best Student award also went to a Filmakademie project called Rollin' Safari, all clips are online at: http://www.youtube.com/user/rollinsafari/videos

Maya wrap deformer tips

I just randomly found the hidden smoothness attribute on the wrap deformer and thought I make a post about it and some other options I like to use on the Maya wrap deformer.

Attributes:

• There is a hidden attribute called smoothness. It is not visible in the Maya UI (creation window, channelbox/attribute editor). But it is documented in the node reference. It only works with Falloff Mode: Volume and Exclusive Bind: off. and it creates nice smoothness when set between 0.0 and 0.5. On the downside it moves unaffected neighbors of deformed vertices in the opposite direction, so that may be a reason not to use smoothness for some cases. And because it is not accessible in the UI may mean it is unstable (?)
• When enabled Exclusive Bind improves performance a lot, but may lead to bad deformation. Works especially well when driver and driven have a similar resolution. I used this setting a lot in the past.
• I usually use Falloff Mode: Surface for smooth results, probably because my driver and driven object usually have a similar shape. Smoothness requires Volume mode thou.
• maxDistance 0.0 disables maxDistance

Use cases:

• Deform highres geometry with easier to rig lowres geometry
• When the driving mesh just has a skinCluster I prefer to copy the skinCluster and weights to the highres, because it calculates faster than a wrap deformer and you also have the option of tweaking the weights further.
• Use as partial blendshape, to be able to work on local area and with those patches drive the final one-piece mesh. Edit membership has to be used to avoid double transformation. Not a user friendly workflow. Exclusive Bind can be used to greatly improve speed (if meshflow is similar).

Example:

Kool-Aid commercial: Rig breakdown

Kool-Aid commercial: Rig breakdown from Parzival Roethlein on Vimeo.

The complete spots:
https://vimeo.com/64086798
https://vimeo.com/64086797

The node order of the face, starting with the low resolution geometry:
-> blendShape
 -> skinCluster (for the mouth I put the joints on a curve with motion paths, to tweak the curve cvs without getting intersecting loops, see old post: Joint chain rigging techniques)
 -> bend deformer (To roughly match the body shape. Works for this range of motion, for more range I would recommend using a surface constraint / rivet on the nurbs surface and connect translation to UV values)
[lowres for animators]
 -> smooth (subdivide)
 -> sculpt deformer (project on nurbs surface with the same shape as the glass)
[highres, final shape]

And the highres geometry was used as a mask in compositing.

Adventure Time - A Glitch is a Glitch

Yesterday aired the Adventure Time episode "A Glitch is a Glitch" (AT S5E15 AGIAG).
It was a special 3D episode (usually the show is 2D) and directed by David OReilly.
The rigging was done by Mark Feller and me at Studio Soi in July 2012. My main responsibility were the faces and spines. The faces were made by hand, some parts I could import and adjust after the first one was done. The mouth joints were sliding on a nurbs surface, that had the shape of the face polygons. For the spines I wrote a script (ribbon based. See older post: Joint chain rigging techniques).

This is a clip from the episode:

Maya Naming Conventions

Summary

• L_hand_finger_index_1_joint
• Prefix: The side ("L_..." / "R_...")
• Hierarchy from general to detail
• Numbering starting at 1
• Suffix: Default Maya nodenames ("..._blendColors", "..._multiplyDivide", ...)

Motivation

This is my latest naming convention. I never wrote it down before and also kept changing it. Combined with using many different ones at the companies I worked at, it did get confusing at times.
Because I am happy with it for the first time I made this post, so maybe others find something useful in it.
I tried to be very production oriented. So it should be easy to read, learn, use (string searching / filtering for selection, skinning, sets, ...) and not have any fancy special rules. I try to use as much of the Maya default naming as possible, because a Maya user will always prefer that over something completely made up.
In the past I had really short ones, so I would have to type less, but that is not really important to me anymore, because the time typing is neglectable and most nodes are created using scripts anyway. It is much more important that other users and myself can read the nodes easily.
Since I mostly work in modeling, rigging and animation, other areas are not considered.

Prefix

As a lot of people, I like to use the prefix to identify the side (left, right). It is important for animators while working, so it's good to have it in front where it does not get cut off in  the UI. It should also be short, so that the rest of the name gets cut of as late as possible. And because there are not many options (opposed to many nodetype suffixes) it can just be "L_...", "R_...".

Hierarchy naming / DAG-Nodes

Because it is possible to have multiple transforms with the same name (if they are not in the same hierarchy level) most people put some hierarchy information in each transform to have fully unique names (on the dependency graph level). I prefer to go from general to detail, because that allows for alphabetic ordering when skinning or when string searching / filtering ("L_hand*"). It is also easy to remember, so if I happen to manually name stuff it is harder to make something wrong.
Examples: "L_hand_finger_index_1_joint", "R_arm_2_joint", (if it should be more descriptive: "R_arm_2_lower_joint"), "spine_5_joint"

Numbering

Because of scripting (for x, each in enumerate(pm.ls(sl=1)) I sometimes started numbering at 0 when naming my nodes. But because most people / animators start to count at 1, I would do that as well.

Suffix

I think it is general consensus to use the nodetype as suffix. For my earlier naming conventions I tried to use only 1-3 letters (joint = j, blendColors = bc, multiplyDivide = md). But as I mentioned, I don't think that is important anymore. It's mostly about readability and being foolproof.
For my new convention I prefer to just use the full node default Maya name as suffix ("..._blendColors", "..._multiplyDivide"). This way it is always readable for every user and they are all unique. Also if you create the node manually you will already have the suffix by default, so you have to type less and it reduces mistakes.

Suffix - Special cases from Maya:

• Default transforms will get different names in Maya, depending on how they got created: null1 (empty group), group1 (group for transforms), transform1 (actual node name). Most people call default transforms (no shape / special function) groups, so I stick with group as well.
• Transforms with shapes get names from the shape nodeTypes (locator1, annotation1, ...). So Maya already gave an answer how to name those transforms. Shapes themselves will get the Shape suffix.
• Transform Handles (deformer handles) get named: "nodetypeXHandle" in Maya. So I also use this convention, except for the number in between, so it's only "deformertypeHandle". Example: L_cheek_clusterHandle (cluster itself: L_cheek_cluster)
• ... (probably more)

Suffix - Special cases from users:

• Animation transforms 1: Usually transforms are the only nodes animators are exposed to. That's why they often get named differently. For this convention I prefer "_control" over "_nurbsCurve".
• Animation transforms 2: One nice alternative would be to use no suffix at all. That only works if they are the only nodes with this rule and obviously would be the shortest possible solution. But because strings in most (or all?) Maya UI elements (channelBox, graph editor, outliner, ...) get cut of at the end, if they are too long, it does not make a difference for animators if they can see the suffix or not, because it's the always the same anyways. That's why I prefer to stick with "_control" for now, to be able to work with them more easily.
  
• ... (probably more)

Extra

• To prevent hard to read suffixes when using stacked groups ("..._group_group_group") I like to use descriptive names ("..._null_group", "..._sdk_group", "..._spaceSwitch_group").
• ... (probabably more)

Credits

• I was introduced to the L and R prefix from Mark Feller at Studio Soi. At first I was not sure about it, but now I prefer it as well. 
• He is also the first rigger I saw that uses no suffixes / nodetype information for animator control transforms.

Implementation

To create/edit/access the naming convention I like to create a Python file/module with a dictionary that can be imported. I prefer this over any intelligent method from the past, because it just adds unnecessary complexity in my experience.

# this is the file naming_convention.py
maya = {
    # global
    'left':{'prefix':'L_'},
    'right':{'prefix':'R_'},
    # single purpose nodes
    'displayLayer':{'mesh':'MESH'},
    'set':{'bake':'bake_set'},
    # default nodes names
    'transform':{'suffix':'_group'},
    'multiplyDivide':{'suffix':'_multiplyDivide'},
    'mesh':{'suffix':'_mesh'},
    # special node names (from user)
    'control':{'suffix':'_control'}
}

The way of ordering the dictionary keys might change, since I just started using it.

# this is the code to use the naming convention
from naming_convention import maya as nm
print nm['left']['prefix']# Result: 'L_' #

prHeatDeformer

Description
I recently finished a heat/tension based deformer / Maya-API plug-in. Depending on the amount of squash and compression on the surface, vertices get deformed along the normal or with blendshapes. The most common application would be to blend in wrinkles on skin and clothing.

Motivation
To have an extra tool to improve deformation for many different types of rigs. I was also personally interested in the subject and to do something useful in the downtime between projects.

Video

prHeatDeformer - deformer (custom node) from Parzival Roethlein on Vimeo.

Breakdown
In total it took 15-20 working days (8-9 hours each) to get this plug-in to a production ready state. I roughly kept track of it, since my Maya API knowledge is still only a few months spread over a few years, so I would not do it at a company, if it would take me too long. But I guess since my old Maya API nodes were mostly deformers as well, that I am not terribly slow. I would expect a more experienced user to be twice or three times as fast and a beginner probably takes two to three times as long. Summary:

• I had not used the Maya API for over half a year, so I was a bit rusty at first.
• I always had to take a break when there was a project I had to work on. Which is less efficient for me than continuously working on it, because it always takes a bit to get back into it.
• The first 10-15 days were spent writing a complete Python API version. I implemented all features, with little calculation optimization. So far I always wrote a full Python version for my deformers first, because I wanted to learn both APIs and to avoid compiling during iterations. But I should probably stop now, since it seems like a waste of time. Especially because more difficult debugging is easier in C++ / Visual Studio, since you can set breakpoints and use "attach to process" for interactive debugging, which I used the first time on this plug-in
• After the Python version was working (and terribly slow) I wrote the C++ version in around 5 days. This was the hardest part, because I had to implement a lot of performance increasing stuff, so that the deformer does not slow down the rig as much. There will definitely be a geometry resolution switch for the animators, but I still want them to be able to see the heatdeformed highres mesh with decent speed and also when working with it as a rigger it is always better to have the deformer as fast as possible. To make the deform fully production ready it had to work with transforms that have any number of shapes and each shapes vertices can be inside or outside of the deformer membership. Combined with the speed improvements they were the most difficult things to get done. 
• I wrote a lot of common features for the first time (tangent space, smooth, grow, some of the speed optimizations). So that slowed me down. And will improve development time on future nodes.
• The Python version has 800 lines, the C++ version 1400 lines (including header file, comments etc)

Conclusion
In retrospect I was surprised how quickly it was done. Especially if I had skipped the Python API implementation. Because it is one of the more technical and difficult tasks in rigging, it also feels quite rewarding when you get it done.

Todo
Additional features and performance improvements

Related

• (2007) Siggraph 2007 presentation "Realtime wrinkles, Christopher Oat": This is the oldest reference I could find for this idea. The second half has "dynamic wrinkles" that are tension based.
• (2008 or earlier) The Maya (Comet) muscle skinDeformer has a "wrinkle" option included to the "relax" feature. It moves vertices along the normal vector when being compressed. This feature is not usable, because there is only one global attribute to control the strength and one paintable map. So there is no limit and no way to control the acceleration etc. And the biggest problem is that the algorithm does only work properly on primitive geometry (sphere,..) because it is only considering neighbor vertices that have continuous numbering (or a random one, if there is no proper neighbor id). This is a bit hard to explain, but the result on a production mesh is that it calculates the compression differently on neighbor vertices (except if you scale everything from the same pivot), so you get spikes and have no real control over the shape.
• (2010) fStretch: I think this is the most well known version of this technique. It is a commercial plug-in by Matthieu Fiorilli. It seems very sophisticated, but it is a commercial plug-in that costs money/effort and the license model is not so good for the place I work at.
• (2012) tenshionBlendshape: Inside of the SOuP plug-ins, it does not have tangent space, which makes it unusable and I also did miss some other features and the base algorithm also had some problems with different sized geometries. I did send them the feedback thou, so maybe some day there will be a usable free version of this technique.

Fish rig - Beck's Sapphire

The last project I worked on at Psyop. I was responsible for the rigging. If possible I will add a breakdown video later.
Update: Sadly it is not allowed to upload a breakdown / making-of for this project
Update: HD version on Vimeo https://vimeo.com/59246733

Beck's Sapphire | 2013 Super Bowl Commercial -- Super Bowl 47

prAttractNode

I never made an extra blog post for my prAttractNode. So since I just uploaded an update and also made a better demo video with more useful work examples (Read Vimeo description for explanation), I think it is a good time.

The plug-in is open source (download link in Vimeo description), so the following Maya API parts might be useful to others:
- How/Where to properly initialize a ramp attribute
- How to setup everything in a single .py/.mll file, for easy installation
- (C++) OpenMP usage (Extra blogpost: http://pazrot3d.blogspot.com/2012/01/openmp-and-maya-api.html )

prAttractNode - deformer (custom node) from Parzival Roethlein on Vimeo.

prSelectionUi updates

prSelectionUi - Animation UI (Maya) from Parzival Roethlein on Vimeo.

I recently updated the prSelectionUi quite a bit. The Vimeo video got updated as well, but since there have been new script updates, it does not show all new features. You can find the download link in the Vimeo description.

There is some background information in my old blogpost:
http://pazrot3d.blogspot.com/2012/03/prselectionui.html

Rig performance tips

A rig should always be as fast as possible to improve productivity of animators. It is also more fun to interact with a fast rig in general and maybe even allows for viewing the animation in realtime inside of the viewport. So there is no need to create a playblast all the time.

The biggest factor is the geometry resolution (lowres/highres/..) and the kind of setup the rigger chooses  Hopefully always balancing quality and speed. This is very project and people dependent. So I'm not going into that here. This post should just be a small list of things that always work and are not that well known (?):

• Remove vertices from the deformer, if they are not affected, with the "Edit Deformers > Edit Membership Tool". I almost always use this for lattice, wrap, wire, sculpt, .. There are probably cases for all deformers. This can also be achieved by only selecting the affected vertices when creating the deformer.
• Use few skinClusters by merging geometries. This should be used carefully of course, because it can be annoying to skin overlapping geometry (maybe skin multiple geometries and copy skin weights on the final merged mesh when publishing the rig) and other steps in the pipeline have to be considered as well.
• Remove unused influences from skinCluster. Use "Skin > Edit Smooth Skin > Prune Small Weights" before. Each influence costs a little bit of performance, so if you have multiple geometries that are skinned to all skinning-joints this can make quite a difference.
• Connections instead of constraints. A lot of point/orient/parent/scale-constraints can be replaced by simple translate/rotate/scale connections, if the hierarchy is setup in the right way (Maybe by creating an extra null-group to have the same local transformation values). BlendColor nodes can be used for blending. I think scaleConstraints are always the worse option, and can be avoided completely.
• Don't use clusters to deform curves. Instead use a skinCluster (use component editor to tweak skinning weights) or [Credit to Francisco Naranjo:] connect locatorShape1.worldPosition[0] into the curveShape1.contolPoints[x] attribute
• Delete unused Orig shapes. This does not effect the rig speed when interacting, but is about filesize, which increases file-opening / reference-loading time. Whenever you create a deformer, maya also creates an Orig shape (intermediate object). If you duplicate a geometry that had an orig shape, it will get copied as well, but ignored for future deformers. So it basically just increases the filesize with no benefits. You have to remember to delete it, or delete the history before you duplicate. (An easy shortcut-combination to select the orig shape: Arrow down (child), arrow left (latest child)