Sweet beans, thanks for sharing your insights so far.
I think it all sounds completely natural and in-line so far. I could share some thoughts, but I'd stress that they would mostly be suggestions to an already well defined workflow.
Plug-ins are generally intended to be as small as possible, and work together, rather than become merged, so that fact that this had to happen sound to me like a fault in the GUI and something that should be fixed. As @tokejepsen and @mkolar mentioned, we've stumbled upon this problem before.
In addition to the forum post on the topic, there is also this.
At the end of the publish I have an integrator which writes a json file of the context.data dictionary
Good idea. I'd include the
result dictionaries as well, for future auditing or just archival purposes. They capture absolutely everything about any publish, including timestamps and performance counters. You can serialise it to a JSON-compatible dictionary using
I've wrapped the ui launcher in order to control which plugins are loaded,
This may be the only real deviation from Pyblish standards and practices.
The overall design intent of Pyblish is to discover what data is available, and offer the user an option to publish it. As in, if there is a model (the simplest example), a model instance would appear. If that model instance supports extraction to one or more formats and representations - e.g. one
.ma and one
.maProxy - then (optional) extractors would appear to give users the option of publishing it to those.
The same should apply to any and all types of data.
Families are meant to solve this by having your collector identify a model for what it is and then provide support for it via additional plug-ins.
I think the most successful method of solving this gracefully, is having a generic collector run across your scene, and have your assets make an effort in identifying themselves. As in, the artist or technical director could "tag" various parts of their scene and tell them what they are supposed to be. The generic collector could then read this/these tag(s) and apply families as appropriate.
These tags could even be the families themselves. (Both plug-ins and instances may have more than one family)
Napoleon is an example of this in action.
It also has an example Maya project.
I know @BigRoy wrote a visual tool to help TDs make these tags, out of a selection of available tags studio-wide. That might be similar to what you have already with paths, except in this way the specification is associated with the asset itself, rather than with a particular running session of Maya. Maybe you could share some pictures of yours, Roy?
Puppets and other assets have a node which identifies them as an asset, but they also contain other assets.
I've run into this problem before, and I think the most graceful solution I've seen has been to look at their hierarchy. Is the asset a parent or child? If child, either collect an instance that is unchecked by default, or don't collect at all.
That way you'll be able to nest assets arbitrarily whilst still maintaining control.