Hi,
Found the script I sent a while back as an example of picking layers in
merges using up more resources.
Just tried it in 6.3, and I still get similar results.
Script attached for reference. Try viewing/rendering each of the two groups
while keeping an eye on memory usage of your Nuke
Thanks Ivan,
That's some really good info. I'll check it out.
Ryan
On Tue, Sep 6, 2011 at 2:06 AM, Ivan Busquets ivanbusqu...@gmail.comwrote:
Hi,
Found the script I sent a while back as an example of picking layers in
merges using up more resources.
Just tried it in 6.3, and I still get
Hi Ivan
The thing is in your slower one in red of your example your first
copying/shuffling everything to another channel before merging them from
their respective channels. The fast one there isn't any shuffling around of
channels first. Your going in the opposite direction(shuffling to other
Sure, I understand what you're saying.
The example is only bundled that way because I didn't want to send a huge
multi-channel exr file.
But if you were to write out each generator to a file, plus a multi-channel
exr at the end of all the Copy nodes, and then redo those trees with actual
inputs,
Or, to go even further and remove any differences between multi-channel vs
non multi-channel exrs, have a look at this script instead (attached)
Even when you're reading in the same multi-channel exr, my experience is
that shuffling out to rgba and doing merges in rgba only uses less resources
Recently I've been trying to evaluate the load of nuke renders on our file
server, and ran a few tests comparing multichannel vs. non-multichannel
reads, and my initial test results were opposite of what I was expecting.
My tests showed that multichannel comps rendered about 20-25% slower, and
Exr files are interleaved. So when you look at some scanlines, you need to
read in every single channel in the EXR from those scanlines even if you
only need one of them. So if you have a multichannel file with 40 channels
but you only use rgba and one or two matte channels, then your going to
I shuffled out the multichannel files for the contact sheet. Sometimes I
keep multichannel files directly on the b line, and do merges (eg. Plus
reflection over lighting) inline, which seems to be the most efficient way,
node-wise.
Shuffling out is more intuitive, and gives a more visual sense of
Sorry, no benchmarks yet. I started making a doc about exr to put up on
nukepedia that one day I will finish.
Ryan: are the exr files scanline or tile exr's?
-deke
On Thu, Sep 1, 2011 at 14:18, Dan Walker walkerd...@gmail.com wrote:
Hey Deke,
Could you elaborate on the last paragraph.
All exrs are zip1 scanline. We created the multichannels in nuke from zip1
vray renders.
On Sep 1, 2011 8:41 PM, Deke Kincaid dekekinc...@gmail.com wrote:
Sorry, no benchmarks yet. I started making a doc about exr to put up on
nukepedia that one day I will finish.
Ryan: are the exr files
10 matches
Mail list logo
