Monday, August 16, 2010

The latest goings-(Pyth)on

Now that animation has wrapped at Reel FX on both Open Season 3 and the three Wile E / Roadrunner shorts, I'm back to updating the animation tools. While I was able to do a little development during production, it's tough making big changes for various reasons. With things flowing a bit slower now, it's nice to finally have the time to tackle some long-overdue to-do items.

One particular programming puzzle piece that I've been half dreading, half eagerly-anticipating is Qt. For those not in the know, Qt is (in the words of its current developer, Nokia) "a cross-platform application and UI framework." With the popular PyQt module that provides an interface to this framework for Python users, its use in the development of tools and interfaces for CG software has grown immensely, just as Python's use has grown in the same field.

The TD team at Reel FX has been steadily pushing farther into Qt development over the past several months, but production demands pretty much kept me from taking a serious look at it until last week. After just a few days of play, though, I'm already a fan/convert/addict. Just as Python is so much more versatile than MEL, Qt's UI tools are WAY more versatile than the UI tools provided by Maya. My mind is reeling with so many ideas of how we can significantly upgrade our animation tools to take advantage of the versatility provided by the Qt toolkit. While I'm far from an expert at it after only a few days, I've managed to conduct several successful tests of greatly enhanced functionality for our character GUI system, and can't wait to overhaul the whole thing and put the new pieces in place.

The only hitch is that getting Maya set up to use the Qt framework takes a bit of work, at least if you're using Maya 2009 (which we still are for some recent projects). While the folks at work have taken care of that already, and we are already using Qt for a greater number of internal Maya tools, we have several tools that are also used by remote animators who are hired to help us with various projects. By relying only upon the toolset within Maya up until now, we've been able to minimize the setup hassle for remote artists. If we suddenly ask folks to also go through the necessary steps to get Maya and Qt talking, we'll likely run into some problems, and that kind of remote support is something that we're just not prepared to handle.

This means that until production switches to using the later versions of Maya that have built-in Qt support, it's going to be difficult to justify spending much time on the tools that are used by both internal and external animators, which is just a tad frustrating. However, there are plenty of internal-only things that can be upgraded, which will give me time to become more familiar with Qt's idiosyncrasies.

On a somewhat-related note, I've taken on yet another side job. This one's more informal, though, but it also involves Python. One of my friends owns a dent-repair business, and he approached me a few weeks ago asking for help with something that will perform a bunch of calculations and track certain information related to the jobs done by him and his team members. Originally he wanted to do everything in a spreadsheet, and in our initial meeting we came up with something that worked fairly well after a couple hours. However, as my friend came up with additional features that he wanted for this system, it quickly became apparent that while it's certainly possible to do the whole thing via spreadsheets, in the long run it would be too much of a headache. I've been wanting to try my hand at standalone development for a while, and this looked like the perfect opportunity. To keep deployment simple, I plan on using Tkinter for the program interface, and will pack the whole thing up using py2exe. While I've only put a few hours into it so far, my experience with Python development at work is helping immensely. I could not imagine tackling something like this in my early Python programming days.

I hope to put out some more posts in the coming days/weeks with some further Python programming thoughts, but only time will tell if it actually happens.


David Martinez said...

Hey Justin,

It is great to see that I am not the only one getting into QT right now.

I have done a few tests with QT as well but using MEL instead of Python. I can see a great potential on using the new technology as well as being able to use the QT Designer at least as a base for the interviews.

Have you tried to create controllers that are not supported by Maya in your interfaces? If so, how did you connect them with Maya. I have been able to get their values if I connect them in the QT Designer to another kind of controller that Maya recognizes but I just feel that it is a dirty way of doing it.

On the other hand, I am also getting a lot into Python and I plan to re-write most of my scripts to Python.

Good luck on your standalone project. Let us know how it goes.

And don't stop posting about tool development either. You may not have a lot of comments on those but that doesn't mean that we are not reading!

All the best,


Justin said...


Thanks for the comments and encouragement. I haven't used the Qt Designer yet, so I can't speak to its abilities. While I can certainly appreciate using such a tool to lay stuff out, there's a large part of me that prefers to get my hands dirty by coding everything from scratch. I've always been that way, and don't know when/if I'll ever change from that path. :)

What exactly do you mean when you talk about "controllers that are not supported by Maya"? This may be a MEL-only issue, as I have yet to encounter any real problems with designing Qt interfaces in Python.

I'll certainly do my best to keep the comments flowing! Cheers!


David Martinez said...

Hi Justin,

I can understand the thrill of coding the interface instead of using the designer. I also think that you will have more power over the interface if you code the whole thing instead of using the designer.

I haven't tried to do any interfaces with Python. I've just used MEL so far.

After looking for some information about QT in Maya, I found a few tutorials and articles and they were enumerating how to access some of the controllers created with the designer. I have noticed that some of them were not accessible using MEL so they end up connecting those to other controllers that MEL can handle. They did that connection with the QT Designer as well (In something similar to the connection editor in Maya).

I will try to get into interface creation using Python to see if there is a way to avoid the problem.

Thanks for the heads up!