I've noticed a few posts about the disk cache node, and after my own disappointments, I just ignored it. I would really appreciate a good explanation of the proper use of this node.
I assumed it's purpose was to spare the comper from recalculating processor-intensive branches of a comp. I think the assumption was that the cache was in RAM, but I believe it's on disk (which takes longer to read), which would explain the mediocre performance that so many of us notice. Still, I'm only guessing here. Ryan On Sun, Feb 19, 2012 at 1:29 PM, KiboOst <[email protected]>wrote: > ** > Well even when I make entire preview in ram on last node before write, > writing frames make Nuke re-render the exact same thing instead of direct > write ram cache to files. Quiet disapointing, performances, playback and > caching are really strangely outdated, specially coming from Toxik. > > Anyway Randy, sure I wouldn't start toxik vs nuke thread, nuke is ahead > hands down regarding a lot of things (3d environement, customization, > python scripting, etc etc). But when nuke works ok regarding performances, > toxik just fly. So I can't not think of having toxik caching technology > inside nuke, but hey, we can't have the butter and the dairywoman lol [image: > Rolling Eyes] I just hope thefoundry dev team will have a look at this in > the future. > > _______________________________________________ > 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
