# Determining publish name and type from the user?

#1

Just evaluating pyblish today, and there’s something I’m not understanding because I either haven’t come across it yet or I have and didn’t comprehend. It might also be because I’m stuck using pyblish-light at the moment because I don’t have access to pyqt5 yet. The Maya examples I’ve seen use things like naming conventions or sets to define what an asset is and therefore how it should be published. Is there a way of just asking the user for this information? For example if you have a rig in your scene you could want to publish a rig, or you could want to publish animation. Or if you’re publishing something that wouldn’t have been named or organized properly yet.

#2

Think you have two options for this; tool for tagging or context launching.

Tool for Tagging

You could make a tool, where you ask your user what they want to do, and either tag the objects or organize into sets etc. This does require a bit of development though, but you would be able to ask the user about anything, and for any objects. I personally haven’t seen this method in use, although I think maybe pyblish-magenta was making use of something similar.
@marcus and @BigRoy would know better:)

Context Launching

Here you would organize your Pyblish plugins, so there are a set for modeling, rigging, animation etc. When launching Maya, or any host, you would only add the plugins relevant to that task. This way you can assume that the user wants to publish a model, rig or animation, and so you help the user organize the scene.
We current make use of this method for modeling in pyblish-bumpybox.

Hope that gives you some more options to work with.

#3

Hi @morganloomis, and welcome to the community!

For example if you have a rig in your scene you could want to publish a rig, or you could want to publish animation

In addition to the tips and tricks from @tokejepsen, you could collect both the rig and the animation, and allow the user to toggle which to publish interactively.

If one if more preferred than the other, you can define their default “checked” status via the publish data member to an the instance during collection, and the GUI, both Lite and QML, will assign the value to the corresponding checkbox.

my_instance.data["publish"] = True


#4

About this. In Pyblish terms, this would, by definition, fail validation and not be allowed to be published.

#5

Thanks for clarifying guys. Does the UI handle this sort of toggling natively, will it show everything that is returned during collection and you can choose what you want to publish?

For smaller studios where artists wear several hats, is there a workflow for changing “modes” from modelling to rigging to animation without restarting? If there’s not a way to set up plugin groups in the UI I’m thinking basically having different UI launch wrappers which load a different set of plugins, does that seem feasible?

#6

ooh, just found this thread which goes into this a bit. I’ll reply over there.

#7

Yup, every instance you create when collecting will show up in the UI. Then its up to the user to choose what to publish.

You could definitely do this. As the plugins are just registered from PYBLISHPLUGINPATH, you could add/remove when changing modes.

I would probably more look at collecting everything you need from the scene, and let the user decide what to publish. You could have a model instance if you detect any non-referenced meshes in the scene, rig instance if you have any skinning or constraints, and animation is there are any animated channels.
Although you would be leaving a lot of decisions to the user, which is why we went with context launching.

#8

Would I need to de-register plugins, or is resetting that environment variable enough?

#9

Setting the variable is enough, Pyblish refreshes the registration of the plugins every time you hit reset in the UI.
Just to clarify if you were in modeling mode, PYBLISHPLUGINPATH could look like this; \path\to\modeling\plugins, and when in rigging mode it would look like this; \path\to\rigging\plugins.

Granted I haven’t personally done this, but that should work in theory.

#10

I’m going to try this today if I can, I’ll let you know.

#11

This is working just fine btw.

#12

What solution did you end up with? Did you make a context switching tool?

#13

Having different launchers which set the PYBLISHPLUGINPATH just before running the UI. It may ultimately not be needed, but is working for now.

#14

Sounds like it’s right on the money, thanks for following up!