Before digging into the meat of the Maya-to-Qt discussion, I should probably cover some basics first.
Software Versions
Because all of my Maya/Qt work is currently happening at Reel FX (as I still don't have a current version of Maya at home for various reasons), everything I do will be based on the software versions installed at Reel FX. As of this writing, we're using PyQt 4 with Qt 4.4.2. Most of my work at this point is with Maya 2009. While we do have later versions available, and I may make occasional reference to idiosyncrasies in those versions, assume for the most part that this is all happening in Maya 2009.
Installation
One thing that I definitely won't talk about in these posts is how to install either Qt or PyQt, or how to get PyQt conversing with Maya in versions prior to 2011. I'm avoiding that hurdle largely because it was cleared for me by the folks at work, so I don't have any hands-on experience to share in that regard. If you want, head on over to Nathan Horne's blog, where he has kindly shared some packages that he put together to make the PyQt installation process a little easier. I haven't personally used those, though, so I can't offer any comments on their effectiveness.
Code Content
While the code samples that I list will be (ideally) fairly complete, I may only present partial code pieces here and there, partly because I'll be pulling some of these examples from actual stuff I'm doing at work. Those omissions are not only to address code-proprietary-ness issues, but because of some customizations that were done to unify all of our Maya/PyQt development at Reel FX. Just be aware of that in case you copy-paste any code samples that you find here. I'll leave in the essential stuff like imports, naturally, but some other parts won't be there.
I think that about covers it. In the first post (coming soon), we'll take a look at Qt's signals and slots, and then delve into meatier UI topics from there.
Showing posts with label Qt. Show all posts
Showing posts with label Qt. Show all posts
Wednesday, August 18, 2010
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.
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.
Subscribe to:
Comments (Atom)