Instances with multi-family support


#1

image

Goal

Facilitate the use of external plug-in(s) in existing publishing pipeline.

Motivation

Installing someone else’s plug-ins currently requires you to architect your content according to the families provided by those plug-ins.

That’s fine, assuming this is the first and only series of plug-in you install and that you start from scratch.

But what if you already have a series of plug-ins and things are working well? You are just interested in appending a few from an external source that help with one or more issues?

Well, with this you can.

Usage example

  1. Install new validator, with support for familyX
  2. Append familyX to relevant instances in your Collector.

Or better yet, have your collector remain general enough to derive familyX from the content somehow, such as picking it up from a user-defined attribute in Maya; as in Magenta.

Implementation

An implementation is fairly straightforward, an Instance is already capable of hosting arbitrary data so we’ll add to that.

instance.data["families"] = ["geometry", "human", "primary"]

The mechanism currently in charge of determining compatibility between plug-in and instance is called instances_by_plugin and will be augmented to also consider the new families data entry.

For backwards compatibility, the current family will remain and involves no overhead and little cost to maintenance (about 4 lines of code at a near location).

Discussion

This is a feature that changes some major ways of thinking about how to orchestrate many plug-ins. But @BigRoy pointed out some concrete flaws in the current system of a singular family which basically boils down to an inability to make use of Magenta without making large changes to an existing eco-system of both plug-ins and how content is created.

It’s possible that this feature can eliminate that concern, that all one has to do to work with an external plug-in/series of plug-ins is to simply append, or “tag” instances with the additional families that it could relate to and have the corresponding plug-ins trigger.

What do you think, does this make Pyblish a stronger (more powerful) or weaker (less focused) framework?


#2

I like it. Certainly adds more flexibility to the whole framework for very little effort on both developer and user side.

:+1:


#3

I certainly think it’ll make Pyblish stronger.

Is the aim of this to get closer to a plug’n’play system?


#4

Yeah, I suppose it’s always been about plug-and-play but it’s been difficult to test without much to plug-and-play. Magenta is one of the cornerstones in this that I’d like anyone to be able to install, much like they were to install a plug-in to Sublime or Atom. Effortless.

We need more extensions like this to really hit it home!


#5

I’ve actually been “sidecarring” (is that the word?) on Magenta for a couple of projects right now. Especially because I’m digging its instance collector (that can pick up any type of family in Maya) based on an objectSet. Unfortunately the whole of Magenta is of good interest to me, but haven’t been able to take it as one full piece into any real-life production. Nevertheless I’m using a good part (basically excluding what is pipeline specific like some Integrators) mixed throughout different types of projects.

Magenta is also housing some very small tools already to easily create instances in a scene based on a set of predefined family types. And this is already extensible in that a family can come with its own predefined attributes on the set. Have a look at its instance creator. I also added the “publish” boolean attribute by default so I can always easily toggle on/off in the scene) So far it’s been really nice to be able to quickly toggle some things on/off in a scene to perform extractions.

Similarly I have some scripts (and again, these are really just one or two lines of code) to highlight the instances in the scene that contain e.g. one of the selected nodes. This makes it easy to run a publish of content only related to some instances in the scene (instead of toggling in the UI, etc.)

I hope we can get to a point where others love some of the things in the Magenta repo. Then they take the repo and without altering the content of that repository be easily able to mix-and-match the plug-ins in it to use it in their own pipeline. (Especially a lot of Validators can be useful in a wide range of uses).

I’m looking forward to using this and see where I can really reap the benefits!


#6

I’ve actually got a use case for this now in Hiero:)

Is this implemented? Saw it in the developer guide, so assumed it was already in there.


#7

There is an implementation for it, but it hasn’t been very well tested yet, I wrote it specifically for the guide.

You can give it a try by pulling from my personal repository; if it works for you (in the GUI particularly) then it’ll likely be committed sooner.


#8

I have pulled from your repo and it works when not using the GUI. I’m guessing the GUI part of the implementation is missing?


#9

The GUI is using the same implementation, the same library and all, but it’s running it from another Python process.

Make sure this other process doesn’t pick up your other, older, version of the pyblish library. That can get a little tricky… the pyblish-win distribution will default to using it’s own interpreter which puts it’s own modules on the PYTHONPATH, shadowing whatever you’ve put there manually.

The best thing to do is to not involve pyblish-win, and use the repos individually, as in the Developer Guide.

Granted it’s not terribly pleasant, and we should really find an easier way of overriding individual repos this way. If you think of anything that could help, let me know.


#10

You are right:) False alarm.

Needed to clean out pyblish-win, to make sure it was running the individual repos.


#11

Hey @tokejepsen, how has it gone with this? Does it work?


#12

Im still developing, so the code isn’t in production.

It is definitely working, but I haven’t tested it extensively.


#13

Ok, let me know how it goes.


#14

This is working really well. Its perfect for the Hiero workflow where you tag items to export.


#15

That’s really great!

I’m just about to push an update to Pyblish now, I’ll include this then. :slight_smile: