if it was in RAM it wouldnt be named "DISK cache" or?
Am 20.02.2012 01:52, schrieb Ryan O'Phelan:
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]
<mailto:[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 Rolling Eyes I just hope
thefoundry dev team will have a look at this in the future.
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[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
