Christmas Bjørn Dancekonge created with Pyblish

Ho ho ho! Merry Christmas.

Completely validated, extracted and integrated through Pyblish in our pipeline we (at Colorbleed) took on our own in-house project about a character named Bjørn Dancekonge. He’s a born dancer and party starter celebrating life to the fullest. We kickstarted his personality with the release of a short Christmas video.

And to keep up the Christmas spirit I wanted to share it here too: Bjorn’s Christmas (2016)

If you like Bjørn’s moves you can follow him on facebook: Bjørn Dancekonge

Using Pyblish

At Colorbleed we’ve been using Pyblish productively from a very early stage (around a year now?). We always wanted to do a write up about how we use Pyblish and why we benefit from using it. Most of our projects this year are under NDA and have a longer time to go to release than we’re used to so we never found the right way to share our story.

We’re expecting to hit some nice releases next year (from productions done this year) and open up a bit about the involvement of Pyblish. It’s helped us a lot! At first it was just an additional safety check but over time it changed our way of thinking about production and improved our workflow in much more areas. Hopefully we can share some of that knowledge along with it by then.

Pyblish in our production takes care of validating and publishing models, rig, caches (Alembic, but also fur, particles and others), lookdev (shader-relationships) and much more. For us it provides a safe consistency on which our pipeline now lives.

I’d be happy to elaborate on this if there are specific questions. And, of course, happy holidays everyone!


That is freaky great!

So many many questions, but I guess first who came up with this? :grinning:

More techy questions:

  1. How do you handle shader relationships?
  2. How do you handle rig updating? Do you publish accompanying script for for fixing the rig?
  3. Are the artist very comfortable in thinking in Pyblish terms like instances and plugins?
  4. Do you have some thoughts about where the next step is for Pyblish?

The character came to be during a brainstorm session with the whole team. At that time it was a character that would celebrate all things in life, the good and bad. From there on out I drew character designs and wrote out this film (and some others) and eventually directed the film. So in a way you can blame me and the whole team. :wink:

We extract the shading groups (and other sets) into a .ma file along with a relationships table stored in a .json file format. All our models get a unique identifier assigned so at all times (no matter where the mesh is) we can identify it for example as the leg of Bjorn. We can lookdev Bjorn and publish his shaders and their relationships, so basically it knows to assign the legs shader to the legs mesh.

Additionally a single asset can have shader variations (e.g. a healthy condition of his outfit, a worn down variation or just a different colored one). This is especially useful for background props (e.g. having many variations on books, etc.)

Because of the asset ids being on the mesh the shaders could theoretically be created anywhere (not necessarily in the workspace of the asset itself) and it would know the relationships belong to the Asset (e.g. Bjorn). In usual production we recommend to work in the asset itself but it has happened that we would lookdev a whole scene (consisting of many assets) in one go and combined and publish it from there.

With this we’re not yet where we want to be because preferably it would be a one-click solution. Usually rig updating isn’t a major dealbreaker at this point since meshes usually maintain their ids and all we do is transfer the deformer relationships from the old to the new meshes. (We don’t have referenced meshes in the rig, they are imported there.)

So far this has worked fine and usually takes around 10-20 minutes for a character depending on the complexity of the rig. Only with a lot of blendshapes things get increasingly complex.

I must say, yes. At least, over time, they grow comfortable with some of it. Especially instance is something they know what it is because we specifically identify in the scene what needs to be published by putting it in sets that we call instance sets.

I don’t think they use the terminology of Pyblish (they don’t really need to) of plugins and instances. I never heard them say plugin for example, they would usually say “This mesh check here is giving me this error. What’s up?” or “The model publish isn’t working here and I can’t seem to find what went wrong?” These are things you usually hear when a Validator started acting out (bug in the code that results in wrong behavior in specific situations) or just plain Maya crashes during certain extractions (which is when we debug it all and resolve it for the future, potentially adding extra validators or improving the extractor).

I think it’s mostly in the UI at this point. The backbone is there and should just get some good use over time to really figure out what else is needed but I believe the foundation that’s there is strong. We use the QML version but are looking to switch to Lite for stability and speed purposes. The UI suffices for most of the general use cases but large and heavy scenes would benefit from simplified overviews that are more artist friendly.

Aside from that I would love to see the community growing into such a direction that ideas, techniques and preferably even plugins & pipelines start to open up and get shared. Collaboration is a keyword there, so I believe, and it will help us all to increase production quality much more than we would be able to do alone. The fact that Pyblish exists and is maintained is just the beginning. The first step is there, from here on out giant leaps should be taken by everyone to really reap the benefits.