Hi. I have made a couple tests with a simple scene (4 primitives) and:
In NUKE everything seems about the same, tested it wuickly and everything looks normal, the picker works as expected. So…great!
In PHOTOSHOP (using exrIO plugin) each object is split in separated layers. I’m unsure if that’s the usual behavior (I’ve only used Ps/exrIO with renders coming from Maya), but in a large scene it would mean an absurd number of layers, and probably a huge processing time. On the upside, there is no selection required, is literally having a ton of alpha layers split multiple times (obj1.material, obj1.asset, obj1.object, obj2.material, etc…).
Then again, I haven’t used it before coming from blender into PS. I tried the same scene with an earlier version of Blender and it does the same thing, so I guess it’s working as expected. Maybe @machieb can shine some light.
@txo: The behavior in photoshop you subcribe is the way the Exr-IO plugin works/worked.
You are right if you have many objects or shaders in 3D, it ends up in a huge prosessing time and a mass of layers. So if you plan to make compositing in photoshop, you have to think beforehand if you render crypto materials, crypto objects or both of them.
@machieb it isn’t in the experimental tab. Just try to use the cryptomatte node in the compositor. The changes are all related to how to use cryptomatte within blenders compositor. There wouldn’t be any changes when exporting to an OpenEXR file.
Hey, I still seem to be unable to render out cryptomattes correctly and export them to Nuke. I’ve downloaded the test file and exr and they both work fine in nuke. I can also render from the test file and that works fine in nuke also. However when I try and render my own scene I can’t access the cryptomattes in nuke correctly. The metadata looks correct in the render when I check inside of nuke so I’m not sure exactly what I’m doing wrong as far as I can see my blend file is set the same as the test file?
OK, I opened it and it seems all is fine. The issue was thecrypto names in the fileOutput node didn’t have the 00 at the end. It is used in nuke to check how many levels there are per pixel, so it has to be there for the cryptomatte to work properly.
That kind of hassle is why I recommended to use the script by @p2or in a comment before in the thread. It helps a lot with that.
the new cryptomatte workflow has been committed to master. There is another patch in review (https://developer.blender.org/D10705) that shows the object/material name under the mouse cursor when picking.
looks great!
One thought from what I see in the video demo (haven’t tested it): In my experience, it is really common that you want to create a mask out of a bunch of elements at a time, and maybe they are all separated. I think it would be a nice addition if the add and remove tool could stay active and the user didn’t need to go and click it every single time, just keep adding/removing objects as you click+drag the eyedropper over the image (if you just click and release, it would work as it does in the demo video).
I think from a UX perspective it would be much better.
But nevertheless, great job!
I was thinking of that last week, but haven’t looked into it yet. Need to check with ui team if that fits within the design guidelines. Bit would be a good addition.
Just thought of bringing this here although I left a message on Blender.chat, not sure If its a bug or feature request.
Basically as it stands Blender render output with cryptomatte is not compatible with Nuke (nuke has native cryptomatte support for a while now)
I spent a few hours going through this test, comparing the test files supplied here with the latest versions of Nuke (2.93 and 3.0 Alpha)
I narrowed down the problem to how the metadata tags with the cryptomatte settings are built.
The first issue is regarding the view layer naming, if it has a space it will need to have an underscore on the name metadata tag for the cryptomatte layers.
The second issue is that the . separator between the view layer name and the cryptomatte layer is not supported by Nuke so basically that . separator also needs to become an underscore.
As an example here is what the current metadata tag for the cryptomate layer is and how it should be in order to work in Nuke.
View Layer.CryptoMaterial should be>> View_Layer_CryptoMaterial.
Basically no spaces, nor dots.
Ive come to this conclusions by manually editing the metadata keys.
Yes, tried with Nuke 13.1v5 and it doesnt work, only if i change manually the metadata (replacing . with _), so im 100% sure its not working. They pretty much disregarded the Psyop changes since 1.24, gone!
