…where the first is equivalent to publish_session_geometry.py, and the second is similar except the internals write out an Arnold standin rather than an Alembic, and both have class names that indicate what they do.
I’ve also modified ..\config\env\includes\settings\tk-multi-publish2.yml in the Maya asset step section to trigger the correct hooks, and have added publish template paths for each in ..\config\core\templates.yml.
Lastly there are some UI tweaks, screencap for clarification:
The issue I’m running into currently, is that when I test with Validate, both the Publish Alembic and Publish Arnold Standin tasks are showing that they’ll resolve the output file path and naming to be whatever is described in the asset_arnold_standin template publish definition, which is wrong for alembics.
From testing, it seems that whatever the order of publish plugins is in tk-multi-publish2.yml that resolve as a child of a given item in the UI (here All Session Geometry), the one that comes last is the publish template that ends up getting used for both (e.g. if I switch it so that A follows B, the publish template for both ends up being the asset_alembic_cache definition from templates.yml, which will be wrong for Arnold standins). Also, if I eliminate one or the other, I get the desired results specific to the one that remains.
Interesting. I think we would need to see your plugins to be sure. But are you storing the path you want to publish on the item like we do here?
If so then both plugins will be overwriting the same setting, I think you would want to use local_properties instead so that both plugins don’t overwrite each other.
For some yet-to-be-ascertained reason, all of the plugin items in the All Session Geometry stack are inheriting values on common properties based on the values of the last item through the stack, so I have been unable to use e.g. item.properties["path"] and the like. For the same reasons item.local_properties hasn’t been effective for me.
I’m not subclassing the collector hook at all, but what @ymesh suggested gave me an idea for a different implementation.
Now I’m creating uniquely named item properties in each of my subclassed publish_session_geometry hooks (e.g. item.properties["publish_template_alembic"] in that subclass), and when each is instanced on a Publish invocation, there’s no clashing/overwriting of values across items in the stack. In the methods of each subclass I had to change it so they’re only concerned with the keys unique to their subclass when returning values.
I also had to create relative publish_file hook subclasses so that their methods are also only concerned with the aforementioned unique keys/values:
The upshot of all this is that I’m getting expected results: creation & in-place publishes of ABC & ASS files from the correct disk loactions, validation, correct post-publish SG Publish UI button triggers, etc.
This screencap is of a successful Validate run through the SG Publish UI:
Having said all of this, while it’s all “working” now, I would prefer to understand why the stack items are behaving the way they are for me such that I needed to implement something that feels like a workaround rather than an “as-the-developers-intended” solution.
I just tried the item.local_settings on my side, but it’s working for me.
I created two near identical simple plugins that both stored their paths in the accept method and then retrieved them in the publish method: plugin_two.py (1.2 KB) plugin_one.py (1.2 KB)
Which resulted in the two paths being correctly logged:
So that you’re leaving the template to be set in the publish_session_geometry.py rather than in your inherited plugins?
I’ll have to have a look tomorrow.
So I took a look at the publish_session_geometry.py, but I’m not sure what exactly you are overriding in your custom plugins.
The publish_session_geometry.py hook is using item.properties rather than item.local_properties so if that behaviour is not being overridden then it will continue to overwrite the property for each plugin, since it will be storing it as a global value on the item rather than as a plugin specific value.
I guess ultimately it would be better if our publish_session_geometry.py hook used local_properties by default as that would mean you wouldn’t need to override that behaviour.
One slightly hacky thing you could do to avoid having to implement the full publish logic in your hook, is to override the publish method, set the item.properties["publish_template"] = ... and then call super.
I mocked up another example where both plugin 1 and 2 derive from plugin base.
Plugin base uses the item.properties like the publish_session_geometry.py does, but each derived plugin sets that property before calling the base method so that it is redefined for each plugin when it comes to use it.
Still the better approach would be to use local_settings but I appreciate that would mean taking over more of the base hook logic.
A couple of days after I last posted to this thread, I ended up looking at the Unreal implementation of an FBX plugin, and mimicking that process with a both an Alembic plugin and an Arnold Standin plugin, forgoing the previous work I did with publish_session_geometry.
It made it much easier, and the collector's use clicked for me (I had initially misinterpreted its purpose, which is why I was previously avoiding it).
Looks like this, and since then I don’t use publish_session_geometry (or any of the aforementioned gymnastics) at all.
