Best practices for PublishedFile and Version entities

Pipeline Integrations
1

Shotgrid is enormously flexible, and partly due to this the best practice arrangement of Version entities and PublishedFiles remains a bit unclear.

First, the documentation for Producers emphasizes Tasks, Versions and Notes. Makes sense, but there’s no detail regarding PublishedFiles. This kind of suggests that, yeah its ok to use the system without published files, taking advantage of all the other capabilities.

Second, within Toolkit itself, Versions are clearly intended to be linked to PublishedFiles, but its so flexible its a bit unclear what kind of “best practice” ground rules could be applied. On the one hand a Version can be related to a PublishedFile from which it originated, but… do the rendered movie/frames themselves get a PublishedFile?

I’d like to test my understanding by asking if a best practice here might be to link together the originating DCC’s PublishedFile to a PublishedFile encompassing a render, and then giving that latter a Version entity, in cases where the rendered output itself is a product used in later steps.

In situations where this is not the case, e.g. a Version entity used purely intended for review purposes, there seems less motivastion to provide it a PublishedFile distinct from that of the DCC which made it.

2

It really depends, and I guess every studio does it differently.
We do not publish movies and frames, because they are already present in the Version.
There are other cases, for instance render scenes like USD, IFD, etc. which are used as intermediate formats. For us, these do get published, linked as downstream from the original scene publish.
Then the Version links to the intermediate scene Publish. This forms a tree of entities, with which the process can be traced back when needed.

tldr: for me publishing the movies and frames would be redundant.

1 Like
3

I do usually publish every file because we could have variations of things we generate extra for a publish or a Version.

Or we generate later.

For example:

  • Comper Publishes Version (internal frames publish)
  • Frames get auto-transcoder to a internal Dailly with internal slate and burn ins (internal mov publish)
  • Once we want to send it to the client, we generate a client version, according to the client specs, with slate notes (sanitized by production) and any details on the slate and burnins that the client wants, we replace the playable media and create a Client Version Name. (client movie published file)
  • Client asks for exrs → we export the exr’s in client specs/naming and once again publish (client frames publish)

When it comes to storage usage, we can now target very precisley what we want to keep and what we could archive or delete based on statusses and related tree data.

1 Like