User:Burhop Piccard/Geometry Based Architecture View

This is an geometry oriented architectural view which I hope will stimulate some discussion on providing better functionality and tools for content creation. I also hope it will provide some useful input to the AWG in defining the protocols for comunication of geometric data. Please see the discussion page for more information --Burhop Piccard 19:06, 30 October 2007 (PDT)

Overview

Communication

Communication between components is represented by red arrows. This is expected to 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 width, it should be possible for the viewer and asset server to negotiate what will and will not be transferred.

The extreme example would be a high power workstation with a low latency/high bandwidth communication pipe to an asset server. This workstation would be capable of displaying high detail/large content geometry. At the other extreme might be a cell phone 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 communicate 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 persistent storage. 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 communicate directly with the Agent Domain. For example, these might be programs like Maya, Blender, 3D CAD applications or user created tools. These applications might connect directly with the Agent Domain or they could make use of a common client side library that handle the 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. For example, geometry represented by format F or G and stored on the Agent Domain would require an equivelent plugin for the client that is able to display format F or G.

In the view above, no SL renderer plugin is displayed. In a more pure or non-SL view, one would expect that SL data would have its own plugin. For example, this would be the case where a non-SL viewer was displaying SL geometric like Prims and Sculpties.

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 communicate this data to the Agent Domain and the Agent Domain provides a way to store this data. Further, 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 possibility for supporting additional rendering needs and creation tools. There may be other solutions.

Viewer Evolution

One of the desires of the AWG is to keep existing SL functionality working while a more open architecture is implemented. One possible evolution is below:

The first step is to provide some way of displaying non-SL geometric data. In the ilustration, this is done by providing a rendering plugin for other goemetric formats. Existing SL geometry (Prims, sculpties) are still handled internally as is done today.

The second step would be to exterinalize the SL geometric data. Although perhaps not needed for the existing SL viewer, those wishing to create entirely new viewers might better follow this model.