I recently finished a deformer / Maya-API plug-in that I wrote at Psyop. It is heat/tension based deformation. So 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.
To have an extra tool to improve deformation for many different types of rigs. I was also personally interested in it and only worked on it between projects, when I had nothing else to do, so it seemed to me like a good use of my time.
prHeatDeformer - deformer (custom node) from Parzival Roethlein on Vimeo.
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 also deformers, 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. 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)
In retrospect I was surprised how quickly it was done. I always thought it might not really be time efficient to write Maya deformers at a small company. But for this case I actually think it even would be worth it, if there was just one user (me), since it is so easy to setup and applicable to most characters/creatures. And because I only worked on it in the downtime and there are around four riggers at Psyop I can definitely say that it was worth it (and I had a blast writing it of course).
Additional features and performance improvements
- (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.