It’s only the compositing node still, not yet Cycles output of the render passes.
This written by a developer gives us a lot of hope for the users
@skw Stefan, I would love to see another BCON talk from you!
Last years cryptomatte “teaser” blew me away (whole talk was great), Im sure alot of people would enjoy a showcase of this years improvements and additions!
Thanks skw and brecht for reeling this in!
+1 I second that.
Are there any chances for custom AOVs return into Cycles?
This would be superior feature - if material could be able to generate (for example) different “effect masks” as crypromatte layers. like “virtual objects” or texturing features, not really present in mesh form
I’d to be able to speak at BCON again this year. We’ll see, there are a few things to be hashed out first.
Hhas anyone done this kinda thaaaaaang in production with success?
It’s funny that he doesn’t go on explaining of what use this “ID mask” pass will be in compositing. I guess the only choice you have is to use a color key and hope that other object’s colors aren’t too close to the object you want to key. This will get dirty for sure, especially in more complex scenes.
The next problem you will possibly hit is when you add or remove objects in your scene. It will likely reshuffle the output of the “Random” node and you will have to pick all the key colors over and over again.
I hope that Cryptomatte gets integrated into Cycles soon because it’s lightyears ahead of all existing multi-matte, id-matte, object-matte etc. stuff. Gives you crystal clear masks even when it comes to depth of field and mtion blur, is 100% reliable (been using it in a lot of productions with Redshift and V-Ray without a hitch) and almost any compositing tool on the market can handle it, including Blender compositor (in master and 2.8), Nuke, Fusion, After Effects, …
Apparently this is getting closer
This is really not a good solution. It is a nightmare to work with. The edges of objects are going to be incorrect and that will require extra time to correct and in some cases will not even be possible to correct. It’s very easy to overlook mistakes when editing renders with masks made from that when you are in a rush as well, because it sometimes works and sometimes doesn’t depending on the colors. And the fact that some other good render engines might have this horrible horrible feature does not make it any better . It is a lot better to render masks 3 at a time with RGB colors than this. And that is still a huge headache.
I see October 26, revision approved. What does that usually mean? That we can find it in tomorrows latest build, or am I way too optimistic and spoiled then? ( i suppose so)
Stefan has to commit it first (which he hopefully does soon). Then it will be in the next build.
I was hoping to commit last night, but there were so many people to talk to at the Blender Conference dinner, I didn’t get to spend any time at the computer. Right now I’m about to board a transatlantic flight, so this will have to wait until sunday or monday.
I’m looking forward to it being committed but I’m not in a hurry.
As I have read this part of the Cycles source code recently, here’s how it works:
The name of each object is hashed and used as random ID.
So the colors will not change if you add/remove objects, but they will change if you rename them.
OK, that’s at least something. But now with Cryptomatte right around the corner, all of this becomes obsolete hopefully.
Cycles: Added Cryptomatte output.
This allows for extra output passes that encode automatic object and material masks
for the entire scene. It is an implementation of the Cryptomatte standard as
introduced by Psyop. A good future extension would be to add a manifest to the
export and to do plenty of testing to ensure that it is fully compatible with other
renderers and compositing programs that use Cryptomatte.
Internally, it adds the ability for Cycles to have several passes of the same type
that are distinguished by their name.
Differential Revision: https://developer.blender.org/D3538
But sadly I’m not able to compile it under Linux Mint because:
... /blender-git/blender/intern/cycles/util/util_murmurhash.cpp: In function ‘float ccl::util_hash_to_float(uint32_t)’: /blender-git/blender/intern/cycles/util/util_murmurhash.cpp:121:2: error: ‘memcpy’ was not declared in this scope memcpy(&f, &float_bits, sizeof(uint32_t));
I also get an error in linux, but I think it’s different one:
I think my problem for master appeared since I ran the new build deps script for 2.8.
Ok, apparently I installed OpenImageIO from git (1.9). I do not even remember when.
I have uninstalled it and now I can build master.
And Brecht fixed it