Currently prepping for a job and testing out whether we can use Silhouette and its newly added Crytpomatte feature for integrating a structured roto set. Based on initial testing the Silhouette Cryptomatte implementations has a hole, but I’m discussing this on the BorisFX forum.
Would any of you see value if this were to get fixed? If so, please chime in on the BorisFX forum.
Essentially the idea is that you can build a complex roto out of a tree of mattes, render this out as a Cryptomatte (similar to what you receive from CG deliverables), which would then allow you access to individual components of the roto through the existing Flame Cryptomatte node.
And while on the topic - a separate feature request, which may not be nearly as easy, as it would require an OFX API extension possibly, is to have the Silhouette OFX node in Flame be able to export a Cryptomatte stream. If that were possible, you wouldn’t even need to render out an EXR sequence, but you could get in-node-tree multi-matte roto access with the more advanced roto tools of Silhouette.
And out of curiosity - when you have a multi-shape (think 20+) roto, how do you currently integrate/use that in a Flame batch? Just copy all the shapes into various GMask Tracer nodes? Any other paths?
Cryptomatte for roto seems like a solution in search of a problem, but maybe that’s because my only Cryptomatte experience is in the context of giant, super heavy multipass 3d renders. RGB mattes for roto have always been enough for me, honestly.
Fair point. But isn’t the max number of mattes you can select that way 7? In this case we might have as many as 50 objects in the roto that we need to select. I know this may be an unusual case for roto, not unusual for CG comps though.
Also cryptmatte selection with wildcards is interesting in larger use cases.
It’s a layered CG element / camera element integration in a motion controlled shot. The stuff that some creatives dream up, you know…
Which is why I like the Silhouette path. We have the camera track, and want to put that into the top most layer transform. So most of the roto will get the camera move for free and we just have to fine tune keyframes for perspective.
Keep in mind Cryptomatte will generate holdouts for shapes interesections. At least this is how it works with Nuke Encryptomatte node. This may not be what you want. An alternate route could be to leverage EXR parts and layers along with custom metadata to have a structured shapes setup… although maybe only practical in Nuke.
Thanks for the heads-up. I’ll experiment with that. The way the objects are arranged, we would just have to break it into two files and it would avoid any undesirable overlaps. There are the base objects, and then each has some extras.
The number of ranks defaults to 6, but you can set it as high as you want.
But the number of ranks is not the total number of shapes/layers - it’s just how many it’ll keep track of if they overlap. You can have as many shapes/layers as you want, and as long as not many of them overlap, you can isolate them individually.
I was able to get it working by splitting this into three separate mattes, which avoids most of the complex overlaps. There are three logical elements we’re rotoing.
I’m keeping everything in a single layer which inherits the camera track. So everything is just a deep stack of shapes. I’ve come up with a naming convention which allows me to use the wildcards in Nuke to multi-select the appropriate shapes.
Would still be nice to see if this could be more flexible, but for now it works.