Magenta Asset Map v0.2
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 |
- Publishing to Parent
- Turntable as a representation
- What is "group"
- Can the location of "versions" in the graph be dynamic?
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.
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.
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?
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?
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.
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.
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.
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.