We are a game studio and our pipeline uses Maya to export a proprietary file format that our engine can read. We want use Pyblish to check the content before being sent to our custom exporter and we want Pyblish’s UI to reflect our scene hierarchy. Our Maya scenes are typically structured like this:
This Maya scene has 3 assets being exported. each asset has LOD render meshes, a shadow mesh, a collision mesh, and a LOD coordinator. Viewing this data in Pyblish is a bit rough because I have to create a bunch of unique families and the UI shows every asset by default.
Right now I have a family being generated for each asset type and mesh type, but the UI is becoming really messy because our Maya scenes can have lots of items in it. The artist should only have to see the high level details of the scene when running validation. If validation fails, then they can walk down into the hierarchy and find the offending item.
Ideally I would want the Pyblish UI to show something like the Maya outliner which I can collapse groups and the artist can open them up if they need to inspect an error.
Something like this:
I want to propose to expand the idea of a family to include parents and children. A family would be an asset, a parent would be an export type(render, collision, shadow, etc), and a child would be a DAG object in the scene. Or some similar structure to that. It is important that if any child fails validation then the parent and family would also show a failure.
Could you point me to the spots in the code that I would need to change to implement this need? Or would this be a request that you could implement on your end?
Hi @mbard, thanks for sharing this here rather than via email.
I’m off to bed over here, but in short, that isn’t possible at the moment but would be an interesting addition. Instances natively support hierarchy - they are subclasses of the Python list type, just like the Context which hosts Instances as children already.
The GUI doesn’t support hierarchy, but more importantly the behavior of stopping a parent on a failed child also isn’t supported.
I would suggest implementing the latter, lower level behavior before approaching the GUI.
For starters, you can group your instances like so.
from pyblish import api
context = api.Context()
instanceA = api.Instance("A", parent=context)
instanceB = api.Instance("B" parent=instanceA)
# Or, as they are all lists..
context = api.Context()
context += [api.Instance("A")]
context[0] += [api.Instance("B")]
You would then need to have a look at the Iterator class to ensure it delivers both parents and children to the process() method of your plug-ins. Careful not to assume that all children of an instance are instances, as some use that hierarchy to store all sorts of things.
Alternatively however, I would propose keeping your hierarchy flat and reduce instances to higher-level objects that encapsulate the asset as a whole as opposed to DAG nodes in Maya.
Thanks for the information! I will try to setup that parent structure and see if I can get it working.
For our pipeline we need to use an organized hierarchy like this because LOD0 could be made up of over 100 different meshes, and then each lower LOD could be another 30-80 meshes each. Also another 100 or so meshes of shadow mesh and collision mesh. Looking at that many meshes in Pyblish would be overwhelming and make the tool not function well for the artist. They will mostly only care about what assets passed/failed, and then what export type passed/failed, and all the individual meshes can mostly be ignored unless they need to find an error.
In our export pipeline the user flags groups or meshes in Maya which add a custom attribute that defines the export type. Our exporter will collect everything and spit out the game engine format. We don’t want to change this workflow because it is super fast and users don’t have to worry about scene names or organization to get something to export. We want to use Pyblish to show an organized view of the scene export data and then the validation checks against that data. Hopefully that makes sense
I think I see where you’re going now. If all you want is to draw a hierarchy of an instance, then that should be much simpler.
Have a look at the delegate for the list drawing each instance. If you expose the members of each instance to QML, you should be able to draw the children of it directly in the delegate, with a little indentation, making it visually appear as children of the instance.
