Publishing with comments


#1

Just thought I’d share a technique for artists to include comments with their publishes.

The gist of it is to add the comment within a scene, collect it when publishing and discard it right after.

In Maya

  • Create a node comment, and add the comment to the “notes” field of the attribute editor.
  • Alternatively, if your instance's are already encapsulated in a node, say an Object Set, add the comment in it’s “notes” field.

In Nuke

  • Create any node with a textfield, call it comment.
  • Alternatively, add the comment to the output-node’s “Label”.

In Houdini

  • On any node, create a “Label” or “String” attribute.

The same goes for any other host, such as Softimage, Modo or Fusion.

Finally, after a successful publish, remove the attribute/node from the author’s scene automatically via a plug-in, such as an Integrator, or post-validator. That way, you could include a validator that looks for a comment and either warns about it not being there, or enforces that one must exist.

Modifying the scene during publishing is generally considered bad, but considering the transient nature of a comment and how it is related to the event itself, it’s safe, future-proof and encouraged.

As an added bonus, storing the comment in the scene means publishing can be done offline, via the command-line, or distributed. Simply package up the scene, including a comment, and send it off!

This behaviour is much encouraged, as it enables a native interface between the host and data used for publishing, and transcends usage in just Pyblish. I would consider it good practice to develop a simple comment-GUI to help artists put the comment in. Perhaps something that launches prior to Pyblish, when the artists hit the “Publish” button.

Food for thought.

Enjoy!


Support for Comments
Learning Pyblish by Example
#2

The downside to this technique would be that it’s never possible to do an automated batch publish for which you set the comment through command line. It’s because setting the comment is not software agnostic.

For example:

$ pyblish -d comment "Hello, world!" publish

You could use batch publishes if other stages of production depend on the current publish and require an updated publish.

But it’s definitely a useful technique, one that works right away and is simple to pick up. Great!


#3

Actually, you can already do this.

$ pyblish -d comment "Hello, world!" publish

The key comment with value Hello, world! is then injected into the Context before publishing begins.


#4

To solve this you can have the lookup in a host only function if the comment data is not yet present. So providing the data yourself would override it, for example when you batch publish.


#5

Yeah, in this case, the comment would be the first to the scene, so any plug-in writing a comment would override whatever you put in, unless it checked for it first.

But, as for automation and batch, this technique is also advantageous as the comment would become part of the scene like anything else. It would be written, saved and then sent off. The comment could get lifted from any computer, without user intervention. Maybe that’s what you meant?

In general, I think it fits publishing overall, and should apply to anything user-defined. Maybe I’d even go as far as to say the proposed “user fields” should function in a similar way, simply another GUI for the user to enter information into. It’d keep things simple and uniform.


#6

You lost me here a little bit. You mean a GUI that user would use prior to publishing? or something that pops up during publishing?


#7

Either, I suppose.

For a comment, maybe have it pop up as an optional dialog “Would you like to add a comment?”. Once skipped/accepted, Pyblish pops up. For anything else, perhaps a more elaborate editor GUI, with options for adding various properties. I suppose much like the Add Attribute editor of Maya, or similar editor in Houdini, but for artists.

Re-reading this, it is possible to pop up a dialog from a plug-in, so long as it’s modal and pauses the host while running. Personally I would advise against it, primarily because I don’t very much like “popups” and also because it means publishing requires someone to be there to close them all. But handled right, it’s possible you can get away with it in limited doses.