Below is the current version of the ARBlip specification.
This is a constantly evolving format, but below is the current working draft.
This data is to be stored on a per-blip base's within waves. Each ARBlip representing one AR object (3d mesh, text audio etc) positioned in 3d space either to absolute or relative co-ordinates.
Data:
(below is the data to be stored expressed as a c++ object with a few random functions)
------------------------
class arblip
{
public:
arblip();
~arblip();
arblip(QString,QString,double,double,double,int,int,int,QString);
QString getDataAsString();
QString getEditors();
QString getRefID();
QString getXAsString();
QString getYAsString();
QString getZAsString();
bool isFaceingSprite();
private:
QString ReferanceID; //ID reference. This would be a unique identifier for the blip. Presumably the same as Wave uses itself.
QString Editors; //List of editors of this object
int PermissionFlags = 68356; // default 664 octal = rw-rw-r-- (permission flags, in case Wave dosnt come up with a solution itself)
//Location
double Xpos; // left/right
double Ypos; // up/down
double Zpos; // front/back
//Orientation
// names, ranges and directions are taken from aeronautics.
// If no orientation is specified, it’s assumed to be a facing sprite.
int Roll;
// Roll: rotation around the front to back (z) axis. (Lean left or right.)
// range +/- 180 degrees with + values moving the objects right side down.
int Pitch;
// Pitch: rotation around the left to right (x) axis. (tilt up or down)
// Range +/- 90 degrees with + values moving the objects front up. (looking up)
int Yaw;
// Yaw: rotation around the vertical (y) axis. (turn left or right.)
// range +/- 180 degrees with + values moving the objects face to its right.
bool FacingSprite; //if no rotation specified, this should default to true
//if set to true when a rotation is set, then it keeps that rotation relative to the viewer
//not relative to the earth.
//Data format
QString DataMIME; (The MIME type of the data. Such as )
QString CordinateSystemUsed; (the co-ordinate system in use)
//The Data itself
QString Data;
QString DataUpdatedTimestamp; //Time the Data was updated/changed, not merely when the blip was changed.
QString DataARBlipUpdate //Note; This is a separate timestamp should be used for all updates even if the data wasnt changed.
//Note; By having seperate timestamps the client can know exactly when it needs to redownload linked data (such as a 3d mesh) rather then when data was merely moved. This way we can remove pointless redownloading for every movement.
//Data metadata
QMap<QString, QString> Metadata;
};
Method of storage:
This is still to be pinned down. We can store it very easily by creating a new Blip in a wave, then adding the data as annotations. This has the advantage that the data is easy to update. Each annotation is a key/value pair, and can be updated independently of the other data. However, annotations are designed for text manipulation and thus also have a "start" and "end" integer field as well as the basic key/value pair. This might make them take up more space then is nesscerly for our purpose's and thus building the system around them might bring in some pointless overhead. (is this a question to the sever guys? does "null" data in the start/end field effect performance). Other options for data storage include using a custom widget, or just literally storing it as text. These have their own pro's and con's.
For now I recommend proceeding with annotation-based storage, but keeping our eye on performance issues.
Uploading ....