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.
Wednesday, August 18, 2010
Tuesday, August 17, 2010
More Python/Qt posts pending
After mulling over the matter of this pesky blog a bit more, I think I finally hit on a topic that will keep me posting semi-regularly, at least for a little while. Seeing that I'm learning all kinds of fun new things as I try to rework various Maya tools at Reel FX to use the Qt framework instead of Maya's own UI framework, I will do my best to share those discoveries here in the interest of helping those who may be traveling a similar path.
In my online searches to figure out this stuff, I've seen plenty of "generic" examples of how to use the various classes available in the Qt framework (and the PyQt module used to interface with it), but haven't stumbled across many that address the specific issues faced by Maya developers. I'd like to remedy that (or at least try to) in this blog.
While Qt offers so much more flexibility than Maya's UI tools, the level of functionality that I find myself trying to achieve in my first full UI conversion (which is about 80% done as of this writing) is that of simply matching Maya's existing capabilities. As inflexible as the default Maya UI tools are compared to Qt (speaking of the original MEL-based tools that have been around for so long), the Maya developers provided fairly easy access to a number of very useful features: popup menus, drag-and-drop, grouped radio buttons, widgets with attached labels, etc. I imagine that many pre-Qt developers who have been coding Maya interfaces for a while -- in either MEL or Python -- are probably at least a little bit like me, and have reached a point where these features are taken for granted to some extent. You may look at that list and say, "What's the big deal? Widgets with labels? Pshaw! That's standard!" Yeah, well it was a bit of an interesting revelation to discover that many of these features don't come auto-attached to most (if any) widgets in the Qt framework. The ability to use these features is all there, but it takes a bit more work on the front end to set them up. Some require very little work, while others require a bit more.
That's the kind of stuff that I'd like to cover here. In short, I want to do my best to answer the "how do I replicate [insert Maya UI feature here] using Qt?" question. That's what's been running through my mind over the past couple days, and I've made some interesting discoveries in my search for the answers. Generally speaking, it's fairly easy to match what Maya can do. However, the real fun begins when you realize how much farther you can go, and I'll try to offer some of those "go farther" tips as well.
As I've said before, I don't have an official programming background -- just a deep passion for problem-solving and tinkering. Most of this stuff is coming to me through trial and error, with a little help from the Qt framework docs and various web searches, so there may be hiccups in some of the stuff I present. If your experience has led you to do things differently, or if I just flat-out get something wrong, feel free to speak up.
By the way...did you know that the official pronunciation of "Qt" is "cute"? Before digging into it, I heard tons of references to "Q-T", but not one talking about it with its real name. Is it because it's a bunch of guys who have this thing with saying "cute" in the context of programming geekiness? Is it ignorance? A bit of both, perhaps? No matter. You can say it however you wish. As for me, it's "cute" all the way. :)
In my online searches to figure out this stuff, I've seen plenty of "generic" examples of how to use the various classes available in the Qt framework (and the PyQt module used to interface with it), but haven't stumbled across many that address the specific issues faced by Maya developers. I'd like to remedy that (or at least try to) in this blog.
While Qt offers so much more flexibility than Maya's UI tools, the level of functionality that I find myself trying to achieve in my first full UI conversion (which is about 80% done as of this writing) is that of simply matching Maya's existing capabilities. As inflexible as the default Maya UI tools are compared to Qt (speaking of the original MEL-based tools that have been around for so long), the Maya developers provided fairly easy access to a number of very useful features: popup menus, drag-and-drop, grouped radio buttons, widgets with attached labels, etc. I imagine that many pre-Qt developers who have been coding Maya interfaces for a while -- in either MEL or Python -- are probably at least a little bit like me, and have reached a point where these features are taken for granted to some extent. You may look at that list and say, "What's the big deal? Widgets with labels? Pshaw! That's standard!" Yeah, well it was a bit of an interesting revelation to discover that many of these features don't come auto-attached to most (if any) widgets in the Qt framework. The ability to use these features is all there, but it takes a bit more work on the front end to set them up. Some require very little work, while others require a bit more.
That's the kind of stuff that I'd like to cover here. In short, I want to do my best to answer the "how do I replicate [insert Maya UI feature here] using Qt?" question. That's what's been running through my mind over the past couple days, and I've made some interesting discoveries in my search for the answers. Generally speaking, it's fairly easy to match what Maya can do. However, the real fun begins when you realize how much farther you can go, and I'll try to offer some of those "go farther" tips as well.
As I've said before, I don't have an official programming background -- just a deep passion for problem-solving and tinkering. Most of this stuff is coming to me through trial and error, with a little help from the Qt framework docs and various web searches, so there may be hiccups in some of the stuff I present. If your experience has led you to do things differently, or if I just flat-out get something wrong, feel free to speak up.
By the way...did you know that the official pronunciation of "Qt" is "cute"? Before digging into it, I heard tons of references to "Q-T", but not one talking about it with its real name. Is it because it's a bunch of guys who have this thing with saying "cute" in the context of programming geekiness? Is it ignorance? A bit of both, perhaps? No matter. You can say it however you wish. As for me, it's "cute" all the way. :)
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:
Posts (Atom)