Using the publisher in reverse

Hi everyone!

While investigating ways of packaging data for final delivery I had this kind of crazy idea to use the publisher in a “reverse” kind of manner. Let me explain what I mean by that: usually you use the publisher to bring data into the pipeline, but what if you bend that logic to export data out of the pipeline?

I imagine it like this:

  • drag and drop a link to a SG version to the publisher
  • that gets displayed as a publish item
  • a custom publish plugin exports the “path_to_frames” (or whatever) to an external folder.

The drag and drop logic for links does not exist at the moment, but could be added with little effort,I think.
The publisher API is powerful enough to make the rest work.

So my question is: did anyone already do something similar to that? Is there maybe something that I don’t see that would make this impossible?
And maybe more general: how do you handle exporting data from the pipeline for deliveries to a client?

Thanks for your input! :slight_smile:

We have a packaging pipeline that grew quite a bit over time.
Currently we use AMIs that trigger actions on the local machine. This in turn in most cases triggers Deadline farm jobs that do the actual work.

There are many degrees of packaging, for instance you might want to rename assets to match a client’s naming convention, generate metadata files for easier ingestion on the other side, and so on.

Just to mention it, SG has a Delivery entity, which you can leverage for collecting the final results in one place.

No idea what would be required to support drag’n’drop onto publisher controls - if Qt supports it then it should be doable.

3 Likes

Hi @mmoshev !

Thanks for your reply and insight of your workflows!
We actually have a very similar approach with AMI’s and Deadline jobs. The issue we face is the development time it takes to keep it kicking. So we are looking left and right to see if we can come up with something better. Really not easy with all the custom extra wishes from clients… :grimacing: .

Using the publisher allows you to easily choose a context for things, if it cannot be inferred automatically (otherwise an AMI would be better).
The publisher UI customization was a bit hit and miss, but it’s fine for simple cases.

So in your view, do you still see the publisher submitting to Deadline or performing everything locally?
It is significantly better to offload the heavy work to Deadline, so the workstation can be used for something else.

I would definitely let the publisher send jobs to deadline. Since forever I wanted to send the actual publishing process entirely to the render farm. This would be possible with the publisher API, so it might be worth investigating some more. Anyway, I will find a way to implement what I want.
Thanks for your input, @mmoshev

A bit late but I can confirm this works fine.

We have used this to send exports to the farm for ages.
You just create a custo collector with a UI maybe that allows you to select a playlist and then create whatever “fake” items you like :slight_smile:

1 Like