Aesel
2.0
- Getting Started
- HTTP API
- Advanced Topics
- Aesel
-
Page
- Aesel Design
- Section 1: Abstract
- Section 3: Individual Workflows
- Section 4: Configuration Options
- Aesel Design
- « Design Documents
- Aesel High Sp... »
This document outlines the design for Phase 1 of the Distributed Visualization Server. This is a system for allowing many different user devices to visualize the same 3-Dimensional objects in real-time. While additional workflows are planned, they will not be outlined within this document.
This consists of a number of different components, so this document will focus on integration-driven flows. The document will proceed on a workflow-by-workflow basis and provide the basis for a solid API design.
The following workflows will be outlined in the below document:
The following custom components will be utilized within Aesel:
| Type | Name | Description |
| Gateway | Adrestia | Gateway for Client communications to be translated into Protocol Buffer or JSON Messages |
| Data Storage | Mongo | Storage of text-based data to hold Mesh data, Shader data, etc |
| Transformation Updates | Clyman | Storage for Object Transformations with real-time change feeds |
| Scene Data Storage | Neo4j | Stores Scene information, and is the primary database for CrazyIvan |
| Scenes & Coordinate Systems | CrazyIvan | Tracks sets of objects & user devices which form scenes to know what to load. Tracks coordinate systems to resolve the differences between devices. |
| Asset Management | Kelona | Manages Assets and tracks different versions of Assets over time. |
| Term | Description |
| User Device | A Unique Hardware device utilized by an end-user to render the objects received from Aesel |
| Object | An Object in 3-space that is being rendered and/or interacted with by user devices |
| Scene | A logical grouping of objects which devices can register to. Each scene is associated to a particular coordinate system |
| Coordinate System | A set of 3 Axis (X, Y, & Z), as well as an origin. Coordinate Systems are stored in relative terms, using matrix transformations to move from one to another. |
| Transaction | A single interaction with Aesel by a client through the HTTP interface. Strong consistency and atomicity are guaranteed, with slower performance profiles than events. Confirmation is received synchronously. |
| Event | A single interaction with Aesel by a client through the UDP interface. Weak consistency and atomicity is not guaranteed, with much faster performance profiles than transactions. Confirmation is received asynchronously. |
| Scene Cluster | A cluster consisting of one or more instances (and/or clusters) of CLyman, Crazy Ivan, Mongo, and Consul Agents. Responsible for serving up Object information for one or more particular scenes. |
Device-Scene Registration occurs when a User Device either:
The following are necessary inputs for this workflow:
Upon receiving the request from the client, we send a message to the Scene module requesting registration. When registration is successful, we return the Scene ID and the Obj3 ID’s to be pulled.
The following are the outputs for this workflow:
A Scene Transfer occurs when an object is removed from it’s current scene, and is registered to a new scene.
If a calculable coordinate system transform is available, then it is returned to the device. Otherwise, it is approximated and a flag is returned notifying the user device that Scene-Scene coordinate synchronization is needed.
The following are the outputs for this workflow:
Device-Coordinate Synchronization occurs when a User Device wishes to re-calibrate it’s current scene transformation relative to it’s local coordinate system.
The following are necessary inputs for this workflow:
This message is used to dial-in scene transformations. Upon receiving the request from the client, we send a message to the Scene module and pass back the confirmation.
Confirmation or Error
Scene-Scene Coordinate Synchronization occurs when a User Device wishes to re-calibrate it’s current scene transformation relative to it’s previous scene.
The following are necessary inputs for this workflow:
This message is used to dial-in scene-scene transformations. Upon receiving the request from the client, we send a message to the Scene module and pass back the confirmation.
Confirmation or Error
Device-Scene Exit occurs whenever a user device leaves a scene
The following are the inputs for this workflow:
Upon receiving the request from the client, we send a message to the Scene module requesting de-registration. When de-registration is successful, we return the confirmation.
Confirmation or Error
Object Creation is the act of making a new Object across all User Devices.
Upon receiving the request from the client, a message is sent to the Scene Module with all the information. The object is added to the scene within the Scene Module. Then, a message is sent to Ceph to save the Mesh, Shader, and other information. Then, the resulting keys are added and the rest of the information is saved to Clyman, which generates an outbound message on the response streams in the gateway.
Object Destruction is called to remove an Object from all User Devices
Upon receiving the request from the client, a message is sent to the Scene Module with all the information. The object is removed from the scene within the Scene Module. Next, the Asset ID’s are retrieved from Clyman. Then, a message is sent to Ceph to remove the Mesh, Shader, and other information. Then, the rest of the information is removed from Clyman, which generates an outbound message on the response streams in the gateway.
An Object Update, or Transformation, is a special flow in that it only hits Clyman. These are designed for high-speed processing, and generate outbound messages to update all devices of the changes.
Upon receiving the request from the client, a message is sent to Clyman to apply the transformations specified. This generates an outbound message on the response streams in the gateway.
Object Asset Update is called to edit the assets that make up an Object, and push the update to all User Devices.
Upon receiving the request from the client, a message is sent to Ceph to overwrite the data there. Then, a mesh update message is sent to Clyman, which generates an outbound message on the response streams in the gateway.
Object Retrieval comes when a Device needs to load the assets and transform information for an Object.
Upon receiving the request from the client, a message is sent to Clyman to retrieve the Transformation information and Asset ID’s. Then, the Asset ID’s are used in messages to Ceph to retrieve the asset information. All of this information is assembled and passed back to the Device.
A User Device Lock is used to prevent other User Devices from updating an Object, until it is released.
Upon receiving the request from the client, a message is sent to Clyman to establish the transformation lock.
Releasing a User Device Lock allows other Devices to establish locks or update the Object.
Upon receiving the request from the client, a message is sent to Clyman to release the transformation lock.
Several Configuration Options will be available within the DVS Server, each with different objectives.
Each Service will either accept or generate a transaction ID, such that any individual transaction with a User Device can be traced through each service that it hits.