(Rigging Tips and Tricks : Making of Pose Critter by Timm Wagener)
August is off to a great start here at Rigging Dojo and we are very excited to have a great guest blog post on this months Rigging Tips and Tricks, Timm Wagener presents the Making of Pose Critter. If you haven’t seen his work or Pose Critter before, it is a very dynamic and cool animation pose saver for Maya.
Timm kindly wrote up a behind the scenes on the making of this great tool so we could share it with all of you. Enjoy!
Begin Guest post:
Hi, my name is Timm Wagener,
I’m currently a TD student at Filmakademie Baden-Württemberg, where I just recently finished the work on the upcoming FMX 2014 trailer. For this project I served as the only pipeline and rigging TD and additionally supported the Lighting/Shading TDs as much as possible. My main focus is on pipeline programming, rigging as well as lighting/shading.
I originally started with 3D because I wanted to build my own levels for games like Half-Life and Unreal Tournament. I never really played any games, I spent all my time in their editors like Valve Hammer Editor or the UDK. As games became more detailed I had to learn 3ds Max to create assets for my levels. I did that as a hobby along high-school, which earned me an internship in the 3d art department of a game company right after my A-levels where I learned Maya on a production level. After the internship I was sure that 3D was my career path but I wanted to switch from games to animation for two reasons:
- Around this time I saw all the movies that especially the French animation students where putting out (I think “Burning Safari” pulled the trigger), and I thought that this is exactly what I want to do.
- At this time working for a real-time engine still meant to overcome lots of limits.
So I made my B.A. in Digital Media at the USC Darmstadt focusing on the technical aspects of 3D animation. I paused that 3-year program for a practical year in the industry which I spent at a local animation studio called WeCanDance and at BUCK LA, which was an extreme boost (maybe better than 3 years of bachelor studies).
After that I decided to either start working in the industry as a Maya Character and General TD or do my Master at the TD program of Filmakademie. Luckily I was picked at Filmakademie where I now enjoy the opportunity to work on student productions that reach a wide audience and dig deeper into my areas of interest which right now are programming with Python and C++, parallel computing and Houdini.
I really like the fact that the field of Rigging has so much intersection areas with programming. Be it writing auto-riggers, a custom animation GUI or custom deformers. For the FMX show I spent about 60% of the rigging time within sublime and only about 40% within Maya itself doing hands on rigging.
About 70% of the rigs of the characters were automated with a custom written modular auto-rigger. I also wrote a custom roll deformer as the base for the rig of a chrystal that is the main character of the show and spends much of his time rolling around.
As opposed to many other TDs at the Academy I don’t have a BA in IT, which is usually an acceptance criteria according to their homepage, but rather have an artist background. (Although I have a formal education in OOP programming and databases since IT was my main focus in High-School).
I feel like that artist background provides me with valuable hands on insights in the production process that benefits the pipeline decisions i make and the tools i write a lot.
Apropos tools, the reason why I’m writing this is because the guys of Rigging Dojo invited me to do a guest blog post about my attempt at a pose library, called PoseCritter. So enough about me now, let’s move on to something that’s actually interesting 😉
When I started at Filmakademie, I had a short period of time until the production for the FMX trailer started and the animators in my room where just starting the animation blocking phase of their diploma project. Since they were not truly happy with the usability of their MEL based pose library, I thought it would be a great opportunity for me to dive a little deeper into PyQt and try to write a pose library that provides a nice interface and focuses on usability.
There were several criteria I wanted to meet:
- I wanted to strictly separate the functionality of the UI from the functionality of the DCC or the database, in an effort to keep the codebase clean and be able to make ports amongst python enabled applications relatively easy.
- I wanted to use databases over scene embedded data storage or .xml files. ( Although I don’t think that one is actually better than the other, they all have their advantages and disadvantages).
- Ensure a pleasant user experience by a friendly ui and easy accessable and exchangeable data.
Having stated these points, I started programming. For the UI I used QtDesigner and the double inheritance approach for on-the-fly conversion of the xml ui data with uic.loadUiType(). It allows for maximum flexibility, since you don’t always have to convert files with cmd tools like pyuic4 manually. Also I went with using resource files as the base for images and graphics that I used.
To my wondering PyQt doesn’t come with a flow layout which automatically puts any widgets in the next line below, once the parent widgets maximum width is reached, but there are a few implementations that are subclassing from a basic layout to be found online. I needed this as the layout for the pose buttons view.
One decision that is more of a design thing than a science was to use the little purple bugger I had lying around as some sort of identification or mascot for the tool. In order to do something for the usability, I felt like this would be a nice little thing to please the artist with a little color and some happy madness when he opens the tool.
I then started with the database functionality module and created the basic functions to set, get, update and remove data. I used the sqlite3 database module that ships with Python and serialized the data I retrieved from Maya with Python’s pickle module in order to store them in the database.(I think cPickle is the equivalent direct c built-in extension that is a little bit faster). Just as a side note, the ability to serialize data that easy is a really powerful option to store any information on Maya nodes as a string attribute. If you have a lot of (meta)data in Python structures such as lists or dicts that you would like to associate with a node, you can just pickle it and store it in a string attribute. (There are limits to what can be pickled but for much of the usual metadata it should be fine.).
For the actual retrieval of the data from Maya I wrote a maya functionality module. If I was to port the tool to, lets say Houdini, this would be the only module that would needed to be replaced. (Amongst a few tweaks in the main ui module).
Since I started scripting for Maya, I never used anything else than PyMel. Apart from the early days, where some plugins like VRay (up to version 1.5xxx) or Furryball had problems with PyMel, I never encountered any issues. Its object oriented approach using PyNodes, which in addition to wrapping Maya cmds and MEL exposes API functionality in an easy way , is just so comfortable.
The last module that belongs to the tool is the poseButton module. It’s a subclassed QWidget, customized to hold specific objects like a setPose or deletePose button.
One of the things that are most valuable when developing such a tool, from my perspective, is good artist feedback. When you are programming you most probably have a programmers view on the product and sometimes its pretty astonishing how different an artist approaches the interaction with the tool in the daily workflow. Therefor it might be a good idea to involve them as soon as possible, to ensure you are developing something that’s actually of good practical use. For PoseCritter I can say that, although the tool is still in beta and its development is currently on hold, there would be some real show stoppers in it, if there wouldn’t have been animators discovering them while testing it against their production workflows. In theory that can be a total win-win situation since they get a tool which perfectly fits their workflows and you are probably save from a lot of embarrassing mistakes when releasing it to the public 😉 (There are still some total bummers in PoseCritter, remember its still beta and its development currently on hold, but at least I know them know and will fix them when I carry on developing it……….just saying it in case you dare to look at the code :D).
With that, I will conclude my little production report on PoseCritter. I hope you could get something useful from it, if there are any questions or if something is unclear leave a comment below.
You can download the tool and have a look at the code here:
A small video, showing it in action, can be watched here:
If you would like to know who steals my time from developing PoseCritter..…he’s French, and he likes to solve cloth (hopefully soon in parallel on the GPU):
If you feel like having a look at my website then visit:
Add me in LinkedIn:
Last but not least I want to mention that I learned a lot from dedicated artists and TDs that take the time to create tutorials and spread their workflows and techniques.
And a big thanks to the guys from Rigging Dojo for inviting me to do a guest post here!