Monthly Archives: October 2003

Porco Rosso

Earlier this week, the brand new English dub of Hayao Miyazaki’s Porco Rosso was screened at the Paramount Theater as part of the Austin Film Festival. I bought a full pass to the festival to make sure I wouldn’t get cheated out of seeing this film, and I thought I could catch a few other films and the pass would pay for itself. No luck, I haven’t made the time to see any other films. But who cares. This is Miyazaki for crying out loud, and the only chance to see it on the big screen before it hits DVD next year.

As John Lasseter said on some of the Miyazaki’s DVDs: “You are lucky. You get to see (insert great film here).”

The film was fantastic, and the audience loved it. Funnier than his other films, but also with that sincere Miyazaki touch — beautiful sky scenes, not afraid to pause and appreciate a moment.

Cindy and Donald Hewitt answered questions afterwards. They did the English dialogue for Porco Rosso and also for last year’s Academy Award winning Spirited Away. Sounds like they enjoy working on these films, even though they have a short time to get the screenplay done (2-3 weeks). They are also playing a bigger role in directing the voice actors.

To see how potential voice actors will fit the part, they use Final Cut Pro to take audio clips from other movies and play it over the animation. When working on the English version, they just practice the dialogue while watching the movie, trying to get the lip sync right (lots of rewinding). They use the direct translation and also other existing dubs as a guide.

Miyazaki’s next film, currently in production, is Howl’s Moving Castle.

Rustboy book

My copy of the Rustboy book arrived the other day. It is an incredible achievement, one of the best “making of” books I’ve seen. Like the upcoming film, it was put together by one guy, a Mac with off-the-shelf software, and some good design sense.

Much of the book contents can also be found on the main Rustboy web site, but there is new stuff in the book too, plus some great insight. And hey, it even comes with 3d glasses.

I only hope that he can finish the film itself relatively soon. Yesterday I caught myself saying that he would never finish it at this rate, or that it would take 5 years, but the truth is that I can see it being completed in another year or two. My only concern is that the story might not be strong enough to engage an audience for 25 minutes, but his work is beautiful so it hardly matters. And he has been such a perfectionist up to this point, it’s better to give him the benefit of the doubt.

Hackers and Painters

Paul Graham’s Hackers and Painters essay surprised me. I put off reading it for months, because I assumed I knew what it was about — that programmers are artists, that their work today is just as important an art form as that of painters during the Renaissance. And sure, there’s some of that in there, but that’s not really the point at all. By looking for patterns between two seemingly unrelated subjects, Paul attempts to better understand the strengths or weaknesses of different approaches to programming. In the process I think he also defines what a hacker is — a tinkerer, a designer, but also someone who jumps in and starts coding. Not all programming projects should be tackled this way, and that’s fine too.

“If universities and research labs keep hackers from doing the kind of work they want to do, perhaps the place for them is in companies. Unfortunately, most companies won’t let hackers do what they want either. Universities and research labs force hackers to be scientists, and companies force them to be engineers.

“I only discovered this myself quite recently. When Yahoo bought Viaweb, they asked me what I wanted to do. I had never liked the business side very much, and said that I just wanted to hack. When I got to Yahoo, I found that what hacking meant to them was implementing software, not designing it. Programmers were seen as technicians who translated the visions (if that is the word) of product managers into code.”

Old life drawings

The human figure is complicated and beautiful and impossibly hard to draw well. If you can master it, the quality of the rest of your work will improve. When I have time, I go to an open life drawing session on Saturday mornings to practice. I don’t have anything recent scanned in yet, but here is some stuff from a few years ago (nudity).

For some people, drawings appear to just flow off their pencil. They’ve also usually been carrying a sketchbook their whole life. For others, it is a constant struggle to improve their drawing skills. When I was young, I fell into the former category. But right now, it’s work, and I think it will take drawing regularly for a few more years for it to become easier. On the other hand, fighting over a drawing or piece of animation (and winning) is good too.

Richard Williams, animation director for Roger Rabbit and author of the excellent Animator’s Survival Kit, writes:

“I’ve never understood why some people in animation are so desperate to save work. If you want to save work, what on earth are you doing in animation? It’s nothing but work!”

Kelly is an animation student beginning her second year at CalArts, and writes one of a handful of LiveJournal weblogs that I’ve run across. I think she would agree with Williams, but she says it as only a passionate student artist can.

“I wanna be struck by my unknown story with anvil force, thrown against the wall by more than I can handle, smashed and lightheaded on concepts I don’t understand but must master, and grinding my pencil through my desk as I carve the lines of the living character into the paper. I want it to be messy and painful. Because there lies the beauty.”

Me as an animator

Most people who know me know that I’m a big fan of animation. There’s a great potential in animation to create stories and characters that move the audience in ways that are impossible in live-action. Many considered it the art form of the 20th century, but in the aftermath of Saturday morning cartoons and outsourcing to cheap labour in Asia, it is rare that audiences get a glimpse of what animation can do.

In addition to being a fan, I’m also something of an animator by night, working on a short traditionally animated film. I’ve been working on it for about a year, a few hours a week, in the evenings when time permits. (Often, it hasn’t.)

Lately I’ve found myself talking about this more frequently, so it seems the right time to expand the coverage of this weblog to include some of the things I’m working on. Mainly as a chronicle that I can come back and read later.

Here’s a little sketch I made last night while doing thumbnails (a quick way to explore the key poses for a scene before animating). As I get further along with the film I will post some storyboards, production stills, and pencil tests.

Wheee!

Doubting Cocoa

TidBITS, iMovie 3 Tips and Gotchas:

“Although the program introduced a number of welcome new features, performance was sluggish, the program crashed for no reason, and exporting data was problematic. iMovie 3 had become the new Word 6 (for those who remember that giant step backwards).”

I still wonder about performance sometimes. Why is iCal so slow anyway? And why is the rewritten-in-Cocoa iMovie 3 slower than iMovie 1 and 2? No doubt that it is design decisions more than the language or framework that makes an app slow. OmniOutliner and Keynote are two examples of fast Cocoa apps.

I spent several weeks last month working on Cocoa experiments — small test applications and new features in a Carbon application. It’s clear that the Cocoa framework is very powerful. If I started a new application from scratch I would probably use Cocoa, but for an existing Carbon application the choice is more difficult.

Look at apps like iTunes. It’s still all Carbon, even the new music store. Or Final Cut Pro. These are some of Apple’s best apps. Not to mention Photoshop and Illustrator. Why should I abandon Carbon if it produces apps like these?

And there’s something else: I trust the Carbon team at Apple. They know the Mac better than most — not just the APIs but what it takes to build solid apps, and what the essence of Mac UI is all about.

I need to think about this more. Contrary to my previous post, mixing Cocoa and Carbon windows in the same application is problematic. Window focus doesn’t always work correctly, and dealing with menu commands in two different ways complicates the app. A better approach would be to stick with one framework for the UI (Cocoa or HIToolbox), and mix-and-match Cocoa and Carbon as needed under the hood.