From boxes of IBM cards to animation on websites.
It’s easy, if you’re my age, to be very excited about the speed of the new generation of multi-core processors and about ever-increasing Internet bandwidth. Hey, I started out writing programs on punch machines that spat out boxes of “IBM cards”. A medium sized program might need a wheelbarrow move it around. We ran our programs on computers that cost hundreds of thousands of dollars, and if we were lucky, we could squeeze in a half dozen compile-and-executions a day. There was, of course, no Internet, and dialup technology was brand new.
I’m maybe the zillionth guy to brag about his experience with walking-to-school-in-ten-feet-of-snow computing technology. But here’s the subtlety. Faster and faster processing and data movement is more than a convenience. It does more than gradually increasing the ease of getting computing jobs done.
There’s always another hurdle.
That’s because every now and then things get fast enough that something that was totally intractable in the past is now quite doable. Managing multimedia on the Web is one such thing. It seems like we’re almost there. Soon, we’ll be able to stream large videos over home Internet connections. We’ll have “real” animation on websites, not just choppy Flash stuff. We can already edit video on modest desktop machines. We can install large scale server-based database management systems – and have them run just fine. Soon, many folks believe, we’ll be able to edit huge pieces of media online and search large server-based media databases effectively.
But just as we pass one horizon, we see a new, higher one out ahead. It’s tantalizing, thinking about the things we can’t do yet, things that we’re not completely sure we’ll ever be able to do.
Here’s one. Rendering.
I teach 3D animation. I like to experiment with new applications and introduce them to my students. Lately, I’ve been looking at a rapidly growing class of photorealistic renderers that can turn vector-based 3D Google SketchUp models into images that look like photographs, and in fact, beautiful photographs. These renderers simulate the complex movement of light as it reflects off of and refracts through objects like glass and car paint and swimming pools.
In past entries of this blog, I’ve written about the explosion of animation tools and the the teaching of animation. Desktop animation applications do tend to demand multi-core processors, several gigabytes of memory, and reasonably high end video cards. But machines with such components are now cranked out routinely by Apple. PCs intended for game playing make excellent home and small office animation engines.
Except for rendering. It’s that process that takes twenty or thirty frames per second of animation and cranks out video that looks super-real. That’s the bottleneck. I teach Maya. My students often find that their two minute videos can take hours or days to render. Two things in particular can cause render times to explode. Particle dynamics, used to simulate things like fire, is one. The other is rendering. Simulating light and its movements is computationally intense.
I use a product called Maxwell as a plugin to Sketchup and Maya. One beautiful frame – and remember, that covers maybe a twentieth of a second of video – can take an hour on my several-core Apple iMac.
Imagine the day when it takes fractions of a second.