Renaming Instance to Asset

What do you think about renaming Instance to Asset?

I think Instance fits it’s technical implementation, as an “occurence” of some set of data. But perhaps the way we’ve been using it is exactly how we would use an Asset. The difference being that we have an upfront understanding of what it is supposed to mean, as opposed to Instance which has to be unlearned (from particle instances or what not) and then relearned until we eventually get to the point where it clicks “Aha, so it’s an asset”.

By calling it Asset to begin with, we might make it easier to grasp first-hand, whilst providing a stronger continued understanding of what it is.

Here’s a look at an alternate reality where this has already happened.

import pyblish.api

class SelectCharacters(pyblish.api.Selector):
  def process(self, context):
    for objset in"objectSet"):
      name = cmds.getAttr(objset + ".name")
      asset = context.create_asset(name)
      asset.set_data("family", "character")

class ValidateColor(pyblish.api.Validator):
  families = ["character"]
  def process(self, asset):
    assert"color") == "blue", "%s isn't blue" % asset
1 Like

Asset is great term that everyone seems to like using. Unfortunately it’s being used differently in other place all the time. Example:

Shotgun Asset = a piece of work reused in more shots or places, like character, environment, backplate etc. can have lot’s of subelements. tasks, published files, versions, etc.

Ftrack Asset = A container for version of certain type. Not the full character, but a character model for example. However this can hold multiple components in each version like Low res mesh, Hi res mesh, preview quicktime etc.

Equivalency roughly based on what they contain:

Shotgun Asset = Ftrack Asset Build = Pyblish None

Shotgun Version = Ftrack Asset = Pyblish Instance?

Shotgun Published File = Ftrack Component = Pyblish Instance?

Of course this is very much an approximation, because there are big overlaps. I’m not trying to steer away from asset here, but merely trying to point out how differently it is used in many place (not to mention, that many studio have their own understanding of that asset actually is).

At the same time, changing the name from instance to something more intuitive would certainly help new people understand the system quicker.

The problem I see is that Pyblish instances can be of such massive variety, that maybe something more general than asset might work better. Even though ‘asset’ is still better than ‘instance’.

I don’t really have suggestions at this point. Just wanted to paint a full picture.

1 Like

No, you’re right, I also see this pattern, but I actually think this might work to our advantage in this case.

I think the term “asset” is being used sporadically enough for anyone encountering it to put some assumptions into it, like the fact that it is an encapsulated set of data, but not too many. Just the fact that FTrack and Shotgun has chosen to put such specifics into the term themselves is a good sign of this I think.

I think “asset” is just general enough to make it a good fit as a replacement for “instance”, without taking too much away from it. When considered in context of developing plug-ins with Pyblish, which is the only occasion this term would ever surface (as artists would never be exposed to it; an important distinction I think), encountering asset shouldn’t leave room for much confusion in regards to whether it’s a Shotgun or FTrack asset.

On the other hand, it does mean that things like this might start to raise an eyebrow.

if 'AssetVersion' in ftrack_data:
  version_id = ftrack_data['AssetVersion']['id']

Is this a Pyblish asset, or FTrack asset? :confused:

That’s exactly where we might run into troubles. This is a good info about what is what in ftrack for example ftrack assets

What you pointed at is referring to ftrack AssetVersion which is a part of ftrack Asset. So in ftrack what we’d be doing is roughly this.

create 'Asset' of type 'Animation'
create 'AssetVersion' as child of 'Asset'
set 'AssetVersion'.versionNumber to #
attach components to 'AssetVersion'

I can see this getting a bit confusing when instances are called assets too. Even though ftrack data is all stored within ftrackData in the context, so there shouldn’t be any clashed in terms of overriding data.

Just a heads-up, I’m striking the use of “Asset” off the list, sticking with “Instance” to maintain the separation between what is Pyblish and what is everything else.

The Learning Pyblish by Example has been updated to reflect this.

Thanks for your input @mkolar!


Not sure that one is linking where you’d like it to? Did you mean the actual Learning Pyblish by Example topic?

Haha, yes, that was the wrong link, I’ve updated the link about having updated the guide. :slight_smile: Thanks.