lowrez.net DiskBuffer
automatic disk buffering plugin for Nuke




DISCLAIMER
This thing is still in alpha stage, so you'll likely experience crashes, lockups, hard disk formats, backup tapes shreddings, natural disasters etc.
Read the KNOWN BUGS section, think about unknown bugs, and USE AT YOUR OWN RISK!


ABOUT
This plugin implements a disk-based buffering system, somewhat similar to Fusion's cache. It employs internally a Write node that writes the input to disk (in OpenEXR 32bit format, you can choose the compression) and a Read node that reads it back to the output connection when you re-visit a buffered frame, skipping re-computation of the upstream tree.

Any changes in the upstream will be detected automatically and cause the Write to execute again - you should disable DiskBuffer when doing frequent changes in the upstream (while Viewer is connected downstream) to speed things up a little.

There is a Pre-render button that lets you specify a frame range and then batch-renders only those frames that need updating.


 INSTALLATION
Put the file in %NukeDir%\plugins\user - and maybe add a line like this to your menu.tcl to have it in the menu:
    menu Other/DiskBuffer DiskBuffer


QUICK START
Just connect the node wherever you want the buffering - this should be after a computationally intensive tree. If you don't specify a filename the node will behave as if it was disabled. Make sure to have frame number (the usual %04d) in the name - or obviously the plugin will misbehave.

Specified channels in the input are written to disk (and read back) and all others are passed thru untouched. You should only buffer channels modified (or created) by the computationally intensive tree to save disk space.

When you render a frame - via Execute, command line or just visiting it in a Viewer - all upstream DiskBuffers will be re-rendered to disk as needed.


VERSION HISTORY
v0.2.0
  • hash journal much more reliable
  • channels to be buffered are selected by user
  • autoname and autoextension, Purge command, status line, console log
v0.1.0
  • initial release
    
KNOWN BUGS
  • there are issues (random re-renders, Nuke's viewer cache not working, sometimes even crashes) with complex scripts and long chains of DiskBuffers. I think a full disk-based hash journal is required (hashes are stored inside the node now) - this might be implemented in a future version, for now you should avoid having a lot of DiskBuffers in a given comp
  • rather unpredictable behaviour when input is directly connected to some heavy, 'execute-like' nodes (e.g. VectorBlur)
  • NOT yet tested in command-line render
  • the internal Write node crashes under Linux, so no Linux release, sorry

TODO LIST
  • disk based hash journal
  • suggestions?

Any testing and feedback VERY appreciated.