Not sure there is one, feel free to make one if not. The thread topic doesn’t reflect this at the moment so it might get lost.
Maybe if you have a particular idea in mind, we could come up with an alternative until it’s implemented?
So I’m presenting all valid meshes when a user wants to publish a modeling task. I would like to extract all those meshes to maya file, but if the user deselects anything the ui the meshes will still get extracted with this plugin;
import pymel
import pyblish.api
class ExtractModeling(pyblish.api.Extractor):
""" Extract work file to 'publish' directory next to work file
"""
order = pyblish.api.Extractor.order + 0.1
families = ['geometry']
label = 'Modeling'
def process(self, context):
nodes = []
publish_file = ''
for item in context:
if item.data('family') == 'geometry':
nodes.append(item[0])
if item.data('family') == 'scene':
publish_file = item.data('publishPath')
pymel.core.select(nodes)
pymel.core.system.exportSelected(publish_file,
constructionHistory=False, preserveReferences=True, shader=True,
constraints=False, force=True)
I know there is the alternative of the users choosing which meshes to extract with sets, but I don’t want the users to get into that workflow.
Ok, I think you can do this.
Make your extractor into an Integrator, and have it happen at the very last. Say, an order of 99.
At this point, you’ll know which instances were published by looking into the results dictionary of the context. It will list all processed plug-ins and the instances they were associated with. Go through this list to find out which instances were toggled.
There might be a flag on each instance saying whether it has been published as well, such as __published__, but I’ll have to double check. Until then, try the above and let me know how it goes!
nice:) I ended up doing this;
import pymel
import pyblish.api
class PassthroughModeling(pyblish.api.Validator):
families = ['geometry', 'scene']
label = 'Passthrough'
ExtractModeling = True
def process(self, instance):
pass
class ExtractModeling(pyblish.api.Integrator):
""" Extract work file to 'publish' directory next to work file
"""
families = ['geometry']
label = 'Modeling'
def process(self, context):
nodes = []
publish_file = ''
for item in context.data('results'):
try:
item['plugin'].ExtractModeling
instance = item['instance']
if instance.data('family') == 'geometry':
nodes.append(instance[0])
if instance.data('family') == 'scene':
publish_file = instance.data('publishPath')
except:
pass
pymel.core.select(nodes)
pymel.core.system.exportSelected(publish_file,
constructionHistory=False, preserveReferences=True, shader=True,
constraints=False, force=True)
Just wanted to say that I’m missing this quick toggle feature more and more. With lots of alembics to export, and you may want to just export one or two, having a toggle for selecting/deselecting the entire family becomes super handy.
About the quick toggle to toggle a branch of Instances in a family, do you think you could mock up a sketch illustrating how you would like that to work? The drag select is easier, we’d just need to replace the scrolling functionality with a scrollbar, but I think the family toggle is more important? And more difficult to get right, user experience-wise.
I imagined it working like most master check boxes. The family check box will toggle all the instances, regardless of their current state.
Ah! That’s brilliant!
Will have a think about it, doesn’t look too difficult to set up.
I had a thought about this. If the GUI can modify the state of the instances with a future implementation, it could also propagate the change to the scene, meaning that you get it saved for the next run.
This is workflow dependent obviously. In the case of for example renderlayers in Maya our collector looks at the renderable state of the renderlayer to choose whether or not to include it as an instance. In this case the GUI could change this renderable state to save it for the next run.
This would need some kind of abstraction layer, where you can choose how to turn instances on/off.
It could do that, but it wouldn’t be the default behaviour I think.
Initially, it would simply pass along the publish data of an instance when publishing. In practice, that means your render layer would set a default value for this data, but wouldn’t be affected by changes to it.
Setting up a “hook” of sorts to physically do things externally is possible also. There’s enough information in the developer guide for such a thing to come to fruition. *hint hint*
1 Like
haha, getting it:)
1 Like
So I have a working version of this; https://www.youtube.com/watch?v=XVUjvYfRcWE&feature=youtu.be
Apart from what people think of the functionality of the feature, what do you think of the placement of the checkbox? Here are some other options.
Private video 
How about now?
Nice job! The YouTube link seems to be private however, maybe need to make it public somehow.
Just looking at the images, I think the former one looks more organised but perhaps less intuitive whereas the latter one looks easier to grasp but perhaps less visually appealing.
To throw out one more alternative, not sure whether it’s neither worse nor better:
C
Still thinking the first one, let’s call it “A” to be the more clear one.
Maybe the boxes are starting to clutter up the view? We could make them smaller, similar to a bullet list, and scale them back up when hovering.
D
Alternatively, we could have a look at adding some change in appearance when hovering an item. In that way, the checkbox could appear highlighted when hovering an item, and when hovering the family (or “section” as it’s called) all related items could be highlighted?
Just saw the video, great job in handling the corner cases of “what happens when I toggle a family of which there are two?” and “what happens to the family when I toggle an instance?”!
Think your option “C” @marcus looks good to me. Thought the clustering of checkboxes are bad in the video, but indenting the instance checkboxes would make it easier for an overview.
for now I’d go with option C that you posted.
D is a bit confusing, with all the dots in the middle and on the side. I already have artists complaining about the amount of stuff that’s in the UI.
@tokejepsen If you can, try having a look at what would happen if the checkboxes were hidden by default, and only show up when the user hovers an instance.
Would you have to hover over all the instances to see which instances are going to be published then?