IRC Channels
IRC Protocol interface. (Later GoogleWave?)
Reads/Writes AR strings to the
IRC channels the user is logged into.
Also handles logging in/out of those channels.
File Sever
When an AR string indicates a file needs
to be downloaded, this downloads and caches it to
a directory which the renderer can access. When
the user posts a model, this file sever can host it
ready for other clients to connect to and download.
(Can use standard ftp protocols?)
Renderer

Taking Log/Lat/Alt specified by the Protocol interface,
(and possibly meshs downloaded by the filesever),
it overlays the objects in the field of view in the correct
position.
The renderer will also place meshs aligned to real world
objects where such associations have been specified by
the protocol. This could be simple marker-based alignment
or more sophisticated markerless solutions, such as
Total Immesions D’Fusion technology.
(Users current GPS co-ordinates and direction
taken from the device they are using )
GUI
The interface allows the user to log on/off
any channel, as well as positing a message in
mid-air at the current co-ordinates. Later
versions could allow moving/editing and
3d modeling.
# AR Urban Games
# AR PrivateChat
(Another Client)
# AR City Map
Arn v0.001 'SkyWriter' - Basic concept for an open multi-source AR framework.
Basic Starting Concept:

a) To allow anyone to write messages in midair on a specific channel, which are visible to everyone
logged into that channel at the time they are written.

b) To allow users to see messages from multiple channels at once.

c) To be decentralized.

Requirements:

The protocol/framework developed should be able to be able to handle both loosely bounded
facing text (todays "AR"), and in future tightly bound meshs skinning real world locations. (The AR goal)

To achieve this protocol will be designed to enable posting 3d objects rather then just text,
moving objects already posted to new locations, and allowing complex games to be developed
based around IRC bots moving/changing the objects posted. Even if clients and hardware
cant yet tie 3d data precisely to locations, the ability in the protocol should be there.

Additionally, IRC Bots could also be used to post a back-log of messages on request from another
client. (allowing users to see things that were posted before they logged on). At some point
standard "request strings" should be speced out for this purpose.

The system should also be designed so that its later possible to switch to more modern open
protocols such as GoogleWave. (Which would remove the necessity for reposting mentioned
above)
Notes;
An AR String would be an XML formatted string containing all the information
needed to post a message or 3D model at a specific location in real space. For an
example and more information of how this could be formatted, see
"Anything Anywhere"; If a bit of text is all that's being displayed in midair,
rather then a 3d object, it could simply put inline within the
XML-AR string;








==
To keep the diagram to the left simple, Ive just refereed to the
basic flow of information. In terms of coding, some interactions would
need to be more complex.
For example, the gps co-ordinates would determine if a mesh was in range, or
nearly in visual range, and thus if it needs to be downloaded or not.
1
ID=”DARKFLAME:1”
Obj=”HELLO WORLD! This is a demo message”
Loc=”(49.5000123,-123.5000123) Alt: 10.123m"
Permissions=”None”
LastUpdate=”12/12/0000,2012:12”
/>
(example concept of AR update string,
details still to be discused)
Static http hosted 3D Content.
Perhaps IRC could trigger links to 3d worlds hosted
on http. (Such as; Gamarays dimension format
, or Layer's...umm....Layer format)