Return cryptomatte metadata in GetRenderStats #1178
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes proposed in this pull request
When rendering cryptomatte with husk, we need the new cryptomatte attribute
custom_output_driver
to be enabled, so that cryptomatte metadatas are authored in theHdArnoldDriver
. Then, we need to return this metadata to Hydra through the virtual functionGetRenderStats()
where we return a dictionary of values that will be authored in the exr metadata.In order, to do this, in this PR we register all the drivers associated to a cryptomatte AOV (
crypto_asset
,crypto_masterial
,crypto_object
) and then inGetRenderStats
we check the attributecustom_attributes
and return the cryptomatte metadata in the dictionary.I could have registered the drivers by their AtNode pointer instead of their name, to avoid doing a node lookup, but I'd rather avoid crashes if/when some nodes got deleted during IPR sessions. So I'm storing the driver names.
Also, for now I'm looping over all of these drivers, even though in theory all the drivers for cryptomatte AOVs will have the same data, so we could just check the first one. But since GetRenderStats doesn't seem to be called very often, it looks like it's not a bottleneck.
Issues fixed in this pull request
Fixes #1164