Read that page - it only offers that option if it can store the hash of the rendered tree in the file meta i.e. in exrs (otherwise it doesn't have anything to check against). J
On 8 July 2015 at 11:22, Igor Majdandzic <[email protected]> wrote: > Sorry but where is that option. I just got a read file knob thats all. Am > I missing something? I certainly am. > > Igor > > > Am 08.07.2015 um 12:16 schrieb Jack Binks: > > It's not that they're necessarily faster, it's that you get more manual > control and may be better if you're happy to trade off the automagic > cleaning of cache data, higher precision vs half float exr, and not needing > to explicitly render you get with diskcache. > > If you've got 'check file matches input' on it'll need to calculate the > hash of the tree above to check it (see rest of article) - cheaper than > figuring out the image but could still be doing work, so that might be what > you're seeing. See if switching it off/using a non-hash-metadata writing > format like dpx makes any difference, as perhaps that's it. Might explain > why different script configurations see different times spent calculating. > J > > On 8 July 2015 at 10:48, Charles Bedwell <[email protected]> > wrote: > >> That's quite interesting, thanks for posting it. >> >> The author mentions that using read from write nodes as being a faster >> and perhaps more efficient way of not recalculating upstream nodes than >> using the diskcache node. >> >> The issue I have is that it is not faster at all, upstream is still >> being calculated and the read from write is completely ignored, and I'm >> stuffed if I know why. If I make a dedicated read node and read that >> sequence, connect it to the downstream it's fine. Plays back like >> lightning. Putting a readfromwrite node in the stream does not seem to >> function. >> >> Charlie >> >> On 8 Jul 2015, at 10:21 am, Jack Binks < <[email protected]> >> [email protected]> wrote: >> >> CAUTION EXTERNAL EMAIL >> >> >> >> >> This may be informative - there's a section on diskcache in particular, >> but the rest is good to know if you haven't come across it before: >> >> http://major-kong.blogspot.co.uk/2012/11/all-your-cache-are-belong-to-us.html >> >> J >> >> On 7 July 2015 at 15:04, Charles Bedwell <[email protected]> >> wrote: >> >>> Hi Daniel, >>> >>> At the moment Nuke 9.05. >>> >>> Elias, I rendered out, checked Read and pointed the viewer to that >>> (exr render, check file matches input disabled) so the write/read is >>> sitting at the bottom of the tree. Playback still awful (I can see the >>> calculating keyframes or whatever it is window pop up briefly from a >>> tracker above it). >>> >>> The only thing that worked is to disconnect the tree and make a read >>> node pointing to the render. Playback is fine as it's just playing back the >>> exr seq. >>> >>> >>> >>> >>> On 7 Jul 2015, at 2:54 pm, Daniel Hartlehnert < <[email protected]> >>> [email protected]> wrote: >>> >>> CAUTION EXTERNAL EMAIL >>> >>> >>> >>> >>> Hi, >>> >>> i would be curious about this too. Because i expierenced the same >>> behaviour in many Nuke versions and finally just gave in, thinking it just >>> doesn't work. >>> I'd be happy to hear other feedback though. >>> What Nuke version are you using? >>> >>> Cheers, >>> Daniel >>> >>> Am 07.07.2015 um 15:43 schrieb Charles Bedwell: >>> >>> Hi, >>> >>> Is there some secret to using the DiskCache node? I have a large node >>> tree which I'm pretty much done with and would like to cache it so I don't >>> have to render it during playback as it's rather slow. >>> >>> I added a DiskCache node and clicked PreCache, but when I scrub my >>> timeline the nodes above it flash yellow as if they are processing. I >>> haven't changed the zoom level or otherwise changed anything. This is with >>> the viewer looking at the diskcache node. >>> >>> Am I doing something wrong? >>> >>> >>> >>> >>> *CHARLES BEDWELL* >>> Compositor, Encore London >>> 142 Wardour Street, London, W1F 8DD >>> t: +44(0)20 7149 2409 <+44%280%2920%207149%202409>/ m: +44(0)7789 190206 >>> <+44%280%297789%20190206> >>> <http://www.encorepost.co.uk/>www.encorepost.co.uk| FACEBOOK >>> <https://www.facebook.com/encorepost> | TWITTER >>> <https://twitter.com/EncorePost> >>> >>> >>> <115070714433600569.jpg> >>> P Please consider the environment before printing this email. >>> _______________________________________________ >>> Nuke-users mailing list >>> <[email protected]> >>> [email protected], <http://forums.thefoundry.co.uk/> >>> http://forums.thefoundry.co.uk/ >>> <http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> >>> DO NOT open attachments or click on links from unknown senders or >>> unexpected emails >>> >>> >>> >>> >>> This e-mail and any attachments are intended only for use by the >>> addressee(s) named herein and may contain confidential information. If you >>> are not the intended recipient of this e-mail, you are hereby notified any >>> dissemination, distribution or copying of this email and any attachments is >>> strictly prohibited. If you receive this email in error, please immediately >>> notify the sender by return email and permanently delete the original, any >>> copy and any printout thereof. The integrity and security of e-mail cannot >>> be guaranteed. >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >> >> DO NOT open attachments or click on links from unknown senders or >> unexpected emails >> >> >> >> >> This e-mail and any attachments are intended only for use by the >> addressee(s) named herein and may contain confidential information. If you >> are not the intended recipient of this e-mail, you are hereby notified any >> dissemination, distribution or copying of this email and any attachments is >> strictly prohibited. If you receive this email in error, please immediately >> notify the sender by return email and permanently delete the original, any >> copy and any printout thereof. The integrity and security of e-mail cannot >> be guaranteed. >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > > > > _______________________________________________ > Nuke-users mailing [email protected], > http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
