Options for plugins


#1

Hi,

I want the extractors to have some options. E.g. as in Pyblish-magenta ExtractAlembic, it has a few options like noNormals, that the user may want to set.
After some research I found these links.

So I want to set options for plugins in context and per instance (I want to export normals for Bob, but not for Alice) and I want to use the pyblish-qml as gui. How should I do that?

One thing comes to my mind. Create a preprocess gui before starting pyblish. It would show the options, and set them in the scene (maybe on the export set), then launch the pyblish-qml. But it would mean, my preprocessor gui should run the collectors, and also gather all the VEI plugins to show their options. Then we are just one step away from rewriting the whole pyblish gui, which is not what I want.
Unless you tell me, there is no other way… :slight_smile:


#2

There is currently nothing like this for Pyblish. As you said it has been discussed before and would be very welcome addition to Pyblish-QML (hint :slight_smile:)

I have been using custom attributes in Maya and Nuke when users wanted customization over the submission/publish. It has worked where a validator and action ensured the existence of the attributes, which the user would then go back and customize.
Not ideal so a solution for Pyblish-QML would be great :wink:


#3

Have a look at how Avalon deals with this; in a nutshell, you graphically author instances and set options there. That way, options are picked up during publishing, like any other attribute. The options then are per instance, or family, where they belong. Such as options for a Model, or a Render etc.

The screenshots are a little out of date, but the practice has worked well.


#4

Also some more context here


#5

Thanks for the information!
How would one start working on an issue like this? We would need to discuss further specifications.
I can see two parts of this.

  1. Implement options in the API. The structure in pyblish-magenta’s extract_alembic seems as a good start.
    Although we need something for context options and per instance options. (Or do we?)
  2. GUI. And I think this is the bigger part. To my best knowledge, you can’t see plugins collected for individual instances, so this is something that has to be implemented.

#6

Start with a simple prototype. Something standalone, separate from Pyblish, that proves the concept.

  1. Both instances and context have a .data dictionary, which I think is a good place for options. E.g. context.data["isAwesome"] = True
  2. You can, api.discover() will get you all available plug-ins which each have a .families list, and an instance has a corresponding instance.data["families"] list. If these have a shared member, e.g. they both share “model”, then they are meant for each other.