Creator / Publisher Overhaul

We’ve been talking for quite some time about making the publishing experience simpler to understand, more consistent across the hosts and in turn, more capable.

This is a suggestion coming from internal pype.club discussions on how to deal with this.

Why we need this?

  • With the addition of new hosts many of which have no good support for storing extra metadata on scene objects, we have to resort into storing this on various places where the user doesn’t have good access or no access at all. As a result of that, the user has no good way to inspect or remove instances once they have been tagged for publishing
    • Photoshop - json in file metadata (limited user access)
    • Harmony - json in file metadata (limited user access)
    • TV Paint - .ini style formatting of metadata in the file itself (now user access)
  • Having Unified GUI for this would make it easier for users to adapt to other hosts. Lot’s of artists have to jump between Maya, nuke, PS and so on, and currently, they have to remember how the instances work in each host, making it a lot harder to jump from host to host.
  • Much easier integration of new hosts. Instead of thinking, what do I use to store metadata on the instance, you just need to figure out where to dump a single JSON, that holds all Avalon scene metadata. Instances and containers alike possibly.
  • This doesn’t hinder the possibility of storing the metadata on nodes directly if the hosts support it, so for Nuke and Maya, nothing would need changing.

Requirements

  • Create new publishable instances
  • See all existing instances in the scene
  • See all objects within the given instance
  • Remove existing instances
  • Change publishing parameters of existing instances

The whole idea here is to create a one-stop shop for publishing that is consistent across the hosts.

Here is a starting point for this re-design. The board should be open for public comments.

Creator/Publisher GUI overhaul Miro Board

A screen from the miro board to show the direction we’re thinking of taking.

Good idea with with unifying the instances interaction!

Will pyblish-pype appear when you hit “Publish”?

Current idea is that it wouldn’t. I think the ideal scenario is that the publishing happens technically headless, reporting back to this UI (it’s visible on the miro board) and if something goes wrong, it only reports that to user in a simple readable manner. After the publishing you could however switch to the pyblish-pype (second tab), to inspect what happened if you are more technical user.

What would the artist facing error report (UI) look like? What happens when something needs repairing?

Artist facing errors (not validations) are utterly useless. It comes back to TD or our support 99.9% of the time. And right now the same goes for all the cryptic validations.

There’s another important pain point this would solve. It would allow going back to fully data driven publishing. Right now artists can choose which plugins they want on or off, which is hard to explain usually. This way, there would be no optional plugins and they would be triggered purely based on the pre-publishing settings of the subset itself.

Added bonus is that headless publishing would be producing identical results to GUI, considering the plugins to run would always be the same.

There’s another important pain point this would solve. It would allow going back to fully data driven publishing. Right now artists can choose which plugins they want on or off, which is hard to explain usually. This way, there would be no optional plugins and they would be triggered purely based on the pre-publishing settings of the subset itself.

I’m guessing you would still have control over optional plugins if you went to the details panel?
We, sometimes, need to omit certain validators (frame range is probably most often) to get a task out. This workflow certainly can be improved with various actions or repairing, but in a pinch disabling a plugin is easiest.

Yes that’s exactly how I would imagine it. If you know what you are doing and want more control. Details tab, should give you that option.

This re-design should be able to replace the standalone publisher because it has everything (and more). The current standalone publisher could really use the subset attributes section.

On this note, this publisher should be able to point to files on disk, but maybe that is the creator plugins job?

I’m trying to figure out how to make it nice and easy to populate it with representations and subsets, while in Standalone mode. It’s probably going to require a step before it gets to this GUI, similar to what we have now. Lot’s of moving parts

We’ve moved quite a bit further with the publisher design. Any comments would be appreciated. To see the details and comment please head to the public Miro board GUI Mockup - Publisher

The new GUI looks great! Wondering about possibility of headless standalone publish.

It would be great to have an option of “bulk ingest” with folder full of plates, renders… and csv file defining asset, family, name…

Or maybe just some functionality to parse asset, name… from the filename via regex?

For editorial that is actually fully possible even with current standalone publisher.