I’m looking to implement a Maya Alembic camera publish option in tk-multi-publish2. I watched the tutorial here which was quite helpful.
One thing I’ve noticed though, is that while I can have multiple publish plugin hooks for various purposes (eg. publish_camera.py and publish_shader_network.py here), it seems that there can only be one collector.py.
I attempted adding more than one to the tk-multi-publish2 config as below, but it seems like the multiple paths override each other.
(in this case, only collector_camera.py seems to be run)
I’d love to be able to avoid copying and pasting whole files to my config, since it means that I would miss any updates that are made to the default collector.py, and it’s just extra stuff that I need to maintain. In a perfect world it would be great if SGTK provided some common collector classes in the default tk-multi-publish2 that I could subclass into small modular collector plugins without duplicated code.
Is this correct, or maybe I’m doing something wrong?
In a way, you’re correct in that you can only have one collector per Publish2 settings block, unlike the plugins where you can list multiple. However, you can use inheritance to subclass the base collector plugin.
When setting the hook paths you can define a chain of inheritance by separating the paths using :.
In your example, the order of inheritance is (from base to subclasses)
The collector from the publish2 app ({self}/collector.py).
Then you have the engine’s implementation of the collector {engine}/tk-multi-publish2/basic/collector.py
Then your mesh collector {config}/tk-multi-publish2/maya/collector_mesh.py
And finally your {config}/tk-multi-publish2/maya/collector_camera.py
So in this situation, the collector_camera.py needs to ensure that it calls super per overridden method so that the collector_mesh.py method gets called, and likewise, that needs to call super if you want the engine’s implementation of the hook called.
The tk-maya implementation of the collector does this for the settings property:
I did see that before but I assumed that sgtk.get_hook_baseclass() would just get the default class defined by the plugin but I just tested it out then and it does what I want!
It wasn’t clear to me before but after looking in the Hook documentation I think I understand it now, the order of inheritance of hooks is defined by the environment config .yml, and the base class retrieved by sgtk.get_hook_baseclass() becomes whatever is the hook class that’s defined in the previous file in the .yml ‘collector:’ path list.
I think I have this working quite happily now, with much less code to maintain!
I did have to do a little bit of extra work to find the correct parent_item to add my camera item to in process_current_session()
def process_current_session(self, settings, parent_item):
super(MayaCameraCollector, self).process_current_session(settings, parent_item)
# find the maya session item to attach to
session_item = next((item for item in parent_item.descendants if item.type_spec == 'maya.session'), None)
if session_item == None:
return
self._collect_cameras(session_item)
It might be nice if the default process_current_session() inside tk-maya’s MayaSessionCollector returned the item so that subclasses could continue attaching to it? Is there any recommended way to make small requests like this? A PR against the Shotgun Toolkit github repo?
We are looking into putting a guide together to compliment the reference documentation, so hopefully, this will make it clearer to others in the future. And yes your understanding is correct!
I’ve popped a suggestion into our product team on your behalf, and of course your more than welcome to submit a pull request. However, I’m not sure my self how much that would help, the reason being is that the process_current_session method could create and link multiple items to the parent item, and those items, in turn, could have child items, so you would need to return back either a dictionary or perhaps a flat list of items, which you can essentially access through the parent_item.descendants.
