Support render targets for 'usdrender' product type #8
Conversation
| @@ -26,6 +26,7 @@ class ValidateUSDRenderProductPaths(pyblish.api.InstancePlugin): | |||
| hosts = ["houdini"] | |||
| label = "Validate USD Render Product Paths" | |||
| optional = True | |||
| enabled = False | |||
There was a problem hiding this comment.
Does this just hint that this should be configurable in studio settings and disabled by default? Why are you disabling it?
There was a problem hiding this comment.
Does this just hint that this should be configurable in studio settings and disabled by default?
I think yes. tbh, I have no idea what is this $HIP/renders/$HIPNAME:r/$OS/$HIPNAME:r.$OS.$F4.exr and it was not in the node on creation by default. and that note encouraged me to just disable the validator 😅
(colorbleed): This workflow might be relatively Colorbleed-specific
There was a problem hiding this comment.
Yup, so basically what happens is that the USD Render ROP writes out an intermediate __render__.usd file or alike - however, by default that's just a static path, not a render file for your particular workfile if I recall correctly. And thus, if the user quickly submits to deadline three files from the same work folder it basically means that the each job would overwrite that render.usd file the other two jobs are also writing - hence you can't submit multiples at once. By making sure those files have unique names (e.g. containing $HIPNAME that solves that particular issue).
There was a problem hiding this comment.
I think I get it now. it important when publishing multiple usdrender instances at once.
| usd_file_per_frame = "$F" in instance.data["ifdFile"] | ||
| usd_file_per_frame = instance.data["farm"] |
There was a problem hiding this comment.
This change is incorrect, sorry. We render our USD render usd files as singular files, one big chunk instead of per frame - even on the farm because the files are smaller relatively (no duplication of the same data structure) and the server has better "in-memory" load of the one file and the USD files from render scene is usually small due to containing 99% references/sublayers instead of local geometry.
There was a problem hiding this comment.
Oh, I miss interpreted the meaning of that line!
So, in the current implementation "ifdFile" exists only if the render target was set to "farm_split" aka "Farm Rendering - Split export & render jobs".
So, this validator will crash for other render targets. because of a key error.
| # As long as we have one AOV then multipartExr should be True. | ||
| instance.data["multipartExr"] = len(files_by_product) <= 1 |
There was a problem hiding this comment.
This is technically not entirely true. It may just not have multiple AOVs and is then not multipart, right? USD Render Products are also completely capable of writing no beauty but only e.g. a Z-pass (even though you'd usually not do that I suppose)
Out of curiosity, why do we need this?
There was a problem hiding this comment.
why do we need this?
Well, searching for "multiPartExr" in this file pyblish_functions.py can answer the question.
As far as I was able to understand the logic. if there's one AOV, the logic will assume it's reviewable.
And I was merely trying to adopt the same logic.
server_addon/houdini/client/ayon_houdini/plugins/publish/collect_render_products.py
Show resolved
Hide resolved
client/ayon_core/modules/deadline/plugins/publish/submit_houdini_render_deadline.py
Show resolved
Hide resolved
server_addon/houdini/client/ayon_houdini/plugins/publish/extract_render.py
Show resolved
Hide resolved
client/ayon_core/modules/deadline/plugins/publish/submit_houdini_render_deadline.py
Show resolved
Hide resolved
client/ayon_core/modules/deadline/plugins/publish/submit_houdini_render_deadline.py
Show resolved
Hide resolved
|
Closing in favor of #10 |
Changelog Description
Support render targets for 'usdrender' product type
This also includes
Additional info
It works fine on my side.
But, for some reason I don't know yet, the jobs are submitted twice ?!
Testing notes:
usdrenderfrom Houdini using the four options:Reviewmark as reviewable.