Hi Jean-Luc,
Nuke does stat both the local and original versions of the files before
loading, so if the non-local version is updated Nuke *should* load that
one. If you see different behaviour, then that's a bug, so you should
probably send a report to support.
However, if Nuke does detect
Hi Peter
Thanks for the update. That helps.
I just tested the theory and it works fine.
I localized a Read node from a test render then rendered it again. The
orange bar on the Read node disappeared after viewing the new render. The
interesting thing was that the thumbnail got updated with the
Hi,
Yes, Frank is correct. Currently Nuke doesn't do any clean-up management
on the local cache folder and it must be done manually. This issue is
already logged as a feature request:
*Bug 21091*
https://secure.thefoundry.co.uk/bugzilla/show_bug.cgi?id=21091 -Add
ability to delete locally
ok good to know
One more question regarding updates. If a new version of a sequence is
rendered with the same name, Nuke wouldn't see it would it?
For instance is a roto is updated but overwritten with the same files
name/path, we would have to manually update the local copy? Would it be
Hi Jean-Luc,
you either have to set the Read nodes you want to localise to cache locally =
always or set the local file auto-cache path in the preferences to the root
directory shared by all file paths you want to localise (i.e. '/server/shows/'
). In the latter case the Read nodes' set to
Ok got it!
I thought the localising process was automatic... I didn't realise you had
to manually make it cache...
So what happens when the files are marked always and you're finished with
your shot. Do you have to manually un-cache the files too? There's no size
limit on the localise folder so I
yes, I guess it's a good idea to manually remove the cache files when done.
Don't think there is a mechanism built in for that (which would be a nice
option though to keep your disk tidy)
On Oct 25, 2011, at 12:45 PM, jean-luc wrote:
Ok got it!
I thought the localising process was
