Three Write Nodes - Rendering Once?

[macsepp]

Hi!

I'm a little bit confused about the way Nuke handles Write Nodes, especially when there are for example 3 at the end of the comp. One DPX, on Jpg Full Res and a Jpg Half Res or whatever...

Nuke seems to render three times the whole comp instead of rendering to the last node right before the 3 write nodes and then just save into the different formats like Shake would do.

The first comp we tried looks like one would do in Shake. End of Comp, branching into 3 different FileOuts or Writes.
We also tried to put them one after another which to my logic then should result into ONE branch and the following order: rendering - writing dpx - writing jpeg full - writing jpeg half. But it just handles it exactly like the first version.

Buffering the first Write in the tree doesn't change a thing. Changing the index of the Write Nodes as well.

How is this handled in Nuke? Thx for any help. :p

Intel Quad Core
Windows XP64
Nuke 4.7v3

[macsepp]

Same issue in 4.7v5

[Aruna]

Ya, this is the way it works. You can workaround that by adding several write nodes after the first one, and just reference it. So basically your first write out node will be render order 1, then add a read node, reading in that file, and adding another write out node, at render order 2, and so forth.

[macsepp]

Sounds like Nuke is losing some serious rendering speed advantage on this if I first have to read sequences back in again and then convert them to another file format.

Thx Aruna.

[rueter]

the reason for this is to save memory. In your example it back fires a little but the workaround Aruna mentioned is the best way to go (and doesn't take much time to set up at all).
It has been discussed in the past to have options to either render sequentially (the way it works now) or parallel, meaning all Write nodes with the same render order would be processed at the same time which may cause huge memory consumption in some cases and speed up things in others (liike in your case).
You should mention this to the Foundry to see if this is still planned.

[macsepp]

I'm sure somebody will mention this and I hope The Foundry continues the good job developing this great tool we will have to work with for the next view years.
I don't see the problems with the memory since everything is somewhere stored anyway and then saved into a certain file format, isn't it? I think from that point on it should be no memory problem to just convert into three different formats, on after another like setup in the Write Index Values.
This becomes a bigger problem the larger the pipeline gets and it causes unnecessary traffic to have the renderfarm load everything from the raids again.
I'm curious about how other pipelines solved this.

With Arunas solution there comes another problem, because we often deactivate the main Highres uncompressed "Fileout" and just render Jpegs for previews and layouts. But since the Jpegs in this case would rely on rendered uncompressed files you again need another workaround here. More Write Nodes to chose from inside the comp maybe.
I can't think of any advantages from this. :confused:

[throb]

i do this all the time.
one main write node. make it a nice float exr with all channels for fun
Write order 1
then create a read node for that output
add a write to it for cineon
write order 2
add a write node to that read node for jpg (or whatever)
write order 3

i do this for precomps also.
it works and is very efficient on the farm usage.

[im.thatoneguy]

Well it would be nice if you could set a cache node and then write out from that. So... a sort of RAMDisk write node. And then a read/write off of the RAMDisk. That way you don't create an extra uncompressed version if you don't want to and you can control how the memory usage so its not trying to do it at all the wrong points.

[Hugh]

Didn't someone write a gizmo on here recently to do just this?

Here we go - have a look through this thread (http://www.vfxtalk.com/forum/prerendering-parts-tree-t11899.html)

[rueter]

Yes, with consecutive Write nodes it doesn't make any sense. It's only when you have big branches going into off into all directions or multiple independent trees that you want to render all at once when this may become a memory issue. However, with the render order workflow it would be easily controllable. So I'm totally with you, in my opinion Write nodes with the same render order should process at the same time and share a common cache to speed up things.

Don't rely on others to report things like that. That's what everyone does so therefore a lot of feature requests and bug reports never make it to the guys who can fix it ;).

[macsepp]

Hey!

Thank you guys for commenting on this topic. I really appreciate your thoughts.
@rueter
I meant someone else than me at my place here where I work will report this topic to The Foundry to give some feedback about our ideas.

For now we (or better my compositing supervisor did...) found a "convenient" solution with some tcl scripting so a script handles whether to render only preview versions, or a highres uncompressed version first and then lowres from that without touching any Fileout Node at all. Works great so far.