Automatic "psyop" ID mattes

[RichardBlank]

It's basically what Thorsten said. There's nothing wrong with Vrays deep support. There is just a handful of deep nodes in nuke so we have to do most of the comp with deep expression nodes. That's probably why most people won't use deep at all and want support for cryptomatte.

[monsteradurm]

I'm a big fan of VRay and our deep setup here, and whilst there has been alot of custom nodes ive had to create for our nuke pipeline. nuke makes it fairly painless to set them up w it's api and gizmo functionality etc.

If theres something in particular your looking for perhaps I can help or explain how we overcame in our Vray Deep to nuke pipeline. If this is hijacking the thread at all then perhaps in a separate thread or private message.

[FSGFX]

monsteradurm a second thread would be great... thanks...

[instinct]

I'm a big fan of VRay and our deep setup here, and whilst there has been alot of custom nodes ive had to create for our nuke pipeline. nuke makes it fairly painless to set them up w it's api and gizmo functionality etc.

If theres something in particular your looking for perhaps I can help or explain how we overcame in our Vray Deep to nuke pipeline. If this is hijacking the thread at all then perhaps in a separate thread or private message.

It's kinda sad that there are no efforts on the foundry's side and we all re-invent the wheel.

I tried getting in touch with a bunch of ppl that i knew were doing Deep to try and work together where applicable but that kind of went nowhere.

Cheers,
Thorsten

[monsteradurm]

hrmm.. well i guess i dont see it as much of an issue as everyone else..

eg. if the main benefit of using cryptomatte is to 'color pick' mattes, its a pretty simple gizmo implementation - using a sample node and an expression, or even just using an expression and a position attribute. I've written our lighting pipeline to store shadernames/MaterialIDs in the exr metadata so it can be looked up by shader name rather than / in addition to color picking as I've found its much more useful when re-using nuke scripts between scenes.

[instinct]

hrmm.. well i guess i dont see it as much of an issue as everyone else..

eg. if the main benefit of using cryptomatte is to 'color pick' mattes, its a pretty simple gizmo implementation - using a sample node and an expression, or even just using an expression and a position attribute. I've written our lighting pipeline to store shadernames/MaterialIDs in the exr metadata so it can be looked up by shader name rather than / in addition to color picking as I've found its much more useful when re-using nuke scripts between scenes.

I've implemented total of 16 inhouse Deep plugins ranging from rather standard things like a deep and ID aware grade implementation over utility nodes to create mattes from deep IDs or merging IDs to rather specific nodes to recreate the beauty from passes etc. To make them perform well and leverage all of the nifty possibilities deep offers they are all binary/NDK plugins. It's quite a lot of work to create these and now maintain these and there is still no lack of ideas for things to implement.

Not even having an ID maskable DeepGrade out of the box is a bummer in my eyes. And there's that weird hen/egg problem of people not adopting deep for lack of nuke support and the foundry not implementing better deep support due to lack of adoption *sigh*

Cheers,
Thorsten

[monsteradurm]

Not even having an ID maskable DeepGrade out of the box is a bummer in my eyes.

Typically I would use a 'deepRecolor'' and generally speaking, I find it more efficient to use the deep info to generate the necessary holdouts and do the 'standard' compositing tasks in a non-deep workflow post conversion.

[instinct]

Typically I would use a 'deepRecolor'' and generally speaking, I find it more efficient to use the deep info to generate the necessary holdouts and do the 'standard' compositing tasks in a non-deep workflow.

That's a matter of the type of tasks at hand i guess. It's the only reason for me to go deep to be able to properly separate objects in post and get rid of fringing etc in post colorization workflows. Essentially DeepRecolor drops the most essential part of deep for us.

Cheers,
Thorsten

[monsteradurm]

That's a matter of the type of tasks at hand i guess. It's the only reason for me to go deep to be able to properly separate objects in post and get rid of fringing etc in post colorization workflows. Essentially DeepRecolor drops the most essential part of deep for us.

Cheers,
Thorsten

yeah it does.. thats why i use deep to generate all of the mattes required, and then shufflecopy those mattes in after the hold out - or use the ndk/gizmos to do those processes automatically where possible.

[instinct]

yeah it does.. thats why i use deep to generate all of the mattes required, and then shufflecopy those mattes in after the hold out - or use the ndk/gizmos to do those processes automatically where possible.

What are the advantages over spitting out MMREs for you then? Not having to decide upfront which mattes you want?

Cheers,
Thorsten

[monsteradurm]

What are the advantages over spitting out MMREs for you then? Not having to decide upfront which mattes you want?

Cheers,
Thorsten

yeah, pretty much. Having all of the Material Info/Object info stored in the multimatteID/objectID pass so that the compositors can adjust as required when required. Spitting out individual MMREs for 200+ materials is a significant drop in speed / gain in filesize/layers when they can be generated automatically in post when required easily. The results used in combination with DeepEXRs are alot cleaner also, given that the alpha & ID values are stored per deep sample.