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.
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.
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.
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
