1

Entity-Specific Publishes (aka "Levels")

Ryan Mayeda

July 28, 2015 16:15

None

Follow

Several clients have asked about the concept of "levels" in Tank, where specialized publishes (usually of Assets) should be used when working on Tasks for a given Sequence, Shot or other entity.  For example, a given Asset like the 'DiningTable' will have a (latest) model publish that should generally be used anywhere within the Project.  But, a particular Shot, like say BB0010, might need a specialized publish of the 'DiningTable'.  To cover this, Tank would need to recognize this use case and be aware that the specialized publish should be loaded when working on BB0010, but the regular Asset publish should be used elsewhere.  Additionally, this specificity should be hierarchical, so a Sequence-specific publish could be used for any Shot within that Sequence (rather than doing the same Shot-specific publish for each Shot within the Sequence).

While this functionality isn't in Tank yet, the attached diagram sketches out how it might work.  As part of the implementation, Shotgun would in turn get some extra schema to track the entity linkage specificity, and a big design goal would be lay things out in a generic way so that different studios could define the "level" hierarchy and relationships as they see fit.

It would be great to get feedback on this idea and approach, as well as more detailed use cases!  We also have a few questions for folks interested in this workflow so we can make sure we're in line with the way people want things to work:

1. For the case where the same publish should be specific to multiple entities at the same "level" (i.e. this publish should be used for these two Shots), is it ok for the this to result in separate publishes (as in the diagram)?  In essence, this means that each publish can only have one "level," but that "level" could cover multiple leaf entities through the hierarchy (i.e. a Sequence-level publish would affect multiple Shots, any within that Sequence).  By doing this, the file structure on disk would always be consistent within its context and data relevant to a "level" would reside in the same place, which might clearer and help avoid confusing questions about what can/can't be offlined.  The tradeoff is that data would also be duplicated.  So far, we've asked a few clients and this felt like the best balance - what does the group think?
   
   
2. Should the entity-specific schema also apply to review material (i.e. Versions in Shotgun)?  When reviewing a Shot-specific model turntable, should it be linked to the Asset and have a "level" designation just like the publish, or should it just be linked to the "level"?  Should Notes be linked to both the Asset and the Shot?  Currently, Shotgun's Note-taking tools would only link them to what the Version is linked to, so it wouldn't pick up the "level" as well, should it?
   
   
3. Does the name "level" feel right to everyone as far as vocabulary goes?  We've started with this term because a few of the clients that asked about this workflow call it that but we're open to other ideas.  Let us know what you call this if it's different!

Ryan.

tk_entity_specific_assets_v1.pdf

• Facebook
• Twitter
• LinkedIn

3 comments

• 0
  
  Stephane Deverly July 28, 2015 19:16

  Hi there,

  here is what I think :

  1) Yes, let's duplicate data, keeping things simple

  2) and 3) I thought a ShotAsset custom entity would be used, linked to the asset and the shot. Everything ( version, note, publish file ) would then be linked to that entity. Wouldn't that answer 2) and 3) ?

• 0
  
  Ryan Mayeda July 28, 2015 19:16

  Ah, so do you see this "levels" case as essentially the same setup as the "instancing" case where you would use the same structure to track if, say, the same asset appeared in a shot multiple times (ex. you're in a restaurant, so there are a bunch of DiningTable assets spread out through the scene)?

  When I originally made the diagram, I was thinking of them as distinct cases that could work in conjunction but wouldn't necessarily have to.  Maybe I need to rethink that, or at least flesh this out so the design includes the "instancing" case as well?  In some of the discussions we've had with clients about this topic, the need to define hierarchies of specialization was a big need so this diagram skewed more in that direction.  Let me know if I'm understanding you correctly and I'll go another round on the diagram for discussion!

  Ryan.

• 0
  
  Stephane Deverly July 28, 2015 19:16

  I think instancing and level overriding could be handled with the same mechanism. Let's say that in shot 001_001 you have three dining tables and one character ( Raymond ). We would create 4 shot asset instances, to define the shot breakdown, and be able to give to each asset instance its instance name in the shot : diningTable1, diningTable2, diningTable3 and raymond1, allowing to make sure that dining tables are always named the same way when loading the shot in ( for example ) Maya. If diningTable1 is animated, animations and animation caches would be published against the diningTable1( 001_001, DiningTable ) instance.

  Now, let's say you need a special version of the model for diningTable2. You would publish this model linked to the diningTable2( 001_001, DiningTable) entity. When loading the shot, the rule would be : if there is a model attached to this entity, use it. Otherwise load the model attached to DiningTable ( the asset ).

  People might want to be able to define hierarchy overrides : a shot is in a sequence, which is in project. So they might want to be able to say : if nothing specific at the shot level, check at the sequence level, and then go for the project level if nothing at the sequence level. Although, this could be achieved by adding specific versions in all shots of a sequence, keeping things simple.

  Hope it makes sense !