The tricky thing with Publishing is that you create a form of output that should be easily read and magically worked with somewhere else.
“Publish” can create a multitude of output files, but if there’s no way to consistently create the next work-file it doesn’t reduce that much more hassle; just more neatly saved files.
What you describe here is something I would classify as “shot publishing”, the opposite being “asset publishing”. Shot publishing does indeed seem like a much larger ocean of individuality amongst studios and I think for the time being our efforts would be focused on publishing assets which involves a single output into a single archive, typically single file - such as .mb for character rigs, .tga for textures etc. - but possibly multiple ones - e.g. .obj, .abc and .fbx for a prop model.
Shot publishing, as it seems, is then the publishing of the output of multiple assets at once. Each asset then is treated as a generator of additional output - e.g. a character rig generates point-caches.
I’ll save my comments on shot publishing for a later time in an effort to keep the conversation focused. First, to join our jargon:
Filter
What you refer to as “filter” is what we’re referring to as “selection” and is the method with which to reduce a scene into objects to be published.
Export/Import
What you’re referring to as export is what we’re referring to as conform and is outside the scope of Publish. In a nutshell, all published files would end up relative the current working file.
See here Published file structure concept · Issue #9 · pyblish/pyblish-base · GitHub
And here Home · pyblish/pyblish-base Wiki · GitHub
And here Home · pyblish/pyblish-base Wiki · GitHub
Conform
“Conform” probably isn’t the best name for how we use it, but it’s meant as “take the finished output, and put it where it belongs”.
I think the best thing Publish could be is a framework
I think so too. I was thinking of providing this at least for validations - e.g. a plug-in system with say 1 file per validations, and a naming convention to correlate between classes/families of output (model, rig, animation etc.) and their validations. Similar to how the Python nose package would look for tests.
But it makes sense to make more parts of Publish susceptible to extension. As an example, one of the things we’ve been discussing is how to identify what is to be published, and what is not. I’ve advocated selection sets, while others have spoken of attaching attributes onto nodes. This could potentially also be treated as a separate, exchangeable component that could either be written by others or provided by us along with a few alternatives.
Initially though, I’d like to stress that getting a minimum viable product out is of primary concern, and plug-ins and templates will most likely take a back-seat for that.
for any basic artist to predefine STEPS/ACTIONS to be taken at certain stages (input-output)
And the ease of creating customized ACTIONS should be of utmost importance, because new ways of publishing or requirements will always come up.
Publish therefore should be able to handle both export and imports of data to make it of significant use.
This is a fascinating idea, I’d love for you to try and illustrate it more thoroughly if you can. For example, as a use-case illustrating a suggested step-by-step workflow, and perhaps a mock-up GUI on how artist would actually create/define these steps.
Not sure if the above summation helps or only drifts away from what you want Publish to be.
But what I mention here is what I could possibly see becoming useful.
It certainly does! At the very least it highlights some aspects that have not yet been vented and it’s good to try and at least be familiar with questions that are bound to hit us down the road at some point, like shot publishing.
Not sure where you’ll stop reading because of the length of it, but remember even though I have some criticism I really like the idea of creating tools like this open-source and driven by community.
