Faster rendering for unchanged frames?

I frequently find myself with a Fusion composition where a lot of frames are exactly the same as preceding ones. For example, a title which animates in and then holds for a few seconds. It seems like every frame in the hold time is rendered from scratch when the previous frame could be reused. Does anyone know if I can speed up rendering by encouraging or forcing Fusion not to render those frames from scratch?

Don't know specifics of Fu but the mechanism behind how to accomplish this is based on calculating an unique value (hash) that describes the current state of all inputs and operations that make up the final image. If hash does not change, it is certain that image itself is the same. When it doesn't work out it is either that a) image is not really the same (different input image frame, even if it is visually the same, invalidates cache); b) hash calculation process is broken; c) caching mechanism which uses hash values is broken.

I'm not entirely sure how the cache and request would work, but you could try using a TimeStretcher to hold frame:

Untitled.png (34.59 KiB) Viewed 1762 times

To add a bit to my previous writing, reason why holding frame accompishes what you need is because framehold outputs the same hash value when frame is the same. So engine knows it is the same.

May I ask how you generate the titles, fully inside Fu or you use some external input? And when you say it holds a frame, what do you mean by that exactly? That no node upstream has changing animation on that part (holds constant value)?

Hashes are used for shader caching, but not image caching.

An image cache is valid until it is told it isn't. Which is why you can't undo the change and get your cache back.

An image cache is valid until it is told it isn't. Which is why you can't undo the change and get your cache back.

But what is the mechanism for telling if it is valid or is invalidated if it is not some hashing method? Simply changing a knob should not invalidate the cache. For example if you change some value from x > y > z and end on x again, cache from first state can be used again because image is in the same state.

Are you asking how it should work or how it does work?

Are you asking how it should work or how it does work?

How it does work in Fusion.

Are you asking how it should work or how it does work?

How it does work in Fusion.

Shaders are cached with a hash, so you can store I think 75 shaders by default (might be higher, it's user configurable with FUSION_MAX_CACHED_MTL_SHADERS). So you can change it x->y->z->x and it will keep the cache for each.

Images are invalidated when the inputs to the tool that created the image is invalidated. There are a couple corner cases, like for HiQ, so an output can have two images, one for the HiQ and one not, so that it doesn't invalidate just because you used APrx. Once the cache is invalidated, that triggers the tool to render again (assuming it's requested, since that's what's actually looking for the cached image).

Using hashes for associating caches seems like a nice idea, but that's a LOT of calculation to do to generate those enormous hashes and to compare them to the cached set, and you have to eat up that much extra memory to store the hashes. The likelihood of it being useful is not great since it only ever benefits you when the inputs are cycled back and forth AND there is room for the caching of the images AND there is room for the hashes AND the hash calculation and search is faster than re-rendering. Those combination of conditions may rarely exist.

Are you asking how it should work or how it does work?

How it does work in Fusion.

Using hashes for associating caches seems like a nice idea, but that's a LOT of calculation to do to generate those enormous hashes and to compare them to the cached set, and you have to eat up that much extra memory to store the hashes. The likelihood of it being useful is not great since it only ever benefits you when the inputs are cycled back and forth AND there is room for the caching of the images AND there is room for the hashes AND the hash calculation and search is faster than re-rendering. Those combination of conditions may rarely exist.

Yet this is exactly how it works in Nuke, which is the motivation of my question too, to understand how Fusion does it. In Nuke, every node adds its relevant knobs (that affect its output) to its own hash. This hash and knob values of next node are again hashed together and so on. Hash itself is standard UUID value which is 128 bits, this is very tiny in memory. Hash values for 1000 nodes over a frame range of 1000 frames takes about the same amount of mem as 720p RGBA image, this is irrelevantly small. Hashing itself is also light operation because hash is not calculated on image data but from state that produces image data (I think this is why you thought it would be very slow). This state contains, in addition to knob values, current frame, view, scanline and proxy context. When certain node does not allow animation at all for example (rare but possible), it does not add frame context to its hash, thus engine knows that the output of that node does not change unless its input hashes change which will in turn change its own hash and invalidate cache.

Cache is tied to node hashing through these same uuid values. In cache dir, every cache file is named after its tied hash. And lookup for existing cache works by simply looking up the file in that dir. To prevent slow directory searches Nuke keeps a hash list in mem together with some metadata which is used for weighting stuff against each other. Stuff that takes longer to regenerate is kept longer in cache, what is used more frequently is kept longer and so on.

Lets say I have a node structure A->B->C->D->E where C is a merge and its second input is A2->B2->C. If I attach viewer to node E, hashes are calculated from top down for all nodes, their current state is stored in disk cache and node E is also stored in viewer ram cache. If I make a change in node E, only node E is recalculated because none of the hashes upstream changed. If I change it back, hash will be the same as previous state and it is retrieved (if it has not been purged). If I change some knob in node A, everything downstream it will be recalculated because their hash changed due to their input being changed. A2 and B2 are kept as is though, node C retrieves the cache for node B2 from disk. I can do all kinds of changes in the meantime, if I happen to hit the same combination (state) I had in the beginning and that cache still exists on disk it will be retrieved again, possibly hours or days later (depends on size of disk cache).