What is the technical difference between OpenEXR Depth and a Z AOV?
It’s been a while since this question was asked. I hope you’re still interested in the answer! (I have neither rendered nor used a deep pixel image, so the following is purely theoretical.)
A Z AOV gives a single sample of depth for a pixel. “This pixel is 12258cm from the camera.”
Deep imaging takes samples at multiple depths. Suppose you have a scene with a car driving through smoke. A single pixel might be made up of information from the smoke, with samples from many different depths contributing to the color; the glass of the driver’s side window; the glass of the passenger’s side window; more smoke; and finally whatever is behind the car. Each of those elements might have a sample in the deep image, allowing you to, for instance, put a tint on the windows that will not affect the color of the foreground smoke.
If all you have is Z, you couldn’t do a real depth of field blur on that scene because everything is locked into a single z sample (likely the driver’s window) and would be at the same depth. You’d have to render in layers instead: foreground smoke (with and without holdouts), exterior glass surface, car interior and interior glass surface, refracted smoke (to get the background smoke seen through the windows) and background.
Given how large a deep image can be, rendering in layers may well be more efficient.
Thank you for your reply, it is appreciated. But yes, I have already kind of figured this all out and started doing some implementation at work as well.
Unfortunately deep compositing volumes is a bit too slow for us to utilize as much as I’d like to.
From everything I’ve heard, I think that’s true all the way around. Deep’s a great idea, but the hardware’s not quite ready for it.
Hey, I was looking into deep compositing as well, for one of the animations I’m working on, so I’d like the scene to be tuned for deep if I do use it.
I understand the file samples are quite large but what do you mean by its slow? Does it take much longer to render each frame?
The rendering shouldn’t be too much slower. All of that information has to be calculated whether it’s stored or not. It’s mostly the I/O that’s a problem, from my understanding. If you have 24 sample planes, that’s 24x as much data having to go through your network or bus. And 24x as much data to be processed in the compositor. During render, that’s not as much of a problem because file writing is probably the smallest segment of your render time.
ok, cool. Thanks!