I think Publish shouldn’t just be a “model”-check-and-publish tool, but much more all-round.
The implementation should deliver the basis to allow for all scenarios: model publishing, rig publishing, lookDev publishing, etc.
Possibly even publishing the render scene to make it ready for renderfarm usage.
I totally agree with your descriptions that publishing in its core is a sequence of selection, validation (+ fixing), extracting and conforming.
Whether it’s something as complex as full animated shots needing to be published to lighting in chunks (where each chunk is separated into a valid format; eg. meshes to Alembics, vray proxies to separate .mb) or as simple as a single cube mesh saved to another location. In our studio every big project comes with new requirements for publishing, so it really needs to be configurable but most of all expendable.
The primary focus would be on creating the path-templating, configurable workflow, presets and user interfaces.
Because creating a single check is easy, but managing them in a consistent (possibly open-source industry standard way) is near impossible now.
Why support the rare cases?
For example Today I received scenes from a client that magically contained “scene metadata” (One of Maya’s new amazingly lacking features!) which turned almost all of our files (anything that referenced it) into 70 MB+ files (even if they didn’t contain any nodes at all) and had them crashing the whole time. It would be great if I could easily add a check to warn (and possibly fix) this next time. It’s definitely not an ordinary check, but it would save us a lot of hassle the next time.
Publishing a rig?
By the way, publishing a rig doesn’t necessarily check whether the rig is working fine. (That’s up to the riggers!)
But these could help:
- cleaning up unused nodes could be useful, like remove any unnecessary temporary shaders used in that file.
- remove animation from the rig file (if any)
- good old naming conventions check
- are all the controls in a character set? (see how pipeline specific this could be?)
- are there any non-skinned or non-parented (= not in main group) meshes in a rig file then they are likely not moving along; raise warning?
Yet this could be very different for a project that requires a game rig. That might require that the joint chain used for deformation is decoupled from the rest of the rig so it can be easily exported. (Or at least is able to be baked to such a format).
Also… a neat thing about validations is that it could check a variety of things without stopping at each validation.
One thing that can be very annoying is:
- Run the check
- Find out there’s an error
- Fix it
- Run the check
- Find out there’s an error further down in the checks
Instead it’s better to:
- Run the checks
- Show all things that didn’t pass validation (mark them red?)
- Fix all of it (= Auto-fix where possible; if some can’t be auto-fixed (because of the nature of the validation) then fix it myself.)
- Re-Run the checks