Richard Lewis Takes On the Pipeline
RL: Yeah, probably you don’t. You need to first know what your utilization is, the mix of applications, your average jobs per host, and what’s your average render time, those kinds of things. Our software has a database and we collect all that. With a lot of charting built-ins you always know those things and then you can make intelligent informed decisions.
Do I need more software licenses? Was that why my render pending load was bound? I didn’t have enough RenderMan licenses? And you can say, “Look, our render pipeline is bound by render licenses not by available hosts, or I have plenty of render licenses, but not enough available hosts. Maybe we should use our desktops at night before we go buy a bunch more.” It’s just business metrics. So business intelligence is really kind of the next phase. I remember when Troy [Brooks], my co-founder, left Square, went to work for Electronic Arts and got involved in game pipelines. You know [back then], game pipelines were just sort of one year. Just build a team, build a game, ship it for Christmas, tear it down, start over.
There was no saving of assets. There was no sharing, no information, no one shared resources. He used to say that if render pipeline efficiency was kind of a five game pipeline, they’re about a minus three. It was the Wild West. But back then, the game revenue was so crazy, it would just matter to get that thing out the door on time. We don’t care about efficiency if it’s pretty profitable. But, over time industries mature and you get competitors and eventually it does matter to do it efficiently. Visual effects still, honestly, we’re still really not there. Our selling point is you should really do this as efficiently as you can. But it’s not on the top of everyone’s list. Payroll and artist compensation, as always, that’s the cost of a visual effects business.
But consider this. [As an artist]First I’m going to think about something, then do something, drawing or making something on a computer in 2D or 3D.
Then you render it, so you can see what you’ve done. Then you review it with your boss or peers or someone, then you think about it again and then you redo it again and then you re-render it. Well that cycle, that creative iterative loop, is unique to computer graphics. If you are sculpting something, you whack it and you just step back and review it. There it is. But on a computer, you’ve got to process these frames.
So there’s a whole process to it that goes in your production tracking system schedule. There is a daily so the right people can review it with you and sign off on it, and then you can go back, think about it, and review it. But over time that rendering piece keeps getting longer because you’ve added characters. Now there is skin on them, now there's cloth, now the background is in, now our lighting team has done their work and that just keeps getting longer.
You’re compressing the amount of time to review, re-think and redo. So even if you keep the same amount of work and you are okay with all the infrastructure you’ve got, by putting in a more efficient render pipeline, you’re going to decrease the render piece of that iterative loop and you will increase the review, re-think and redo time. So the work quality goes up.
DS: It just provides that much more time to qualitatively assess and redo the work rather than waiting for it to render...
RL: That’s right… And you will accomplish more on iterative loops. So if I can revise it 36 times instead of 24 it’s going to be a lot better. Or studios and customers can take more work so they can do the same 24 iterative cycles, but now they can do an entire other job. That means a lot more revenue for those same people.