By Eskil Steenberg & Emil Brink
Copyright (c) 1999 Obsession Development

Welcome to a guided tour of Verse. It will take you through the system, and show you some the wonders of Verse. Be sure to sit comfortably, and please refrain from smoking (or don't). Thank you. :)

Start
Verse is a network protocol, for three-dimensional, client/server graphic applications, designed to let anyone build and distribute a 3D "world" on the Internet (or any other TCP/IP network, of course). Even though there have been made attempts to make 3d mainstream on the net in the past, they have lacked some features that are, in our opinion, essential.

• Multi-user capabilities
• Scalable 3D
• Scalable physics
• Client-provided data (such as avatars)
• Open source
• Relative easy to use
• Free
• An open API
• High network and graphic performance
• Modular
• Servlet-interpreted code in any language
• Objects can be built in most 3D software

These are the features that the Verse system is meant to provide and many more are possible, due to the open architecture.

Client/Server
Verse is built around a client/server architecture. This means that in order to do anything, one first has to start a server. The Verse server doesn't actually do much: it basically just stores a big heap of data. This data is divided into "chunks" we call nodes (explained later). To view or interact with this data, you connect a client to it, the client can then read and write the data. A typical client is a viewer that can read the 3D data and display it on screen. The client/server connection is networked and uses the UDP/IP protocols to communicate. This means that the server and the client can communicate locally over a LAN or globally over the Internet. To make the world more realistic and interesting, one may want to connect other clients to the server to controls and make changes the world.

It's not too unlikely that one wants some laws of physics to apply to the world; implementing physics is typically left to a "physics engine client". A physics engine is a typical example of a "server-side client", or servlet. It runs as a client, but is most likely located at the same computer as the main server. It could also be situated on a computer "near" the main server (i.e., on the same LAN). This architecture makes the system very flexible, since you can connect any clients you want to your system and anyone can write new clients.

Rights & Security
If a user is walking around in the world, he/she would do so by changing the data in the server that describes where the user is. Immediately we come across a number of problems: what if the user moves at the speed of light? Or starts moving other users? Or maybe the scenery? Or what if he/she swells up and becomes huge, possibly filling up the entire world? Clearly some form of rights system is needed, to support limiting a user's freedom. This is one of the few things that the server does. Different clients may have different rights. A human user may not have as much freedom as, say, a physics engine since the laws of physics should be applied to the entire world.

Nodes
The data in the server are divided into nodes. There are currently seven different types of nodes. They are:

• Object node
• Geometry node
• Material node
• Bitmap node
• Emitter node
• Code node

The different nodes point at each other to create a scene graph that describes the world. When a client connects to the server, it can choose what parts of the data it wants to download. When the client has downloaded a node, it will continuously get updates from the server on how the data changes. This makes it possible for the client to decide how much it wants to download. A client can also upload new nodes to change the world state.

Running Code
One important node is the the code node. It is used to store source code, in any programming language. To execute the code in a code node, there must exist an interpretating servlet for that language. This servlet searches for code nodes with a specific language, and if it finds one it starts to execute the code within the node. Anyone can write an interpreter that interprets any language, so the system i not locked in to any specific language. The languages we will focus on at the current state is C/C++ and Java, but we encourage anyone to write other interpretations. The code node makes it possible for anyone to write a interactive object and use it in any server, leave it and let other people us it and bring it to other servers.

Standard API
To make it easy for anyone to write applications that talk to the server we will design a library that talks to the server. This means that you don't have to learn how to network anything since the library does that for you. The library will be ported to as many platforms as possible to make your program as portable as possible. As always the source code for the library, and the rest of the system will be made available. We will try to keep a very open policy and publish all documentation and even future plans.

3D Graphics
The 3D graphics data is designed around the philosophy of "perfect data", it means that the data doesn't describe how to render the graphics, but more how the graphics should look. Then it is up to client to do a "best effort render" of the data. The 3D data is based around a single primitive: subdivided polygons. A subdivided polygon is basically a normal polygon, but it can be subdivided to create a 3rd degree curved surface.This means that you may display the graphics as simple, planar, polygons, but you can also subdivide them to increase the smoothness of surfaces. It is also very compatible with a lot of 3D software out there, since you can convert polygons, B-splines, patches and NURBs in to subdivision surfaces without much trouble. A lot of real-time technology today is based around polygon reduction, where a complicated mesh has its geometry reduced in real time, thus creating a less complicated mesh which renders faster. In our case this type of technology wouldn't work, since since we can't transfer huge meshes over the network. It is also a waste of time to model huge meshes that will be reduced to simple meshes when used. Therefore we use low-polygon meshes that can be reduced, if needed but also tessellated to add complexity, and together with displacement mapping detail. Another problem with polygon reduction is that if you have, say, a 5,000 polygon human, and algorithmically reduce it to 250, it will never be as good as if a human did it.

Time
Verse counts time in milliseconds (thousands of a second) and it doesn't have a set rate of how often things are updated. Since the system is based on clients doing all the changing of the data, one can't trust that a client have the time and ability to do its job in a set rate. For this reason, they will just have to do things as good a possible under the circumstances. To make this efficient, one must be able to precalculate future actions. For example: say that someone throws a ball towards a wall. The physics engine now has the opportunity to compute not just the first collision between the ball and the wall, but several future collisions as well. This is good, because it means that the physics engine need not actually run at the time of those later collisions, and it need not communicate with clients at that time either. The server can distribute information about all collisions to the clients long before the collisions are expected to occur. Thus, even if the network connection is lost after these messages have been sent, the ball will still bounce correctly. Of course, such a system requires that the physics engine gets a chance to recompute collision events when the world changes.

Goals
This is a project that can only be realized as a free and open project. We will write the server and client APIs, but they are not worth much if people don't use them by authoring content and writing all sorts of clients. The system is not designed to do one specific thing, it is designed so that you can use it for whatever you want to do. Verse is infrastructure, not application.