Asset Management¶
One of the major design decisions made with Pipi is the encapsulation of content and meta-content within single branches of directories.
For example, the directory /assets/Peter contains all data relevant to this asset. This may be what you would expect, however an alternative, perhaps more traditional method is to separate content produced by artists, content published by artists and the metadata associated with a particular assets into three separate branches.
/work
Peter
myscene.mb
/published
Peter
v001.mb
Where metadata is stored within a database such as mySQL or mongoDB and only accessible via scripts. One of the reasons for this separation is technical; directories are simply incapable of storing additional metadata and files are limited in how they allow you to modify them. With the advent of Open Metadata however, this limitation is not longer the case and we are again free to join metadata with its content.
As such, in Pipi, the hierarchy looks like this:
/Peter
.meta
Asset.class
private
marcus
maya
myscene.mb
public
v001
This way, you are free to rearrange your content, either permanently or dynamically at any point in time as well as transmit or archive content and always rest assured that no content is ever out of sync.
Tagging¶
Traditionally, identifying content within a hierarchy is performed via associating an absolute path to keywords or collection of keywords.
/projects/spiderman/assets/Peter
This path refers to an asset within the project Spiderman, identifying this asset may look like this:
assets = {'Peter': '/projects/spiderman/assets/Peter'}
However, hard-coding absolute paths may make it difficult to change your mind so further convention may be built:
assets = {'Peter': '$ROOT/$PROJECT/$ASSETS/Peter'}
Here, keywords have been inserted in-place of actual path-names that may be resolved at run-time. As you can see, there is no longer any mention of the project’s name. This way, you are free to re-use tools built upon them in other projects.
We’ve chosen a different approach. As part of the decentralised philosophy surrounding Pipi, the meaning of content is stored together with the content itself to form content that is so-called self-describing:
/spiderman
assets
Peter
Mary
Goblin
shots
1000
2000
3000
In this example, spiderman consists of 3 assets and 3 shots. Tagging is utilised to place additional meaning into each directory.
/spiderman <-- Project
assets
Peter <-- Asset
Mary <-- Asset
Goblin <-- Asset
shots
1000 <-- Shot
2000 <-- Shot
3000 <-- Shot
Tagging is performed via a library called cQuery[1]_
Namespaces¶
For context sensitivity, Pipi treats the current working directory as namespace. This means that while your are located within a certain directory, the actions you take within this directory will be relative this directory.
This also has an effect on the layout of your directories.
/projects/spiderman/models/Peter
/projects/spiderman/rigs/Peter
/projects/spiderman/shaders/Peter
In the above example, models are collected within a common directory and each asset separates their corresponding model by name. In this scenario, metadata stored at the models directory of Peter will not be visible with metadata stored with rigs and as such will either need to be duplicated or remembered.
Considering that Peter is more likely to pertain metadata than models, a more efficient layout may look like the following:
/projects/spiderman/Peter/models
/projects/spiderman/Peter/rigs
/projects/spiderman/Peter/shaders
In this example, we may associate metadata with Peter and it would remain consistent whether you are exploring his models, rigs or shaders.