Hey, my long term goal is to make pyblish more accessible
In my past 3 game studios I made a similar system from scratch, and never heard about Pyblish.
It’s surprisingly unknown sadly.
So let’s make it accesible!
I come from a games background, I believe pyblish came from VFX so this might explain why i’ts not as known in games. ( i see in the credits some studios use it though)
To do this, I have few things in mind:
- a library with generic plugins
i’m collecting lots of different plugins.
most use context to pass stuff and only work with the plugins from the same author. this can’t scale up.
i found some people use cmds, some pymel. we need to support differences.
- a way to make plugins work with each other. plugins from different authors are not always compatible.
ex. longname vs shortname, pymel vs openmaya vs cmds, …
python2 vs python 3
- an option to choose plugins. haven’t looked into the filter system yet for pyblish, this might work.
thinking along line of a studio setup, a project setup, …
settings file that overwrites plugin metadata (isactive, …)
could even remap funs to work in ways original author didnt intended.
prototype would be like maya plugin selector
atm you register paths, or plugins with a few lines of code.
it’s easy for tech people. but to make it accessible for artists we ideally have a GUI.
pick and choode your plugins, save config out.
i think an easy way forward would be extend the parent child plugin in pyblish.
- cube instance contains:
- a shape instance
- a transform instance
now we can run our mesh checks on the shape part, and transform checks on the transform part
we could try work around with inheritance but feels more like some hack.
plugins would have to use this new class somehow, it doesnt feel clean
class TransformValidationPlugin(pyblish.api.Validator): def process(self, instance, context): data = instance[:] filtered_data = [x for x in data if type(x) == pm.nt.Transform] instance[:] = filtered_data
ideally we dont touch original plugins and just know what they run on, then run on those applicable instances. hence the parent child setup
i think the big thing to keep in mind is not all of this needs to go in pyblish_base
this can be a separate tool or extension to pyblish just like pyblish_maya