Within the constraints of use cases and interactions within the design document, and the general consensus arrived at through the R&D process, develop a specific implementation plan for distributed asset and inventory services for reX-NG.

Can be found in Asset_System_Technical_Requirements.

• Productive work-flow for content creators
• Easy management and deployment of asset sets for games or other worlds
• Not be centralized or tied to a specific entity
• Scalable to "internet levels"
• Reasonable security and access control
• Leverage existing code-bases to make implementation an achievable goal

Asset: is a binary blob of static, write-few/read-many data that comprises a fundamental fragment of content.

• texture, sound, container, item

Container: a collection of assets, and functional information about how assets relate to each other, that represents a re-usable work of content. An asset itself.

• .mesh, .material, .layout

World: an arrangement of instantiated Items, in space, with a concept of ownership permissions.

• "Joe's Plaza"

Inventory: a relationship between Items used by humans to organize data, with a concept of ownership permissions.

• ".../my_identity/my_avatar/clothes/saturday_evening_wear/dancing_boots.item"

Note: because containers hold data about assets and how they relate to each other, they are content unto themselves, and are properly assets, not inventory

• The existing model of asset management from SL is an excessive burden for professional content creators
  • Asset system needs a means of adding new arbitrary asset types and meta-data specifications
  • No support for "meta-assets", or "items" which is a hierarchical collections of asset, exposed as an asset itself
  • Copy-on-write mechanics makes small iterations of design burdensome since any change means all references must be updated
  • Copy-on-write mechanics makes hierarchical collects difficult as a change in a branch requires rebuilding the linking structure
• Modifications can be made to the SL asset system through server modules, however a complete re-design and implementation of a totally new asset system is not feasible at this time
• At an architectural level, the distinction between "instanced" prim data, and static asset data seems arbitrary: they are both world objects.

• While content creation represents a critical use case, it represents a fraction of the use, as assets are by definition write-few/read-many.

On Meta-data

There are several orthogonal concerns that require meta-data, and while some implementations may choose to combine these concerns together, that should be done explicitly as a design choice.

(With thanks to Metaforik for use as an example)

• Any to Any: Size, Dates (create, modify, publish...), Version
• Content creator to End-user: the attribution terms or conditions under which he has made the content available (copyright, licensing)
• Content creator to End-user: a description or purpose for the content
• Content creator to User-agent: the best ways to view the content under different situations (device profiles, LoD)
• Content creator to User-agent: the language the item was created in, and other possible local versions
• Content creation application to User-agent: MIME (or otherwise) Type for the user-agent to distinguish how to handle the asset
• Content creation application to User-agent: Location of actual binary (PURL-style asset)
• Security permissions (fill in more details here...)

On Container formats

There are several use cases for container formats as well.

• To attach meta-data from any set of concerns above.
• To link together pre-existing container formats, such as Ogre .mesh, .material, .particle, etc.
• To provide hierarchical or relational spatial information -- layout containers

On Relating and Addressing Assets

There are several ways in which assets relate to each other in the pipeline from creation to display.

• Content creation: assets are related to each other in container formats using simple local addressing that is easy for a content creator to understand and manipulate
• Publication: assets are related to each other in container formats using globally unique addressing that is friendly to global indexing, searching, retrieving and caching
• Simulation: assets are related to each other in computer memory using locally unique addressing that is friendly to local indexing, searching, retrieving and caching

On Layers of Abstraction

Clearly the following are all present in any VW system. The question is at what layers do we expose our interfaces.

• Asset Layer
  • stored in uniform memory
  • uniquely addressed in machine friendly way
  • 1-1 mapping of addresses to names make assets immutable
  • operations are GET and SET

• File/Inventory Layer
  • stored in a hierarchical memory
  • addressed by arbitrary, human-readable names
  • easy renaming makes assets mutable
  • addresses may contain cycles
  • operations are GET, SET, RENAME, LIST, COPY, MOVE, DELETE, etc.

• Versioning Filesystem Layer
  • inherits all properties of File Layer, but adds versioning, history, deltas, replication, etc.

Actors

• Client (C)
• Simulator (S)
• Content Creator (CC)
• Content Distribution Network (CDN)
• Content Publishing Tool (CPT)

Objects

• Set of assets (A)
• Set of asset meta-data (M)
• Layout of assets in a space (L)

Assets

• cat.mesh
• dog.mesh
• cat.material
• dog.material
• dogeyes.jpg
• cateyes.jpg
• brownfur.jpg
• whitefur.jpg
• fourlegs.skeleton
• dogwalk.skeleton
• catwalk.skeleton

Dependencies

• dog.mesh -> dog.material -> whitefur.jpg, dogeyes.jpg, catwalk.skeleton -> fourlegs.skeleton
• cat.mesh -> cat.material -> brownfur.jpg, cateyes.jpg, dogalk.skeleton -> fourlegs.skeleton

Creating a World from Nothing, One-step Publish

Goal: create a new world.

1. CC creates A. All are regular files, relative to C:\Content on the CC's hard drive.
2. CC places (realizes) A within the space such that cat.mesh is opposite dog.mesh, and they're facing each other.
3. CC iterates over the content and layout until he is satisfied with the result, at which time he decides to publish.
4. CC gains appropriate permissions to CDN and S.
5. CC places A in the chosen globally accessible CDN, and L is placed in the chosen S.
6. C visits S, which informs it of {(A,M),L}.
7. C reads M, places A in a local cache, and uses L to render the completed scene.

Creating a World from Nothing, Two-step Publish

Goal: create a new world (may lead to simplified content publishing tools).

1. CC creates A. All are regular files, relative to C:\Content on the CC's hard drive.
2. CC iterates over the content and layout until he is satisfied with the result, at which time he decides to publish.
3. CC gains appropriate permissions to CDN
4. CC places A in the chosen globally accessible CDN.
5. CC visits S and gains appropriate permissions.
6. CC places (realizes) A within the space such that cat.mesh is opposite dog.mesh, and they're facing each other.
7. C visits S, which informs it of {(A,M),L}.
8. C reads M, places A in a local cache, and uses L to render the completed scene.

Modifying an Existing World

Goal: Modify make the cat's fur brown-with-spots, and place it beside the dog, facing the same direction.

1. CC visits S and gains appropriate permissions.
2. CC alters L so that the cat and dog are beside each other, facing the same direction.
3. CC modifies brownfur.jpg (F) to add spots, creating brownspottedfur.jpg (F').
4. CC gains appropriate permissions to CDN.
5. CC places F in the chosen globally accessible CDN.
6. CC modifies {(A,M),L} such that F -> F'.

Cable Beach

Cable Beach provides a two-layer solution which distinguishes between cache-friendly and simple semantics of immutable and opaque assets, and a human-friendly and simple semantics of a file system-like inventory system.

Assets are addressed by URL-prefixed content-hash that serves to globally identify assets. Assets either unprotected, in which case they may be read from anywhere; or protected, in which case they are hidden behind a CAP URL. Assets are copy-on-write, and thus there is no need for delete or create permissions, only read and write. An asset server may implement garbage collection, but that is a matter for local policy.

Inventory items are kept in a WebDAV-based inventory system, and thus have a concept of ownership permissions.

Work Remains

However CB doesn't directly address several issues with using Ogre container formats. Dependencies expressed within the container formats are using local names which must be manually edited when changed, or may cause naming issues when exposed over the internet. Moreover, regions have private "primtables", but no easily semantics for allowing actors with acceptable permissions to manage the objects in a world.

Container formats

We propose a simple layout container format which can be used as an asset itself. The purpose is to aggregate "abstract" mesh container files, which contain no "instance" on how to realize (or "rez") the asset in space, into a relative coordinate space. This meshes within the scene fragment described by the container file could then be "rezzed" in one step by rezzing the parent container.

The scene fragment file (.layout) is defined as follows

• Syntactically similar to other Ogre file formats
• Consists of one prim which acts as a bounding-box for a single ogre mesh (.mesh) OR consists of a link-set containing N pairs of prims and associated meshes

World Inventory

We note that items in inventory are not "rezzed" or realized in a space, having a position and volume. Yet content creators wish to have an abstract view of all items, both those that are"rezzed", and those in an inventory. To this end we propose that each region have it's own inventory (containing potential items), and a "dynamic inventory", which is a inventory-like view of objects in the primtable, appearing as items in a similar manner to inventory.

• Each region exposes its own WebDAV-based inventory
• Each region exposes a view of its own primtable, in a manner consistent with inventory
• Content creators with sufficient access rights may view and modify the region inventory
• Content creators with sufficient access rights may view and modify the region primtable view

Explicit Publishing

To try and make content creation as simple as possible, and not burden the content creator with asset addressing details, we propose a modal solution, where the world is first built in a private region, then explicitly exported to an asset server, then the structure copied into a region inventory. The creator then logs into the region and explicitly rezzes the items.

• World creation happens in a special simulator mode where container formats have easy local names
• An explicit publish step causes local names to be re-based to global URIs

Example Walkthrough

Use Case: Creating a World from Nothing, Two-step Publish

1. CC creates WonderWorld locally in a private world controlled by the CPT. Assets are created by the CPT in a "local inventory" stored on a regular file-system in C:\Content\WonderWorld. All URIs within this private world are either of the form file:///C/Content/WonderWorld/*, or * relative to the path file:///C/Content/WonderWorld/
2. CC publishes WonderWorld to his chosen CDN, in this case CB-based asset server at http://example.com
3. CPT recursively parses all container files in local inventory, from root containers (.mesh -> .material -> ...):
   1. CPT computes a dependency graph for each asset based on it's traversal
   2. CPT creates a content hash H of the asset, and a corresponding meta-data stub, attached to it's node in the graph
      1. CPT adds the fully qualified URIs of ALL child assets to the asset's meta-data stub
   3. CPT walks the graph of parsed assets, and POSTs the binary and meta-data, in this case to http://example.com/assets/H/data and http://example.com/assets/H/metadata respectively
4. CPT copies the local inventory to the world inventory at http://example.com/inventory/MyPlace/WonderWorld/, using a WebDAV client
5. CPT creates WebDAV collections (MKCOL) for each directory in inventory, and redirected references (MKREDIRECTREF) for each asset file in inventory, in this case pointing to http://example.com/assets/H
6. CC logs into S and gains appropriate permissions to access S's world inventory
7. CC rezzes each asset by drag-and-drop operation within the world, and manually places each asset in its correct layout
8. S does a GET on each rezzed item in order to retrieve the Redirect-Ref header which contains the asset URI to be stored in the primtable
9. C logs into the S and receives notice over SLUDP of an in-world object; it retrieves the associated asset URI from the object's RexObjectProperties
10. C downloads and parses the assets associated with the object in the primtable
    1. C discovers that the asset URI scheme is "http"
       1. C does an HTTP GET on http://example.com/assets/H/metadata
          1. C reads H from the meta-data (not from parsing the URI)
       2. C does an HTTP GET on http://example.com/assets/H/data
          1. C either decodes or parses the asset depending on MIME-type, and caches the in-memory representation, keyed by H
       3. C downloads, parses, and caches ALL dependent assets listed in the meta-data
11. The renderer is notified of completed in-memory representations of an asset, and is given its key H; which it knows how to draw

Use Case: Creating a World from Nothing, One-step Publish

1. CC creates WonderWorld locally in a private world controlled by the CPT. Assets are created by the CPT in a "local inventory" stored on a regular file-system in C:\Content\WonderWorld. All URIs within this private world are either of the form file:///C/Content/WonderWorld/*, or * relative to the path file:///C/Content/WonderWorld/
2. CC publishes WonderWorld to his chosen CDN and S; in this case CB-based asset server at http://example.com, and "MyPlace" on "MyGrid", respectively
3. CPT recursively parses all container files in local inventory, from root containers (.layout -> .mesh -> .material -> ...):
   1. CPT computes a dependency graph for each asset based on it's traversal
   2. CPT creates a content hash H of the asset, and a corresponding meta-data stub, attached to it's node in the graph
      1. CPT adds the fully qualified URIs of ALL child assets to the asset's meta-data stub
   3. CPT walks the graph of parsed assets, and POSTs the binary and meta-data, in this case to http://example.com/assets/H/data and http://example.com/assets/H/metadata respectively
4. CPT copies the local inventory to the world inventory at http://example.com/inventory/MyPlace/WonderWorld/, using a WebDAV client
5. CPT creates WebDAV collections (MKCOL) for each directory in inventory, and redirected references (MKREDIRECTREF) for each asset file in inventory, in this case pointing to http://example.com/assets/H
6. CC logs into S and gains appropriate permissions to access S's world inventory
7. CC rezzes the single root asset, which contains all the layout and orientation information encoded by the CPT, by drag-and-drop operation within the world
8. S does a GET on the rezzed item in order to retrieve the Redirect-Ref header which contains the asset URI to be stored in the primtable
9. C logs into the S and receives notice over SLUDP of an in-world object from the layout link-set; it retrieves the associated asset URI from the object's RexObjectProperties
   • TODO: I don't know the link-set mechanics well
10. C downloads and parses the assets associated with the object in the primtable
    1. C discovers that the asset URI scheme is "http"
       1. C does an HTTP GET on http://example.com/assets/H/metadata
          1. C reads H from the meta-data (not from parsing the URI)
       2. C does an HTTP GET on http://example.com/assets/H/data
          1. C either decodes or parses the asset depending on MIME-type, and caches the in-memory representation, keyed by H
       3. C downloads, parses, and caches ALL dependent assets listed in the meta-data
11. The renderer is notified of completed in-memory representations of an asset, and is given its key H; which it knows how to draw

Use Case: Modifying and Existing World

Goal: Modify make the cat's fur brown-with-spots, and place it beside the dog, facing the same direction.

1. CC logs into S and gains appropriate permissions to access S's world inventory
2. CC selects an cat.material and copies (COPY) it to the local inventory
3. CPT downloads the asset redirected to by dav://example.com/inventory/MyPlace/WonderWorld/cat.material as C:\Content\MyPlace\WonderWorld\cat.material
   1. CPT downloads all dependent assets listed in the dependency section of http://example.com/assets/H/metadata and places them in C:\Content\MyPlace\WonderWorld\
   2. CPT recursively parses all downloaded container files, from root containers (.layout -> .mesh -> .material -> ...):
      1. CPT reconstructs an asset's original file and type from its meta-data and renames C:\Content\MyPlace\WonderWorld\H -> C:\Content\MyPlace\WonderWorld\brownfur.jpg
      2. CPT rebases asset URIs in the container files to the local file system, http://example.com/assets/* -> file:///C/Content/MyPlace/WonderWorld/*
4. CC modifies C:\Content\MyPlace\WonderWorld\cat.material to depend on brownspottedfur.jpg, which itself is a modified version of brownfur.jpg
5. CC publishes WonderWorld to his chosen CDN
6. CPT recursively parses all container files in local inventory, from root containers (.layout -> .mesh -> .material -> ...):
   1. CPT computes a dependency graph for each asset based on it's traversal
   2. CPT creates a content hash H of the asset, and a corresponding meta-data stub, attached to it's node in the graph
      1. CPT adds the fully qualified URIs of ALL child assets to the asset's meta-data stub
   3. CPT walks the graph of parsed assets, and POSTs the binary and meta-data, in this case to http://example.com/assets/H/data and http://example.com/assets/H/metadata respectively
7. CPT copies the local inventory to the world inventory at http://example.com/inventory/MyPlace/WonderWorld/, using a WebDAV client
8. CPT creates WebDAV collections (MKCOL) for each directory in inventory, and redirected references (MKREDIRECTREF) for each asset file in inventory, in this case pointing to http://example.com/assets/H
9. CC logs into S and gains appropriate permissions to access S's world inventory
10. CC rezzes each asset by drag-and-drop operation within the world, and manually places each asset in its correct layout
11. S does a GET on each rezzed item in order to retrieve the Redirect-Ref header which contains the asset URI to be stored in the primtable
12. C logs into the S and receives notice over SLUDP of an in-world object; it retrieves the associated asset URI from the object's RexObjectProperties
13. C downloads and parses the assets associated with the object in the primtable
    1. C discovers that the asset URI scheme is "http"
       1. C does an HTTP GET on http://example.com/assets/H/metadata
          1. C reads H from the meta-data (not from parsing the URI)
       2. C does an HTTP GET on http://example.com/assets/H/data
          1. C either decodes or parses the asset depending on MIME-type, and caches the in-memory representation, keyed by H
       3. C downloads, parses, and caches ALL dependent assets listed in the meta-data
14. The renderer is notified of completed in-memory representations of an asset, and is given its key H; which it knows how to draw

Additional Use Cases

Open World

Random world on net which doesn't limit users activity much.

No ACE required by the world to users inventory.

User copies object from sim to own inventory

1. Object is copied from users client to inventory with all metadata containing creator info etc.

User copies own object to other user

1. Object owner gives read ACE to reciver. Reciver copies object to own inventory.

User rez object to world

1. Users client gives object metadata to world, which contains uri pointing to asset in users inventory. The sim can fetch collision mesh from this public uri if collision applies.

Walled garden

World where exist own economy, or game where some rules apply, or some other world where rules are "trusted".

World has ACE to folder in users inventory.

User take object

1. Users client send "take" message to server
2. Server checks that the user has permissions to take the object
3. Server copies asset metadata to users inventory with ACE and removes the object from the scene.

User buys object

1. User indicates it's intention on buying object.
2. Server checks that user has enough inworld credits.
3. Server reduces users balance and copies object to users inventory with metadata. Metadata contains information if the object can be re-sold, copied or moved to other user.

User re-sell object

1. User indicates on intention on selling object.
2. Server checks that the user has rights on selling object.
3. If user has required rights, proceeded as normal.

User give object

1. User indicates on intention on giving the object.
2. Server checks that the user has rights to give the object.
3. If user has enough rights and reciving user accepts the object, server moves object from givers inventory to recivers inventory.