HtoA-style Cryptomattes (was: Arnold 5 Cryptomatte and Cryptomatte 1.2.0 Beta)

[Jonah Friedman]

Forking the thread because I figure this is a discussion of its own, which is how best to support Houdini in Cryptomatte. Sorry for the slow response. 

Right now, Cryptomatte's name processing is pretty Maya-centric. The idea in Maya is that the namespace maps pretty well to an "asset", and if you strip apart a name like "bob:hat", you get two pretty useful mattes to use, all of the "bob" namespace and if there are multiple bobs, all of their hats. Alternatively you can turn off namespace stripping for objects, and then you just get bob:hat for the hat in the object Cryptomatte, which uniquely identifies that object. The ":" character means something totally different in Houdini of course and so that doesn't work great. 

This scheme doesn't work very well for Houdini, so my standard advice is HtoA right now is to first turn off namespace stripping for objects and materials and don't bother with the "asset" matte, unless you set it up manually with the user data. I would like to figure out how HtoA names could be used to useful effect, but I'm pretty ignorant of how Houdini works and even more ignorant of what working practices are. In Maya referencing assets into a namespace is, after all, a working practice, but namespace = asset works well enough because that's what the practice is. So what I would like to know and need help finding out is, what would do the right thing in ordinary production practices? (We could also use help implementing it, I know the HtoA community has lots of talented coders). 

Frederic posted a bit of a proposal earlier involving names that start with "/<subnet>/". Do all names from HtoA start with "/"? If so we could use this to detect that we should do Houdini-style name parsing. Is there something that could be used to approximately break the name apart into "asset" and "object" names in Houdini, could "/<subnet>/" do this job well enough? 

On Mon, Jul 24, 2017 at 3:46 PM, Frederic Servant <frederic...@gmail.com> wrote:

Hi Sergio,

Is this the crypto_asset AOV? The current implementation of cryptomatte does not seem to handle HtoA names very well and cannot infer the asset from the object name. I've already notified Jonah about that.

A workaround is to create a "crypto_asset" string attribute on the geometry to override the automatic asset detection. Materials and object IDs should just work out of the box though.

Cheers,

--

Fred

On Sun, Jul 23, 2017 at 8:01 AM, Sergio LoDolce <sergio....@gmail.com> wrote:

Having some issues with Houdini implementation.

Had it working with Arnold 4.2 using the passthrough for each Shader Network I wanted to include into cryptomatte.

For Arnold 5 I'm going off this guide: https://support.solidangle.com/display/A5AFHUG/Cryptomatte

It looks like we now have to create a new Shader Network dedicated to outputting AOVs? As seen below?

And then we need to take that Shader Network and plug it into the AOV Shaders input on the ROP?

For this test I have three different Shader Networks for three different objects. I'd like to have them all use Cryptomatte. Right now they're all coming out as one object.

How do I separate them out?

On Tuesday, July 11, 2017 at 11:57:28 AM UTC-4, Jonah Friedman wrote:

We’re thrilled to announce the beta release of Cryptomatte for Arnold 5, as well as version 1.2.0-Beta of the Cryptomatte specification, and reference Nuke implementation.

Arnold 5: (AlShaders2): https://github.com/anderslanglands/alShaders2/releases

Nuke and Fusion: https://github.com/Psyop/Cryptomatte

Arnold 5 Cryptomatte

Cryptomatte for Arnold 5 is being released as part of AlShaders, as before, but is now a standalone node.  Arnold 5.0.1 adds support for “AOV shaders”, which allow code to run on all materials in a scene, without manually connecting passthrough nodes.  This improves the workflow in numerous ways.  Using a central AOV shader node gives easy access to global Cryptomatte settings (on the one central Cryptomatte node).  It is now also much easier for a studio to create a customized version of Cryptomatte, since the code does not need to be embedded in a surface shader.  In addition to adopting the AOV shader methodology, we’ve added other features as well, such as sidecar manifests that work with deferred-loaded stand-ins, and “integer offsets” for modifying names.

Arnold 5 Documentation: Cryptomatte documentation, MtoA, C4dtoA

Nuke

The big new features in the Nuke plugin are support for sidecar manifests, and a new “Encryptomatte” gizmo.  Although sidecar manifests were already in the specification, there was no implementation for them in the plugins.  The sidecar manifests are UTF-8-encoded json.

The Encryptomatte gizmo provides Nuke users with the ability to generate Cryptomattes from scratch, or composite new mattes into an existing set of Cryptomatte channels.  For example, given a set of conventional roto mattes, Encryptomatte can be used to consolidate the mattes into the more compact Cryptomatte encoding.  This could be useful, for example, when handing off mattes between comps, or between compositing packages.  Our hope is that this will open up Cryptomatte to a wider set of users not working exclusively with rendered images.  In the event that Cryptomatte support gets added to color-correction tools, we think the technology could significantly streamline the handoff of mattes between VFX and DI.

Cryptomatte news

The 1.2.0 release includes several important updates and clarifications to the specification -- many of which were driven by the recent addition of Cryptomatte support for VRay.  Most notably, we have clarified that hashes should be computed based on the UTF-8 encoding of a given Unicode string.  UTF-8 provides backwards-compatibility with ascii-based hashes, but also allows hashing non-ascii characters.  We have added some step-by-step examples to the specification to help with validation and debugging for those implementing Cryptomatte hashes.

This is a beta release, both for AlShaders and Nuke. We feel pretty good about it but it hasn’t seen a lot of production testing yet, so we definitely appreciate any help here. Existing comps and older Cryptomattes will continue to work with the 1.2.0 upgrade, and the new Nuke plugins are not required to use Arnold 5 Cryptomattes (with the exception of sidecar manifests).

Thanks to everyone in the community who has contributed, and also the support from Solid Angle, Chaos Group, and Isotropix.  As always: we hope you never manually make a matte again!

Jonah, Andy and Psyop

-- 

JONAH FRIEDMAN

PSYOP NYC | LA OFFICE: +1 (212) 533-9055 MOBILE: +1 (347) 873-3992 45 HOWARD ST, 5TH FLOOR, NEW YORK NY 10013

--
You received this message because you are subscribed to the Google Groups "alshaders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alshaders+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "alshaders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alshaders+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

JONAH FRIEDMAN

	PSYOP NYC | LA OFFICE: +1 (212) 533-9055 MOBILE: +1 (347) 873-3992 45 HOWARD ST, 5TH FLOOR, NEW YORK NY 10013

[Jonah Friedman]

Thanks. So what i'm after here is really two-fold, how does Houdini technically name things (answered by Frederic), and what do actual production setups look like? The asset Cryptomatte is called crypto_asset and not crypto_namespace, because grouping by asset, in the sense of what people actually consider an asset, is what we would like to be able to infer reasonably well. In Maya we use namespace for that, not because a namespace is always an asset, but because in most existing Maya lighting workflows it is a good proxy for it. 

The examples given were:

/obj/torus:polygons

/obj/foo/bar:curves:45 (for instances)

Changing from foo/bar to something a little more real, how would this look if this were a model of a car, and if the scene contained more than one? Would it be something like this:

/obj/car1/wheel:polygons

/obj/car2/wheel:polygons

In that case, I would think /obj/ could just be thrown away, and after that the split between "asset" and "object" could be on the first "/" if it exists:

/obj/car1/wheel:polygons

asset: car1

object: wheel

If you had a spare wheel just lying around, then I think the reasonable behavior, mirroring what happens in Maya, could be: 

/obj/wheel:polygons

asset: default

object: wheel

Comparing to Maya:

car1:wheelShape:

asset: car1

object: wheelShape

wheelShape: 

asset: default

object: wheelShape

 

Some followup questions:

1. Does throwing out "/obj/" make sense? 
   
2. I want to know if this scheme makes sense from a typical production perspective as well as whether it works technically. Are things in production nested more deeply, such as: /obj/assets/sets/cars/car1/wheel:polygons? I've been thinking for Katana-style paths, which are somewhat similar, it might be useful to give a control for which "/" to split on, is this something that would be useful for Houdini as well? 
   
3. It seems like checking if the names start with "/" could be a switch to use unix path-based name processing (Houdini, Katana) instead of namespace-object-based (Maya, Softimage) processing. Specifically, Houdini naming could be detected by the name starting with /obj/? It'd be nice to not have to specify which scheme is being used, but switch it based on the name it encounters. 
   
4. How are shaders / materials named, what are they rules there? 

On Mon, Jul 24, 2017 at 10:14 PM, Mathew Rotman <mro...@psyop.tv> wrote:

yeah, thats tricky.  Clearly being able to separate by material is huge, but also perhaps by geometry, and then by name attribute.  Just a thought.  Im not sure how hard it would be but also having 3D connectivity could be useful.

--
You received this message because you are subscribed to the Google Groups "HtoA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to htoa+uns...@solidangle.com.

--

MATHEW ROTMAN I HEAD OF FX

PSYOP LA | NYC OFFICE: +1 (310) 577-9100 MOBILE: +1 (310) 480-1028 523 VICTORIA AVE, VENICE, CA, 90291

--
You received this message because you are subscribed to the Google Groups "HtoA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to htoa+uns...@solidangle.com.