EXR output from VRay

[TimForbes]

I have noticed that EXRs output from Maya with VRay are really slugging Nuke where as EXRs output from mental ray have not seemed to have this issue. This seems to have been an issue when either scanline or default compression are chosen with vray. Has anyone else noticed this or is there a reason for this?
Cheers,
Tim Forbes.

[vlado]

Use the "exr" output option instead of "exr (multichannel)". The multichannel .exr files are tiled .exr files and nuke processes them slower.

Best regards,
Vlado

[cpnichols]

What I had done for a long time was to output a vrimg file then convert it to an EXR, then discard the vrimg. I used the vrimg2exr util that comes with Vray. The converter allows you to do a scanline, compressed, multichannel exr output. Works great in Nuke.

Otherwise, it will write out the exr as it renders (in the same way as the vrimg) which is cool because it will save you memory in the frame buffer.

[jasonhuang1115]

Hi,

I just found this thread while searching for rendering Scanline ZIP compressed EXR out of Vray for Nuke.
In Maya 2011 with build 12435, I saw the Scanline ZIP option for EXR compression. Is this setting applied to multi-channel EXR or just the single channel EXR?

Thanks,
Jason

[vlado]

It is applied to both, however tiled files remain tiled (even though the compression is scanline-based within each tile).

Best regards,
Vlado

[jasonhuang1115]

Thanks, vlado. I will use the vrimg2exr utility to convert the EXRs.

[griml0ck]

If you do have to use multiChannel EXRs I would recommend reRendering them in nuke. Just do a simple filein and fileout to EXR with default settings. We have noticed speed increased up to 20x. But I usually don't use multiChannel EXRs anymore, comps feel faster without.

[jasonhuang1115]

Yeah, I spent some time trying to use the vrimag2exr utility last night, but it kept failing out during the scanning process. Not sure if it has to do that my multi-channel EXR has 160+ channels in it. Finally, I just went to Nuke and re-render the sequence. The difference in loading speed is HUGE!

[djx]

slightly ot, but I have to ask... 160+ channels? wow! If you just hit "play" in nuke when viewing the read node what fps to you get? I'm asking because, like griml0ck mentioned, I get better performance in nuke if if use single channel EXRs. I end up with more read nodes, but I'm only reading the elements I actually use. But I'm still working out what's the best workflow, so I'd be interested in your experience.

[jasonhuang1115]

slightly ot, but I have to ask... 160+ channels? wow! If you just hit "play" in nuke when viewing the read node what fps to you get? I'm asking because, like griml0ck mentioned, I get better performance in nuke if if use single channel EXRs. I end up with more read nodes, but I'm only reading the elements I actually use. But I'm still working out what's the best workflow, so I'd be interested in your experience.

Hi, David,
The 160+ multi-channel EXRs indeed are refreshing with very low FPS as scrubing through the timeline. I don't know how to measure the FPS, but it is nowhere near interactive, plus that for now I only render the every 5th frame for testing purpose. I need to process the data contained in every single channel downstream all at the same time but the reason I did't go with 160 single channel EXR is simply that I don't have to manage 160 read nodes, and that's that. Maybe I will try 160 read nodes at the end if that speeds up the process.

cheers,
Jason

[djx]

If you need all those channels at the same time, then I'm gussing the overhead of 160 read nodes might actually be worse than 1 160 channel file. Please let us know if ever you do compare.

[jasonhuang1115]

If you need all those channels at the same time, then I'm gussing the overhead of 160 read nodes might actually be worse than 1 160 channel file. Please let us know if ever you do compare.

Hey, David,

I finally got a chance (actually kinda forced) to output 100+ EXRs to swap out the multi-channel EXR currently used in the comp tree. And the result is SUPER SLOW!!! All the 100+ EXR are already re-rendered thourgh Nuke to make sure they are all 1 scanline ZIP compressed EXRs, but still I can see the yellow processing lights shining through the comp tree back and forth and a 640x360 image will take at least 4 minutes to see the final result whereas the original multi-channel EXR (100+ layers in it, re-rendered as 1 scanline ZIP compressed too) took not even a second.

cheers,
Jason

[djx]

Very interesting. I'm wondering if the thumbnail generation for those read nodes might be part of the problem. I read about a way of forcing an unchanging one-frame thumbnail. I should do some testing myself. Thanks for sharing your discoveries.

edit: Actualy something I did notice was that single channel exrs straight from vray (ie not using the multichannel format) load quicker in nuke than the same file re-rendered by nuke!

[jasonhuang1115]

You are welcome. Thanks for bringing up the thumbnail idea. It could be the reason, but I didn't spend much time investigating why it was so slow. I switched back to the multi-channel setup almost right away. My test might not be of a good reference though as there are no complex manipulations applied to each layer of the EXR, either them as a EXR itself or part of the multi-channel.

[aweidenhammer]

Reading with the obvious curious question of what you are doing with 100+ channels. Seems that's yer problem right there

Andrew