Thursday, November 9, 2006

simple dynamics in MEL

I've often wondered how to build an expression in Maya/MEL that would implement some simple dynamics. For instance, if I want an attribute to be dependent on an object's velocity, how can I get the velocity?

I learned yesterday that you can use the "keyframe" command within an expression to query for the value of an animation curve at a different time.
This isn't an ultimate answer, but it provides a good tool to getting closer.

So here's some code for determining the frame rate of change of an attribute. In this case, pSphere1's tx attribute.

// get the previous frame
$newt = frame - 1;

// query pSphere1's tx anim curve from that frame
$oldx = `keyframe -at tx -t $newt -q -eval pSphere1`;

// this is ugly, but it turns the array result into a float.
// someone please show me how to do this "properly"!
float $ox = $oldx[0];

// now compute the difference
$delta = $ox - pSphere1.translateX;

(and now for search indexing, since these are the keywords I was searching for to find this answer: velocity mel expression dynamics)

Saturday, August 26, 2006

ratOcclusion, or, the SL code I most wish to see

Over the past few months I've run into a number of bugs with the Pixar-supplied mtor/RAT occlusion shader "ratOcclusion". First of all, it has these crazy artifacts at small scales, and second, it gives me yet-to-be-understood white grid patches when the shading rate is too low, or the image is too big, or... well, that's the problem. I have no idea what these artifacts come from, I just know I hate them, and that I spent hours re-creasing the mtor subdivs in the film (yes, this is still about The Incident at Tower 37 project) when, in fact, the creases weren't the problem at all.

Anyway, I just put together my own occlusion shader that seems to fix these bugs. The hope is that it can be the show-wide occlusion shader, so I need to make sure it is fast. How my straightforward shader is different from what ratOcclusion is (under the hood) is a mystery.

Friday, February 24, 2006

Memphis, here we come

"Catch" just got picked for the Memphis International Film Festival, also happening this March. I'm very glad I got two prints, after all!

Tuesday, February 21, 2006

chronophage

A great new term came my way, courtesy (once again) of Dean Weisler: chronophage. Something that eats time. Like this blog, or any number of other things in my life.

I also threw down a new term yesterday in a written model critique: aquadynamic. Yes, I intended it to mean what it sounds like it means, and I kind of like it.

Not that anyone reads this, but if you do please share your new words/expressions with me. I'm always looking to make communicating more... efficient? fun? Maybe just different.
"Catch" is on the calendar now at the CIFF: March 18th and March 25th. It's a part of the "Family Shorts" program.

Wednesday, February 8, 2006

"Catch" finally will be seen

It's been a long time coming, but the Cleveland International Film Festival will be showing my short film Catch this year. And literally at the same time in March, it will be looping at a gallery show in RISD that's showcasing some UMASS MFA student work. Nice to have at least a small audience!

Friday, January 27, 2006

Career Q&A, part 1

I get career-related questions a lot. I've decided to finally start answering them in a public place so I won't have to re-answer them the next time I'm asked!

Q: What's your history in "the industry?"

A: I left the MIT Media Lab with a Master's degree in 1994 and took a programming job at Rhythm & Hues studios in LA. I worked primarily on animation software, supporting productions. After almost a year I moved onto a longer-term project developing a new animation system for R&H (my particular area of focus was the deformation system). After perhaps 2 years of programming I realized that my real reason for coming to Hollywood was to make pictures, not software, and R&H kindly let me shift from tools to production. I did some articulation at first, then moved into more general TDing activities ("TD" is short for "technical director," a blanket term for folks who, in general, use the software tools to produce images).

The TD life in that particular corner of the industry--visual effects work for a client--didn't sit too well with me. It was frustrating to work for an outsider who came in every few weeks and shot down the work you'd been cranking on hard since the last visit.

In 1997 I took a job at Pixar to work on A Bug's Life. At Pixar I hoped the "client" would disappear, and it basically did. Because the client was there every day, working one-on-one with me in the form of an Art Director, Designer, or the Director himself. So there were no longer any deflating reversals of direction. The filmmaking process was ongoing and I was a part of it, encouraged to contribute in my own ways where I could. I also was lucky that my direct managers were very friendly, helpful, and great at estimating how long something should take to do. As a result, on ABL I felt like I had enough time and support to do what was asked of me. In production, at least based on my experience up to that point, that was quite unusual.

After ABL I moved to Massachusetts, so I switched from production back to tools and telecommuted for a year to work on the (at the time) new deformation system. Everything was great about this setup except that I missed two things: the community of the studio and working on production. In an effort to try and reconnect with production in some form, I asked around at the local schools to see if anyone would be interested in letting me teach a once-a-week production course. Hampshire College happened to have a full-time visting opening and when Pixar said I could go on leave I jumped at the chance to try out teaching.

I've taught CG and animation at Hampshire from 1999 until now, and I've returned to Pixar 4 times during the summer/winter breaks for various exciting short-term jobs. 3 were related to Finding Nemo (early concept modeling, fish fin R&D, and then render speed enhancements), and the most recent (summer 2005) had me back in tools.

Q: How was working at Pixar? What was the work environment like?

A: Terrific. I was lucky enough to spend time both in production and tools (software) and I enjoyed both groups equally.

Production can be hectic but working on a big film, alongside dozens of talented people, is not like anything else I've ever done. I would dive in and focus on my part of the project, then show up in a review a few days later to find that (of course) everyone has also been working on their stuff! And it's all growing richer, more interesting, more complicated, more beautiful. Any team effort can be like this if you've got a good team, and I was always working with good people when I was in production there.

My most recent coding work in tools was co-developing the deformation software used for Monsters Inc. and beyond. Unlike production problem solving, I had time in tools to ponder/debate the "right" way of doing things, to work on the whiteboard, to meet and talk and read up and talk some more. Not infinite time, but enough. The needs were pretty clearly laid out, but the approach I would take to solving a particular problem was basically my own. It was a great environment to develop code in. Lots of brilliant engineers and, of course, a user base trying to make the most advanced CG imagery ever. I really loved working closely with production as a tools guy, both at Pixar and at Rhythm & Hues, because I enjoyed understanding exactly what production needed from a tool and trying to give it to them.

Q: Do the engineers get to be involved in the creative process at all?

A: There are many different kinds of engineering jobs at Pixar, ranging from the super-isolated, long-term R&D positions to what might be called "production support" jobs. This is a term I borrow from my first gig at R&H in 1994, where I was hired to do production support programming. At the time it was a job within the software group but a job which was completely determined by the needs of production. At Pixar these days, my understanding is that there are folks who do some level of software engineering from within the production. Same job, but different boss if you will. This is a simplification, but I think the work is the same: if the production needs something that requires programming work, you do it.

If you have engineering skills but want to actually create content for the films then you may want to consider the role of TD. There are TDs who are primarily artists, and there are TDs who are much more technical. A code-savvy TD will often exercise his or her coding skills to solve some form of procedural animation or modeling or shading or effects task for their production. Perhaps these new tools folks, working within a production, are also asked to take on these kinds of jobs. I'm not sure. But the point is there are many ways in which coding skills can be useful at a studio like Pixar.

Q: What do you think Pixar is looking for in Summer interns? What is the best way to get my foot in the door?
A: It depends on what kind of internship you want. I think Pixar's own web pages have some answers to these questions, but here's my short take:

Tools interns need to be good programmers with a demonstrable interest in CG. How you demonstrate those skills and interests is up to you, but a solid resume is a good start. Your cover letter can describe projects you've done, classes you've taken, and other experiences you have too. What parts of CG are you interested in? Make the answer to that clear and I don't think it would hurt.

Pixar has other internships too, such as TD internships. They may be posted with more specific descriptions (layout intern or shading intern, for example) which would help you know if you're a good fit or not. Once again, you need to make your interests and skills clear and hope/ensure that you're applying for an internship that you would be a fit for.

This advice applies to regular TD job applications too: know the job you're applying for and tailor your application for it.