V-Ray 7.30.03 only writes Cryptomatte metadata for the first layer into the EXR
header. If you have VRayCryptomatteOBJ + VRayCryptomatteLAY + VRayCryptomatteMAT,
Nuke only sees OBJ. LAY and MAT are invisible in the Cryptomatte node.
The pixel data for all layers is present and correct — only the header is incomplete.
I tested all three export paths (vrimg2exr, VFB Save as EXR, raw .vrimg binary):
all produce the same result. The bug is in V-Ray Core, not in vrimg2exr.
V-Ray 7.30.01 (revision 33485) writes all 3 layers correctly.
V-Ray 7.30.03 (revisions 33544 and 33551) writes only the first layer.
What changed: in 7.30.01 all Cryptomatte manifests are empty {}.
In 7.30.03 the first layer gets a fully populated manifest (~400 objects),
and after that no further layer metadata is written. Looks like the manifest
generation introduced a loop bug.
Note: scenes are created in 3ds Max 2025 on Windows, but rendering
runs via V-Ray AppSDK on Linux. The bug appears in both the Linux
AppSDK render output (.vrimg) and the Windows VFB export independently —
confirming it is a cross-platform V-Ray Core issue.
1. Confirmed on V-Ray AppSDK Linux nightly as well
Tested on appsdk-linux-rhel8_qt5-nightly-vray_v7.20.09_dr2-20260421_stable_33553 — same bug, same result. Only the first Cryptomatte layer has metadata keys in the EXR output.
This is a completely separate product on a separate version branch (revision 33553, one step after 33551). Since both the 3ds Max plugin and the Linux AppSDK produce the same broken output, this further confirms the bug is in V-Ray Core — not in any product-specific code path.
2. Workaround limitation for existing projects
The ModifyMetaData-based workaround (mentioned in my previous post) works for new projects. However, for existing Nuke projects it is impractical: inserting the fix node between the Read and Cryptomatte nodes causes all saved matte selections in the Cryptomatte node to be lost and must be manually re-created.
This makes a proper Core fix even more important for production pipelines.
Update — bug confirmed with Standalone render nodes
I ran an additional test today: switched all render nodes (q1–q7) from AppSDK VRayServer to V-Ray Standalone (vray -server), keeping only the initiator/runner on AppSDK. Same V-Ray Core build (7.30.03, revision 33551) throughout.
Result: same bug. The converted EXR still has metadata keys only for the first Cryptomatte layer (OBJ). Python openexr header inspection confirms only 4 Cryptomatte keys in the output EXR (OBJ only) — consistent with all previous findings and independent of any compositor version.
This further isolates the bug: since the render nodes are now Standalone and the only AppSDK component is the initiator, and the bug still occurs — the defect is in V-Ray Core’s metadata writing routine on the initiator side, not in any node-side code path.