AYON Pipeline Early Access Beta - Publisher Workflow

Hi all,

I was curious what the rationale was behind allowing artists to decide which products they produce while publishing? In a pipeline I’m familiar with at least, it’s a lot more reliable to completely take away the power of the artist in scenarios like this and choose what products are created strictly via some configuration setting controlled by admin / the pipeline team of the studio.

I could be wrong about what you are asking, but here goes.

The reason to not ask users to for example export to an FBX or Alembic, is to abstract the publishing types (also called instances) to support different workflows needed by productions.
An example would be a model which can be represented by a number of different file formats (obj, fbx, abc), but working with the model data would be the same whether you are in Maya, Blender or Houdini.

Hi @tokestuartjepsen,

Thanks for the clarification. What you are referring to is the actual file type of the products (.FBX vs .ABC vs .MA for instance).
What I’m referring to is the “Create” tab generally and the artist workflow to be able to add new Products at publish time generally.
In my experience it’s best to leave this work up to a configuration engine entirely rather than allowing artists to configure these settings.

So you would like the instances in the create tab to be made without the artists interaction?

The general workflow is for the artist to tell the publisher what nodes/data to publish. Maybe you can write about your previous experiences so we can try and translate them to OP? For example how would the publisher know to publish node pSphere1 and not pSphere2?

Sounds like maybe Shotgrid toolkit experience?

@tokestuartjepsen

I see thanks. Yeah my studio currently uses Shotgrid toolkit as a baseline (primarily for basic tools like the App Launcher / and DCC tools like SG File Open / SG File Save), with a lot of proprietary tooling around that.

We currently use a tagging system to denote what particular nodes/data to publish in the scene. These are custom string attributes on nodes, that we can then search for when it comes to publish time.

At the end of the day though, for my studio, it comes down to the idea that an artist shouldn’t have to know what the next artist needs (in terms of the output files on disk). Rather than giving any control to the artist, we completely handle the configuration of the publisher’s products/subsets.

For instance, an animator (doing 3D rigged animation) shouldn’t have to know what an alembic cache is (or who is going to use it and how). All they have to know is that they run the publisher and give it a human readable description (so we know what changed) and they hit publish.

Instead of string attributes, OP relies on selection sets in Maya. Once you have created the selection set (instance), the artist can drag and drop nodes into the selection set for publishing.
If you already have some tooling to set the attributes, then it wouldn’t be a big job to assign those nodes to a selection set instead or as well.

You are right and in OP they dont have to know about it either. The publishing types like model is an abstraction to denote any geometry that needs to adhere to certain requirements like; no overlapping UVs, _GEO naming suffix etc.
Most artists dont know about all the publishing types, but only a select few that matters to them. For example the modeller only know about model and maybe render, and animator only knows about rig and review.

Sounds like a well-oiled machine :slight_smile:
Unfortunately there is only the custom coding route to take with this atm. You can easily fetch data from the scene and prep some instances for the artist.
You could also propose something like this as an idea for the Ynput team to digest. And you could also try getting on a support plan with Ynput and request something like this.

For rigs in Maya specifically there is a loading mechanism that’ll create an animation instance from the loaded rig. This happens when you load in the rig.
This means the animation does not need to setup any for publishing the animation (alembic) cache. BUT there is currently no such auto created instances when it comes to reviews (playblast).

Just to see what you mean, I tried this out real quick. But hit an error.

I was in a rig workfile, created a basic rig with a single cylinder and a control (parent constrainted the cylinder to the control), grouped them under a ‘master’ group and opened the publisher. After opening the publisher I went back to the “Create” tab, selected the ‘master’ group node, and added a “Rig” instance. I then ran the publish.
Afterwards I opened an empty file, went to AYON->Load and attempted to load the “rigMain” product that was just created. I was then greeted with this error. Is this something you can reproduce?

Using:
AYON Server v0.3.1
AYON Desktop v3.16.0
Windows 10

Ahh yea, you are hitting some bleeding edge issues now. Resolved in this PR; Maya: Hide CreateAnimation by tokejepsen · Pull Request #5297 · ynput/OpenPype · GitHub

@tokestuartjepsen

Ah I see, glad to see I’m on the cutting edge :smile:

Is it also a known issue that when you change file contexts via the AYON -> Workfiles menu and then reopen the publisher, the publisher still thinks you are in the old context?

For example, I’m in asset A and run the publisher close the publisher and then switch over to asset B via “Workfiles” and reopen the publisher, the tool still thinks I am in asset A.

Question for @iLLiCiT

I tested in OpenPype (I believe it runs the same Maya addon/integration)
The publisher seems fine! it refreshes and update UI properly.

I use version 3.16.1

It may not auto-update without refresh. That can happen if you have opened Publisher and Workfiles tool at the same time.