This is a sporadically ongoing diary for a project that I hope someday results in a prototype of a scalable system that allow user to receive visitors and interact with them within their own customized online landscape. Alas, it's a huge, huge project, and real life has interceded many times.

  • Distributed server architecture
  • Large number of clients
  • Infinitely tiled ROAM landscape
  • Complex building interiors via multiple BSP trees with connecting visibility portals
  • Continuous incremental network loading

   
Who's on now?

Ancient Build
This is a Win32 application that requires OpenGL and a 3D accelerator card such as a TNT2 with lots of texture memory. A reasonably fast Win98 machine with DirectX8 and a 3D card should work.

Vegetation Objects
The 3D environments are configurable. Landscape, textures, and objects may all be unique to any given server. Here's how to edit or create the vegetation objects on your server.

Duchaineau ROAM paper
This describes the polygon tesselation algorithm that is the basis of the landscape renderer.


I. Overview

This program is an implementation of a 3D graphical environment that is intended to allow multiple users to interact with one another in a virtual landscape.

Components include a rendering client, a position server, a directory server to allow clients to locate remote position servers, a tile editor that produces landscape and architecture data, and a tile compiler that produces landscape tesselation and BSP tree binary tile files.

II. Landscape Tiles

A landscape consists of a number of adjacent tiles, with each tile containing a heightmap, architecture objects, building and underground interiors, and references to texture resources needed to render the tile. The client rendering software will typically maintain a subset of surrounding tiles in memory, discarding and loading new tiles as the user moves around on the landscape.

The environment consists of groups of adjacent tiles. Tile groups may have no correlation with each other, or may be constructed in such a way that one group is geographically adjacent to another group, forming a larger meta-group that is to be presented in a seamless manner to a user.

A position server is authoritative for a particular group of tiles. Clients are handed off to other position servers as they move from from one tile group to another.

III. Client/Server

The user program consists of two major components. The first component is a client that has the task of accepting commands and movement intentions from the user and rendering 3D scenes. The second component is a server that has the task of accepting movement intentions and transmitting position information back to one or more connected clients.

position server and client

When the program is operating without any network connectivity, the client is connected to the local server, and the local server maintains the client's position within the confines of the tile group that the local server is authoritative for. The user "owns" the local tile group and can modify them to suit herself.

With network connectivity, a client can maintain a position within the local tile group, or can venture out to other tile groups on remote servers. The client operates in essentially the same way whether it is running as a standalone program or connected to a remote position server.

IV. Peer-to-peer

When a position server is run, it can transmit its presence to a publically-known directory server. Remote clients can discover available position servers by querying the directory server. Thus, a client may wander around on a group of tiles that are outside the jurisdiction of its own local position server. A position server can have more than one client sending movement information to it. In this scenario, clients send movement intentions to the server, receive position information for themselves and other clients connected to the same server, and are able to interact with each other.

how a client finds another client

V. Adjacent Tile Groups

Tile elements are arranged in two-dimensional coordinate space. A tile with coordinates of 0,1 is the tile adjacent to and to the "north" of a tile with coordinates of 0,0 if those tiles are in the same group. Tile groups may or may not be related to tile groups under the jurisdiction of other position servers. Position servers can be configured to "know" about neighboring tile groups, and can hand clients off to neighbor position servers.

In the following example, servers A and B are typical of a user's local tile group, geographically isolated and not adjacent to any other tile group, or they could be adjacent to other tile groups, but not adjacent to each other because they occupy conflicting 2D world coordinate space. Server C, lacking a tile with coordinates 0,0, is likely a neighbor of some another tile group. Servers B and C could be neighbors, with B's tile 2,1 adjacent to C's tile 3,1.

server tile groups

As a client approaches the edge of B's tile set, it discovers that neighboring tiles are hosted by C, it establishes an identity with C and begins to update C, as well as B, with its desired movement. C is thus able to inform clients that are already connected to it of B's clients on a proximity basis. The boundary between B's tiles and C's tiles is seamless, and when the client crosses it, it begins to rely on authoritative position information from C.