Flow control


Hi, started playing with pyblish, and trying to get my head around few processes.

I’m trying to get something complex published from within DCC applications (take maya for example), and I need to be able to define a given workflow of events, which will get to the final publish.

I’ll try to break it down so is more clear.
What I got so far:

  1. contextPlugin which collects options and geometries for alembic
    1a) and instancePlugin, that given options expressed in the context, will publish the alembic.

  2. contextPlugin which collects options and geometries for mayaBinary
    2a) and instancePlugin, that given options expressed in the context, will publish the mayaBinary.

I now want to publish a camera in MayaBinary and Almebic.
Problem is I need to be able to run various pre and post processors depending on the options which has been set on the contex.
So for example I can have an option which define whether the camera has to be baked or not.

the idea would be to have an pre-instance and post-instance which gets activated only when that options is active
but these has to be going all before and after the MayaBinary and Almebic step .

To recap:

  1. set options
  2. evaluate options
  3. depending on options add pre-instance
  4. run one instance MayaBinary
  5. run the other instance Almebic
  6. run the post-instance process

Now, I can think of a simple solution for this, but what If I have some other options which requires pre and post ?
How can I explicitly define the flow between instances ?

Hope it does make sense.


Hi Lorenzo! Glad you could make it. :slight_smile:

To solve this one, I think we will need to make a small change to how plug-ins are organised.

At the moment, each collector is coupled with an extractor. Instead, I would suggest you think of what you are collecting not as files, but as types of data. In this case, the type might be specialCamera.

The specialCamera

A specialCamera has a particular layout in Maya. Maybe it consists of the Maya default node camera along with a few attributes, such as whether or not it should be baked.

from maya import cmds
camera = cmds.camera()
cmds.addAttr(camera, longName="shouldBeBaked", dataType="bool")

Now you’ve got a camera, now let’s make a collector for it.


from pyblish import api

class CollectCameras(api.ContextPlugin):
  order = api.CollectorOrder

  def process(self, context):
    for camera in cmds.ls(type="camera"):
      instance = context.create_instance(name=camera, family="special.camera")

      # Include each related node, in this case, just the camera

      # Include user-defined attributes
      for attr in cmds.listAttr(objset, userDefined=True) or list():
        value = cmds.getAttr(objset + "." + attr)
        instance.data[attr] = value

Finally, extract this camera into the formats you are interested in.


from pyblish import api

class ExtractMayaScene(api.InstancePlugin):
  order = api.ExtractorOrder
  families = ["special.camera"]

  def process(self, instance):
    cmds.select(instance, replace=True)

    # Collected data determines what to do
    if instance.data.get("shouldBeBaked"):

    cmds.file("/my/file/path.ma", ...)


from pyblish import api

class ExtractAlembic(api.InstancePlugin):
  order = api.ExtractorOrder
  families = ["special.camera"]

  def process(self, instance):
    cmds.select(instance, replace=True)

At this point, the collector manages what gets extracted, whereas the extractor only bothers with how.

Let me know how that sounds!


mhhh ok.
Not sure is exactly how I would like to use it , but I’ll give it a go right away, also with multiple options.

What about the post process where I delete the camera and restore the original one ?
Should I be having a extractor with higher order value ?


One of the strengths to this approach, is that you can add or remove extractors, without affecting the surrounding plug-ins. If, for example, you one day decided that you also want your cameras in Atom format or the like.

With this particular collector, one of the problems you’ll find is related to - how do you make your specialCamera stand out from other cameras?

In a real scenario, such a camera may be a rig, in which case you could filter the results of cmds.ls() by something unique to this rig. In simple scenarios, it may be as simple as going by convention and suffixing each specialCamera with something along the lines of _CAM - e.g. main_CAM.

The most successful approach in Maya pipelines that I have seen has been to put the camera into an objectSet and treat the objectSet as an instance. The contents of the objectSet can then directly correlate between the contents of the instance, and what ultimately is extracted onto disk; including used-defined attributes to customise the plug-ins at run-time.

Pyblish Napoleon, Pyblish Magenta and Pyblish Starter each utilise the latter approach.


Technically, it doesn’t matter, anywhere will do.

Conceptually however, having an extractor (or publishing as a whole for that matter) modify state is frowned upon and should be avoided.

In this case, you could subprocess a new Maya, where you perform modifications to the scene without altering the original, and finalise the extraction from there.

In other situations where modifying global state is unavoidable, such as when writing to a temporary directory on disk, cleanup is usually handled after integration, with an order of api.IntegratorOrder + 0.5 or the like.


Hi , thanks for the reply!
I still have to try what you suggested, but I think it does make sense in this perspective.
(although I fear might raise a bit the complexity of the system once I have all in place with 10+ assets with specific or reusable pre and post scripts). Anyhow, I’ll have a proper look at this, so I can clear my head about this potential issue.

For the other suggestion, I don’t (and can’t ) use sets for selection, all has to come from the whole scene or user selections.
Sets , as much as prefixes as suffixes a winning method for established pipelines and workflows , but is too much to enforce for single users (sometimes even in small studios), which might be working on a inconsistent set of assets or scenes.

Thanks again for the help.


Agreed, and I hear this a lot. The challenge is making not difficult. One method of doing this, is via tools that can help the user create these sets from their selections.

I’m very happy you asked these questions and raised these concerns, as it is just what I’ve been working on for pyblish-starter - to demonstrate that safe and valid content really can be produced even by the smallest of studios.

Stay tuned, making an announcement soon.


Hey @lorenzo_angeli, the project I mentioned is up! It’s a good example of how I envision users to interact with the otherwise complicated setup of their assets, in any-sized studio.

Let me know what you think!


cheers , sorted with the priorities :slight_smile: