Asset Map 0.2

README.md

Magenta Asset Map v0.2

• Go to Map

Node	Description
	A transformation; i.e. input A turns into output B
	Transformation from -> to
	Instance, the inverse of a file. May have one or more representations
	A representation, such as a .jpeg file or .exr sequence
	Updated individually
	A comment
	Artist
	Task
	Group
	Family

Terminology	Description
Asset	Folder on disk
Instance	Pyblish Object, the inverse of a file
Component	Part of a file
Element	An indivudual "layer" of an image

Things left to solve

• Publishing to Parent
• Turntable as a representation
• What is "group"
• Can the location of "versions" in the graph be dynamic?

Publishing to Parent

In the case of Layout publishing, it should be able to publish an individual occurrence, such as ben01, but also publish the whole scene as a form of "inventory". Something relevant to a shot as a whole, keeping track of which occurrences are part of a shot.

Turntable as Representation

Or metadata. Does it make sense? Or should it be a separate instance/family? They would still both be part of the same version and belong together that way.3.

What is "group"?

Not every graph has the (3) node "group". What is that? Can we have more than one? What happens if we remove it, must we rewrite tools? Can we move it?

Dynamic Versions

Versioning in each graph is fixed and any tools will have to (?) be built specifically to accommodate this particular spot. How does this work in pipelines that don't have versions? Can more than a single node have versions? Can we more the version "attribute" to another node, without breaking tools?

Thoughts

modelDefault from Modeling and animRig from Rigging are pre-defined as the artist starts working on an asset, such as Ben.

$ be in thedeal ben animRig --enter
$ maya

Conversely, ben01 from Animation and background from Lighting are post-defined, as in they don't exist until published for the first time. Subsequent publishes then increment these "dynamic" assets in the exact same fashion as the pre-defined ones.

$ python -m pyblish_maya maya/scenes/v001.ma

Can these be grouped in any significant manner? Are there only ben01, table01 and chair02 etc. along with backgroundLayer, faceLayer etc. that technically form two disparate groups, one closely related to existing assets used during the layout/animation/look development stages and the other during lighting and compositing?

Right off the bat, it's safe to say that faceLayer would never appear through animation, just as ben01 would never come from lighting.

The question is, are these 2 groups the only 2 groups and is it safe to build around them? What if a third group appears? What if groups need to appear more dynamically? What if there aren't any groups at all?

Time might be the only key, for now it seems these two groups cover the whole spectrum of production, from conception to final delivery.

Filesystem analogy

Publishing can happen to one or more "levels" of a hierarchy.

| Level | |------------------------------|--------------- | 1. Current Working Directory | Ben's model is published to Ben/model/v001 | 2. Subdirectory | Ben's animation is published to Shot010/animation/Ben01/v001 | 3. Parent Directory | Background layer is published to MyProject/layers/background/v001

In (1) the asset is published directly to where an artist works, whereas in (2) only a portion of an asset is updated. In (3) the asset is published "globally" so as to facilitate re-use across multiple assets.

Post-defined

Incremented individually.

public
▾ ben01
  ▸ v001
▾ ben02
  ▸ v001
  ▸ v002

Incremented together, latest version derived from traversing upwards, until asset (e.g. ben02) is found.

public
▾ v001     # Version
  ▸ ben01  # Component
  ▸ ben02
▾ v002
  ▸ ben01

Pros; versioning is linear and simple, irrelevant of which occurrences have previously been published. Cons; (1) knowing which occurrences are actually part of an asset is more difficult, as each version would need to be looked into and (2) finding the latest version of a particular occurrence means traversing each version until found.

DIVIDE.md

Divide and Conquer

Content is divided until it stops changing independently.

 _________________________________________________________________________
|                                                                         |
|                                  Film                                   |
|____________________________________ ____________________________________|
|                                    |                                    |
|              Ben                   |             Sequence1              | 
|_______________ ____________________|_________________ __________________|
|               |                    |                 |                  |
|   animRig     |    modelDefault    |     Shot1       |      Shot2       |
|_______________|____________________|_________________|__________________|

MAP.md

Conversely, ben01 from Animation and background from Lighting are post-defined, as in they don't exist until published for the first time. Subsequent publishes then increment these "dynamic" assets in the exact same fashion as the pre-defined ones.

I think you're trying to combine things that aren't related. This being "post-defined" is just as closely related as to how the model output from the Modeling Task is "post-defined". The family only starts to exists after an instance is published from the scene. The only moment something is pre-defined in the above overview is when something is a Task.

Instances are of a particular family, we don't necessarily need to include this in the folder structure. Family really is internal to Pyblish, as Pyblish's way of separating between which plug-ins operate on which instance.

It might be perfectly reasonable to omit the family altogether, from the directory hierarchy. That way, it will become more clear why families themselves probably shouldn't be versioned.

The thing that's being post-defined in this case, is not a family, but an new "branch" of content. backgroundLayer from lighting and ben01 from animation in this case, both depend on the specifics of a scene, and isn't something we could have pre-defined pipeline-wise, with things like families or tasks.

They are both internal to their respective scenes, the hassle starts once we decided that they both need individual versioning. This should be their only difference I think.