Attach (Reviews) to multiple Subsets

Ideas
,
1

Introduction

Originally came up on OpenPype discord here

I wanted to start a discussion about the attachTo functionality that e.g. Maya Reviews support. It embeds a review into another subset, for example a review into modelMain so it comes with turntable or alike.

As I started working on Houdini Review functionality with #3839. To implement the attaching I was looking into how that actually works. As I understood the logic is set up to be, add instance.data["attachTo"] = "subset_name_to_attach_to" and it should then automatically attach that review to that subset.

Then I raised the discussion about being able to attach a single review to multiple subsets.

Attach to multiple subsets

In essence I wanted to be able to say this FX review is a attached to both pointcacheBodySim and pointcacheDebris because the video file contains both the body + the debris FX and thus is the review for both.

So reviewFX would be attached to pointcacheBodySim and pointcacheDebris.

Functionality wise it’d mean that if one wanted to see the review or state of a specific pointcacheBodySim or pointcacheDebris version that they would have easy access to its review file.

Auto-attach: Automatically detect related publishes to the review

An Artist on our also mentioned a potential “auto-attach” feature.

If the review instance itself could define what scene nodes/members are included in the Review (e.g. which nodes from Houdini or Maya) and other publish instances also state what members they are publishing. Then technically one could check where they overlap and automatically attach to the relevant publishes. Extra-epic if that would indeed be one of those links types that you might be able to ignore.

So you would have something like an includes link for the review, but related to those that are to be publish (not what are the inputs loaded). This could automatically be collected as described.
And you would have the explicit attached link for the review, like attachTo.

Naming convention

The attachTo functionality also raised some questions about the naming of these existing “attach”.

The names I’m proposing here are just first thoughts of course - I just matched it with attachTo that currently exists.
To me I intended them as:

  • attached (or attachTo): User explicitly linked this publish to another subset (or version, or representation?). User explicitly linked and said “this relates to X”
  • includes: Automatically detected “inclusion” of what is inside this publish that ended up in another publish. Unlike input links which link input containers that were loaded into the scene this links to what is a publish instance inside the current scene that was published along with this review. Publishing automatically detected “this includes (a part of?) X”

@iLLiCiTiT mentioned:

for me are both attached and attachTo doesn’t tell me anything :smile: how attached? for what reason? what it cause?
I wanted to say that I understand the request but I don’t know how the attachTo functionality works and what is for. And the name attachTo or attached or includes doesn’t tell what it’s attached to or why. My point is that the variable/key is not explicit, attachToSubsets would at least tell to what it’s attached to.
Identify what the key is for, during publishing, is hell if you don’t know the context. Instead of reducing them we’re adding more and more.

Additional discussion

@iLLiCiTiT also mentioned:

Is review link the only reason why it (red: attachTo) is used or there are other reasons?

AND

From what I’ve looked up now it’s based only on subset names. It doesn’t count with option to publish to different assets (so you can’t have 1…n instances with same subset name in context)

He raises some good points.