User:Burhop Piccard/Geometry Based Architecture View

Overview

Communication

Communication between components is represented by red arrows. This is expected by be carried out by a services based Rest protocol and defined by the AWG.

The requirement from the geometry perspective varies depending on the path. Third party applications wanting to upload data to an asset server would value thoughput over latency and granularity.

Communication with the viewer requires minimum latency and greater control of the input stream. Initially, the protocol needs to support existing Second Life Geometry (Prims, sculpties) but needs to be extendable to new SL data types as well as External data types.

Because External data types may or may not be supported by the viewer and because the external type may require excessive band with, it should be possible for the viewer and asset server to negotiate what will and will not be transfered.

The extreme example would be a high power workstation with a low latency/high bandwidth comunication pipe to an asset server. This workstation would be capable of displaying high detail/large content geometry. At the other extreme might be a cellphone with a slower network connection. The cell phone should continue to function in a reasonable manner despite the content on the server.

Components

The components and applications are represented by boxes show the AWG defined components (green, blue, red) as well as 3rd Party applications used for the creation of geometric content (purple). This view shows multiple ways that various tools might interface with the AWG defined architecture. The primary AWG components are the Agent Domain and the Region Domain. These are described in the AWG Proposed Architecture.

Third party components are described below:

Web Application A represents a web based client that can read and write from various persisted geometric data formats. It is able to comunicate with the Agent Domain to upload or download data. For example, it might provide a way to upload obj, collada, JT or other data formats into the Agent Domain.

Web Application B represents a web based client with no persistant storge. It might be a web Application that creates geometry and stores it in the Agent Domain. For example, it might create a cube, combine it with pictures from Flickr and upload a "picture cube" to the asset server. Initially, Web Application B might be limited to existing SL geometry types but could expand to other areas as the architecture progresses.

Application C and D represent applications (new or existing) that comunicate directly with the Agent Domain. For exmaple, these might be programs like Maya, Blender, 3D CAD applications or user created tools. These applications might connect directly with the Agent Domain but it is expected A client side library would be created to handle the common marshalling/unmarshalling of data that is common for these tools.

Plugin E Is a tool made to integrate with the viewer. It might provide "in world" geometry creation tools.

Render Plugin Inherent in this design is the ability to work with all types of geometry, not just the existing SL data types. To provide support for other data formats, it will be necessary to be able to render this data. Based on the data provided by the Agent Domain (and Region Domain?), the viewer will need to call the required functions in the rendering plugin to display the data.

Persistant Storage

Persistent storage refers to geometric data and assets which are generally saved to disk. This includes all types of 3D file in formats like OBJ, COLLADA, JT, and many others.

While these formats may be very good for storing data, few are suited to what SL and other VW's need. They may be too bulky, or represent multiple geometric assets. Implicit in this diagram is the conversion of data to more VW friendly formats before adding them to the Agent domain. This "optimized" data would initially be the existing SL supported data types."

In some cases data may be useable in a VW environment but is not in a format supported by the current Agent domain or Viewer. This is indicated as "Client Specific" data. It is expected that the AWG based architecture provides a way to comunicate this data to the Agent Domain and the Agent Domain provides a way to store this data. Furthere, the AWG based protocols are able to pass this data to the Viewer (provided the Viewer has a plugin or other solution for rendering this data).

Viewer

There are a number of different ways in which a viewer might be defined architecturally. One possible version is included here mainly in recognition of some of the requirements of content creators. That includes better building tools (in world) and support for non-native formats.

As stated earlier, the viewer can not be expected to display any possible geometric format (just as a web browser can not display all types of internet content). Plugins are a posibility for supporting additional rendering needs and creation tools. There may be other solutions.