Architectural Overview¶

• Architectural Overview
• Introduction
• Scene description: IMML
• What can IMML do?
• IMML-based networking
• Indirect referencing of content: Metaforik
• Benefits of being Metaforik
• Further Reading
• Comments

Introduction¶

VastPark takes a very web-like approach in solving the problems of delivering immersive spaces (Virtual Worlds!).

In the above image some commonalities exist with what occurs when visiting a website. The user interacts with an HTML renderer (ie: Firefox) which downloads HTML from an HTML host (ie: Apache), the HTML is parsed and the media fetched from wherever it resides.

In general terms, the foundations of the web can be thought of as the following:

• HTML for describing the structure of a web document
• HTTP for transmitting information
• Apache/IIS/etc for serving HTML
• IE/Firefox/Opera/etc for rendering HTML
• Dreamweaver/Notepad/etc for authoring HTML
• An FTP client or equivalent for publishing HTML and media to a server

The foundations of VastPark:

• IMML for describing the structure of an immersive scene
• HTTP for transmitting information
• Apache/IIS/VastPark Server for serving IMML*
• VastPark Player for rendering IMML
• VastPark Creator/Notepad/ImmlPad/MaxImml for authoring IMML
• VastPark Publisher for publishing media to a server

You'll notice many similarities between the way the web works and the way VastPark works. Probably the most important part of all of this is the HTML equivalent, IMML.

_{* While Apache, IIS or any other web server can be used to host IMML, multi-user interaction requires VastPark server to manage the data connections. It is plausible a module for Apache/IIS could be written which does this.}

Scene description: IMML¶

During early prototypes, VastPark used a binary form of scene description which was not human readable or writeable. While this worked fine when developing in a WYSIWYG environment like the Creator, there were a number of flaws to this approach:

1. The designer needed to be constantly updated to support changes in the scene description
2. Making a small change to the scene took a lot of time
3. Standardising on a binary format was unlikely
4. Web developers are used to human readable markup

With the above in mind, we set out to create a generic specification for interacting with various forms of media (early on, IMML stood for Interactive Media Markup Language) and ended up with the Immersive Media Markup Language, or IMML, one of the foundations of VastPark.

What can IMML do?¶

IMML can't cook you dinner or do the dishes, but it is versatile when it comes to describing immersive media and by extension, virtual worlds. It can describe everything from a game of chess to a detailed virtual world.

Something which may seem controversial is the omittance of the term "avatar" and by extension, anything avatar specific from the IMML specification. But if there is no such thing as an avatar in IMML, how can it be used for virtual worlds?

Rather than having a pre-defined notion of what an immersive space might look like, we chose to stay generic while using common concepts such as a world with avatars for one of the use cases.

An avatar in VastPark is the combination of:

• A Model element for visual representation
• A Plugin or Script element to manage the user input and avatar behaviour
• A Network element nested in the Model, with the Owner attribute assigned appropriately

Why was it done this way? Flexibility and the desire to avoid artificial limitations to creativity!

IMML-based networking¶

The IMML specification defines that Network enabled elements must be automatically synchronised across a given network scene, simplifying the work required by you as the developer.

Fine grain control can be applied to the synchronisation in the form of Network Filters. These filters are able to define the upper limit to the number of network updates sent per second.

In the following example, the Position and Rotation attributes are limited to 30 and 10 updates per second respectively:

1 <Model Source="...">
2   <Network Owner="1234" Enabled="True">
3     <Filter Target="Position" Enabled="False" UpdateRate="30"/>
4     <Filter Target="Rotation" Enabled="False" UpdateRate="10"/>
5   </Network>
6 </Model>

Now that we have an idea how IMML assists us deliver the description of an immersive space, we can move on to the second area of interest which is content acquisition and it's companion spec, Metaforik. You can find out more about IMML in the Working with IMML section.

Indirect referencing of content: Metaforik¶

Metaforik is another light-weight, XML specification that has two primary components:

1. The idea of media as a concept
2. A link between the concept and potentially many assets which represent that concept

VastPark encourages, but is not limited to, the use of Metaforik for links to content.

Consider the following scenario:

• A modeller at the fictitious K9Publishing has created a 3d model of a dog
• The modeller wants to allow everyone to find and use this dog
• K9Publishing have their own servers for asset storage

Step 1: Upload the model to storage

Step 2: Create an entry in the Metaforik index

This entry is known as an Item.

In this scenario, the Item describes the concept of the dog and has one Asset with a direct link to the location of the model. The metadata related to the item is now available in search requests.

Note: The above steps are the primary purpose of the VastPark Publisher application, making the procedure very simple.

Once the content is indexed, it's accessed like this:

Step 1: Request content from index

This returns an Item which can contain a number of nested Asset elements.

Step 2: Process Item to discover correct Asset

Selecting the correct Asset is the responsibility of the client application and is done using the attributes available at the Asset level, including TargetDevice and TargetPlatform.

Step 3: Download the asset from the selected Asset's Source attribute

Benefits of being Metaforik¶

By publishing your assets to the Metaforik index, you gain the following benefits:

• Group level access permissions at both Item and Asset level. Assets can be discoverable or private to your group
• Customisable asset availability, StartDate and EndDate that indicate the valid timeframe for an Item to be available
• More fluid coding, IMML referencing Metaforik Items can be written once and run anywhere. Assets for each platform can be linked to the same Item and the client makes the decision which Asset to consume.
• Association of metadata, such as author, license, tags and description
• Convenience around updating assets, no hard-links to asset filenames means less chance of breaking an existing link to that asset

Further Reading¶

See the Developer section of the wiki for further information.