Peter,
For a recursive process , assuming N here is the sequence length, I have not
tried recently but I did a couple of years ago.
Can't you just hit render while in GUI interface, and that will render in order
and cache the previous result(s) internally.
This will not work on a distributed render farm but that is OK.
I don't think unless something changed recently that Nuke launches simultaneous
frame renders at once sort of thing in such case.
What can happen though is a frame somewhere in time could get cached by nuke because you were there (at that time) and parameters
have not changed, so you might need on first frame to force that to go away by internal updating some parameter or something (or
Render|Clear Disk Cache...)
Pierre
I just tried for myself connecting to a write node and checking read file but there is nothing to read unless you explicitely render
that node so that does not seem like an avenue in terms of building dependencies.
On 10/21/2011 1:16 AM, Peter Kaufmann wrote:
Hi,
I was wondering if the following is possible in Nuke:
Consider a plugin that processes a video stream. Now processing frame N not only depends on input frame N, but it also depends on
the _output_ of the computation of frame N-1. A simple example would be something like this:
out_N = in_N * 0.9 + out_{N-1} * 0.1
i.e. the output color of frame N (out_N) is a mix between the input frame N (in_N) and the output frame N-1 (out_{N-1}), resulting
in a time blur effect. The output for frame N thus depends on all input frames up to N (1, 2, ..., N).
One way of implementing this would be to split the input in the Nuke plugin and request input frames (1, 2, ..., N) for the input.
However, I assume this would be quite expensive (O(N) for frame N). Is there a better way of doing it?
To make things more difficult, what if the mix weight is actually a knob and
thus can change over time, i.e.:
out_N = in_N * alpha_N + out_{N-1} * (1 - alpha_N)
where alpha_N is the knob value at frame N? I think in this case, requesting all input frames up to N won't work, because when
computing frame N, we only know alpha_N but not the previous alpha values. Or is there a way to retrieve the knob value for an
arbitrary frame?
One way I could imagine to do it is to store out_{N-1} in the plugin after processing frame N-1, and when processing frame N,
re-use that data. If frame N should be processed and out_{N-1} is not available, simply output black or an error message. So as
long as the user only moves forward in time, the output is ok. However, if the user then goes ahead and changes e.g. alpha_{N-2},
we would have to throw away the stored out_{N-1} because it would look differently. But we don't know when alpha_{N-2} changes, so
with this approach there can be inconsistencies. And what's worse, Nuke might cache the out_N because it doesn't know it depends
on alpha_{N-2}, so our plugin doesn't get run for frame N and we don't get a chance to update out_N at all.
So, is there a nice way of handling these kind of things in Nuke? Something like requesting out_{N-1} when computing out_N, and
telling Nuke about this dependency (using hashes) so caching doesn't break?
If not, the only practical solution I can imagine is to live with the above inconsistencies and provide a Py script button in the
GUI which, using the Executable interface, processes all frames as a serial sequence, and writes the output for every frame to
disk (i.e. caches its output). So while editing, the user has to be aware of the fact that the button has to be pressed to make
sure the output is consistent. And Nuke's caching needs to be disabled for that plugin.
Any other ideas on how to do this? Any help appreciated...
Thanks,
Peter
_______________________________________________
Nuke-dev mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
