XSIBlog

The FxTree is cool - and I profoundly admire the person that made it - however it really doesn’t handle well not being able to allocate memory and the memory settings are not intuitive.

If the FxTree crashes when you open it, it is because of one of these two causes:

1. the RAM settings are too high
2. you’re running out of disk in the drive where the %TEMP% (or $TMP on unix) variable is pointing to

The important setting is called Image Memory Size (MB). By default, it is 40 megs. In 32-bit, it should never really be higher than 128 megs of ram, because that’s as large as you can safely get in one contiguous block even if you have 3 Gig of RAM. It is the size of one huge memory pool that the FxTree will allocate on startup. In other words, its the minimum amount of RAM to allocate when the FxTree start. In other application, this setting is normally the maximum to allocate! A trivial composite can be assumed to need at least 5 times the amount of RAM of a single image.

In order to be able to resize its memory elegantly (I know, this is ironic), the FxTree allocates a swap file that’s as large as that memory setting. The swap file is located in %TEMP%\XSI_Temp_pid. The hard disk needs to have enough space for it. To quickly go there, at the command line do “CD /D %TEMP%” (/D allows “CD” to change drive if it needs to, otherwise it only changes directory)

In 64-bit you can make the FxTree memory very large, and therefore get a real-time RAM flipbook for free. However, keep watching for space for that swap file on disk. It’ll take a few seconds for the FxTree to allocate that swap file.

If you don’t use the FxTree views and have no FxTree operator in your scene, that memory will never be allocated.

You can right-click on an FxTree node and select “Live Caching”. In this case, the output of the operator will be cached to RAM, for multiple frames, and if the memory runs low it’ll swap to disk using the Disk Usage settings. You would do this for an operator or a branch of the tree that takes a long time to render. It doesn’t persist the setting, but it’s the equivalent of doing a precomp in other products. All file input operators are using ‘live caching’ by default, except with disk swapping disabled, which is why you can sometimes see a yellow diamond (the Live Caching icon) on file input nodes.

Swapping to disk also happens if you use raster paint, or press Play in the FxViewer and it runs out of RAM. Otherwise, these disk options are not used and I’ve never really seen any user having problems with them.

This entry was posted on Friday, May 4th, 2007 at 4:58 pm and is filed under FXTree. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.