[Fusion 16] Lua memory issues

[bryab]

I've seen lots of issues and reports on forums about problems with the Cryptomatte plugin when you use up too much memory, causing mattes to pop off and on randomly.

The workaround I've heard (for rendering) is to put the command fu:PurgeCache() in the "Frame Saved Script" box in your Savers.

This seems to certainly help, but it surely makes renders slower by forcing the cache to be purged every frame. Is this an inherent problem with Fusion that can't be overcome?

Edit - the purge cache function does consistently fix my problem in renders - with that added I can consistently get a correct result.

[cedricduriau]

Hi @bryab

The workaround I've heard (for rendering) is to put the command fu:PurgeCache() in the "Frame Saved Script" box in your Savers.

This will not be a consistent fix, sadly. It helps, but I'll recommend you to be faithful and patient.

This seems to certainly help, but it surely makes renders slower by forcing the cache to be purged every frame. Is this an inherent problem with Fusion that can't be overcome?

Helps indeed, and absolutely will slow down your render times as you noticed. I will refer you to #46 where this get discussed into more details.

Edit - the purge cache function does consistently fix my problem in renders - with that added I can consistently get a correct result.

I am happy for you, but I can already tell you as mentioned above that this is sadly not a consistent fix for everyone.

Cheers Cedric

[bryab]

Thanks for the reply. Just an update to say that the workaround I described doesn't really work consistently. We are having to prerender all our Cryptomattes, which is quite unfortunate.

Would it be possible to make Cryptomatte work in a very different way, by assigning the Cryptomatte channels to the normal RGB channels in the Fusion Loader (or using some of the other Fusion auxillary channels), and making a Fuse that reads the color information directly from the loader in that way? My guess would be this might resolve some issues with the Lua code attempting to load the image data. It would allow Fusion to do that heavy lifting.

[cedricduriau]

Thanks for the reply. Just an update to say that the workaround I described doesn't really work consistently. We are having to prerender all our Cryptomattes, which is quite unfortunate.

Your welcome, thank you for your understanding and pre-rendering is indeed another safe way to get there.

Would it be possible to make Cryptomatte work in a very different way, by assigning the Cryptomatte channels to the normal RGB channels in the Fusion Loader (or using some of the other Fusion auxillary channels), and making a Fuse that reads the color information directly from the loader in that way?

Funny enough if you browse to the origins of Cryptomatte, this is exactly how it was done before BMD provided me the EXRIO library. The issue there is of course the limited hard coded slots of channels a Loader gets shipped with. You will very quickly run out of slots to use inside a multi-layer crypto image.

My guess would be this might resolve some issues with the Lua code attempting to load the image data. It would allow Fusion to do that heavy lifting.

Well here is the thing regarding letting Fusion do the heavy lifting. It actually does.

With the previously mentioned limitation, we reached out to the BMD developers. They were kind enough to provide us the EXRIO library to solve this issue. So technically, I am using a builtin library to read EXR image data. Now the internals of this module are none of my concern, bluntly put. Either the Fusion implementation of Cryptomatte is doing very non-kosher things or Fusion (EXRIO or other) does have a memory issue when programmatically dealing with EXR images.

[cedricduriau]

Fixed in cedricduriau#11