There’s a revolution in the After Effects world – a revolution of speed. Unless you’ve been living in a cave, you caught that VideoCopilot and Red Giant released some ridiculously fast OpenGL powered Plug-ins that promise to change the future for AE users. Moving from the CPU to the GPU is clearly the wave of the future, and that future starts now. Just in case you missed it, I’m talking about VideoCopilot’s Element3D and Red Giant’s Trapcode Mir.
I should also point out that Mettle beat most everyone to the punch with ShapeshifterAE.
I have not heard a lot of chatter about ShapeShifter, but it’s definitely worth looking at, no question.
So while VideoCopilot and Red Giant aren’t the first to release OpenGL Plug-ins, these two products are the first to show a promising future for fast rendering of 3D in AE for wide use in motion graphics and visual effects. I say this because they fulfill the following criteria – both:
- Are useful
- Are super fast
- Have a High adoption rate
- Are fairly stable (so far – time will really tell on this one)
Useful and super fast are great, but the one thing I would not trade speed for is for stability. There’s nothing I hate more then losing my work, or hitting render and going out to lunch, only to find out I crashed. So far, both of these plug-ins have been stable, and I’ve used them a bunch – Mir more than Element.
I also consider wide adoption as an important factor because wide adoption means the product has a good chance of standing the test of time – continuing to get updates and refreshes as needed. Also when you go from shop to shop, the same tools you know and love are always there for you because everyone’s got it – which means you have what you need to do your job. It also means it’s worth your time to learn how to use. Nobody wants to spend time learning tools they know that they won’t use.
I think both products have their pluses and minuses – and there’s always more that you want out of any product once you get started and become filled with ideas. But that’s the nature of doing what we do. What’s in there is never enough.
Regardless, it’s an exciting time. Here’s an example of something I did in AE last week, using Element 3D (first ship) and Mir (Terrain and 2nd Ship):
I want everything on the menu!
But now I’m spoiled. Some of my favorite plugins feel like a u-haul truck, now that I’ve been given a sports car. I’m betting you feel the same way too. You might even be asking “If OpenGL is so awesome, why aren’t all plug-ins just being ported to OpenGL? Can’t the engineers just write code to have the mathematics and algorithms passed to the GPU instead of the CPU?”
Good question. The answer is, unfortunately, no. It’s not that easy. I know this because I had the same questions, so I sat down to breakfast with a former head of DirectX at Microsoft who knows a lot about GPU.
It was an enlightening discussion, and, frankly, a bit above me – but I’m going to do my best to translate all of that into simple English, using an analogy. Any mistakes I make here are mine – not his:
The only man for the job.
Imagine you own a company with exactly one employee who does everything. He’s a generalist who can do a lot of things well enough. When you have a big complex project to complete, you have to lay out the instructions step-by-step. If the tasks are not done in the right order, it will all fall apart. And how fast that project gets done depends mostly on how fast your one employee can work. It’s brute force – powering through each task and moving on to the next, working towards an end goal. At the same time that he’s doing all of these tasks, this employee is also driving a car, talking on a phone with his wife, paying bills, and maybe having an argument over email with his son who insists on going to art school, instead of going pre-med. He’s carrying a lot on his shoulders, and there is only so fast he can work no matter how good an employee he is. This is CPU processing.
There is no CPU in TEAM (well, maybe).
Now imagine you have a whole team of employees who are specialized and dedicated to just this kind of project. How would you do things differently? Well, you’re first thought might be to just dole out equal amounts of work to each of them, and let them go to town. But that won’t work. The tasks have to be done in sequence, one at a time. It’s how the project was designed. So even with an army, they’d still have to march single file. Oh – did I mention they only speak french? Also, that first generalist dude keeps trying to do everyone else’s job, because no one has properly explained to him that he has to learn to let go, so that other people more suited for the job can get to work.
Thus the dilemma. Software programmed for a CPU doesn’t translate to the GPU platform (at least not well).
The solution, then, would be to completely redesign the project in such a way that it is targeted at the team of specialized individuals, instead of the one generalist dude. What must be accounted for is that the tasks can be done by multiple people and even have some that can even be completely dropped if an employee is out for his daughter’s dance recital (example: losing shadows or reflections when the gfx card does not support it). You also have to make sure the employees have good communication with each other so that they can work together. And sometimes, you even let that original guy (CPU) pitch in, if the team can’t handle a certain task. This is GPU processing.
So in short, to get OpenGL speeds, the plug-ins need to be re-written, mostly from scratch, with OpenGL in mind. It’s a major undertaking.
I kept it simple, stupid.
This is a major oversimplification and I’m sure I didn’t quite get it all right – but hopefully it helps you understand what’s going on. Some of you may also have noticed that I totally glossed over multi-core processors and hyper-threading. And CUDA (which until last week I was sure was a kind of cheese). Shut up. You’re ruining my already poor analogy.
If you are a GPU expert, I welcome your input. Otherwise I’ll go back to animating now. Thanks.