From: Peter Amstutz <[EMAIL PROTECTED]>
Reply-To: VOS Discussion <vos-d@interreality.org>
To: vos-d@interreality.org
Subject: [vos-d] second draft requirements
Date: Sat, 3 Feb 2007 17:10:48 -0500
Alright, here's a second draft of the requirements document, based on
the input I've gotten back so far.
Creating Interreality
Version 0.30.0
Peter Amstutz
Copyright007 Peter Amstutz
Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU General Public License,
Version 2 or any later version published by the Free Software
Foundation. A copy of the license is included in the section
entitled "GNU General Public License".
_________________________________________________________
Table of Contents
1. Requirements
1.1. Mission Statement
1.2. Multiuser Requirements
1.3. Online Networking Requirements
1.4. Platform Requirements
1.4.1. Basic Requirements
1.4.2. Scripts
1.4.3. Interactivity
1.4.4. Authoring
1.4.5. Behaviors
1.4.6. Audio
1.5. Client Features
1.6. 3D Graphics Requirements
1.6.1. Meshes and Effects
1.6.2. Avatars
1.6.3. Portals
1.6.4. Animation
_________________________________________________________
Chapter 1. Requirements
An unsorted list of all the thing we want Interreality 3D to
do. See the Timeline at the end of this chapter for priorities
and scheduling. Compiled from ideas and suggestions by Peter
Amstutz, Reed Hedges, Karsten Otto and Ken Taylor.
_________________________________________________________
1.1. Mission Statement
Develop a free software platform for multiuser, online,
collaborative 3D applications.
What do we mean by this?
Free Software
Interreality 3D will be released under a free software
license such as the GPL or LGPL.
Multiuser
Interreality 3D will allow many simultaneous users that
are all able to see and interact with each other, and
share a synchronized view of what is going on in the
virual space.
Online
Interreality 3D will be Internet-based. This means it
must be robust and usable over the "real Internet"
where uneven latency, firewalls, packet loss,
heterogeneous networks, narrow pipes, etc are the norm.
Respecting the distributed nature of the Internet,
Interreality 3D worlds will be spread across many
hosts, and worlds will interconnect using portals and
hyperlinks.
Collaborative
In addition to using the space to communicate with one
another, Interreality 3D will allow users to use the
space to create and work simultaneously on projects and
documents. Changes to objects will be communicated
quickly to all online users, permitting real-time
cooperation.
Platform for ... 3D applications
Interreality 3D will not be limited by focusing on a
single-purpose application but rather will be an
"engine" or "platform" that enables development of many
types of 3D applications. This will include 3D games,
social spaces, commerce, information visualization, and
education.
_________________________________________________________
1.2. Multiuser Requirements
Users shall be able to communicate using typed text messages.
Messages may be sent privately to a single other user, to
users in the local vicinity, or broadcast to the entire
virtual space as appropriate.
Users shall be able to "emote" text descriptions of their
actions.
Users shall be able to establish a long-term identity which
persists between logins of the user.
Users shall be able to securely authenticate their identity to
the server.
At the discretion of the system administrator, users may be
restricted in what they can do. The system shall have a
permissions or capabilities architechture in place that
concretely expresses how users are able to interact with the
system.
The system administrator shall be able to lock out or delete
user accounts at any time.
The system administrator shall be able to grant and revoke
privlidges to other users. These privlidges shall include
moderation privlidges that allow silencing, removing or
banning troublesome users.
Users shall be able to have inventories of objects they "own",
and transfer virtual world objects to other users. The
specifics of inventory management should be left up to
application logic.
Users shall be able to save essential information about other
users to create "friends lists".
Users shall be able to subscribe to the status of other users,
such as online, offline, or idle.
Users shall be able to securely verify the identity of any
entities claiming to be their friends.
Users shall be able to establish direct connections to each
other (thus avoiding the server) for the purposes of file
transfer or interaction in a private 3D world.
Users shall be able to form private channels with distribution
limited to a certain subset of users.
Users shall have the option of ignoring other users, both on a
limited basis (suppressing communications from that user) as
well as completely removing the offender from the user's view
of the world.
_________________________________________________________
1.3. Online Networking Requirements
Users shall be able to exchange files with each other.
All content shall be downloadable. Users shall not be required
to aquire any content in advance in order to join a 3D virtual
space.
For the best user experience, 3D content sent to the user
shall be displayed as soon as possible. Content shall continue
to download in the background. Content downloads shall be
prioritized to fetch the closest, largest or most important
objects first.
To minimize redundant downloads, the client shall support
intellegent caching of recently visited servers. Cached
objects may be displayed as placeholders (with a suitable
visual cue) while an updated version of the same object is
downloaded.
It shall be possible to interoperate with chat systems such as
IRC and Jabber and give users on these other systems a
presence in the virtual world.
The network system shall support preferential treatement for
time-sensitive data such as position updates.
The network system shall be flexible and accomodate the needs
of applications outside the immediate concerns of the 3D
space. For example, messages involving game logic.
The network system shall accomodate semantic markup of the
virtual world to support the development of intellegent agents
and agent-based simulation.
At the discretion of the server administrator, the system
shall be able to log any and all messages sent across the
system.
At the discretion of the server administrator, users may be
disconnected and/or banned. The system shall support blocking
based on identity or IP address.
Servers shall be able to link to content on other servers.
Servers shall be able to limit such inbound linking.
Clients shall be able to perform searches and queries on the
world to select data to download or filter which updates to
receive.
The client and server shall be able to interrogate the other
to determine features, capabilities and components available
on the other.
The permissions system shall support restricting what a given
user is able to acces or "see", so as to support privacy or
enforce game rules to prevent cheating.
_________________________________________________________
1.4. Platform Requirements
1.4.1. Basic Requirements
Interreality 3D graphical software shall be portable and
cross-platform, supporting at minimum GNU/Linux, OS X and
Microsoft Windows. Interreality server software shall be
portable to any POSIX-compliant operating system.
Interreality software shall be usable on modest hardware.
Interreality shall also strive to be suitable for embedded
Internet devices such as PDAs and cell phones (through a
slimmed-down subset of functionality, if necessary).
For server purposes, Interreality software should be able to
scale to multi-core, multi-CPU systems, as well as facilitate
clustering, load balacing and grid computing to support high
demand applications.
At the discretion of the server administrator, servers shall
support "instancing" virtual worlds, for the purposes of
minimizing overcrowding, gameplay reasons (instanced dungeons)
or privacy. Users shall be able to join a specific instance of
a space as a group, or invite other users to that space. Each
instance shall have separate security, so that permissions
granted for one instance are not transferrable to another
instance.
The platform shall provide a plugin-based component framework
that permits extending the platform in a variety of ways,
accessable from a variety of both statically compiled and
dynamic scripting languages.
_________________________________________________________
1.4.2. Scripts
The system shall be programmable in multiple languages. These
shall include at least one dynamic scripting language suitable
for online/on-the-fly development.
Supported programming languages shall interface with each
other using a common set of APIs. Code written in one language
should be callable from another language with no extra effort.
The system shall allow users to upload scripts and run them
securely on the server. This shall scale to thousands of
simultaneous scripts.
The system shall allow scripts to be downloaded and run
securely on the client.
User-uploaded scripts shall be able to perform the same
actions available to the user. Scripts shall be subject to the
same permissions system as users. For security purposes,
scripts may have their capabilities further restricted at the
option of the user.
The system administrator shall have the ability to impose
bandwidth, CPU time and memory/storage quotas on users.
_________________________________________________________
1.4.3. Interactivity
The virtual world shall be able to specify "clickable"
objects. Users who click on this object in the 3D view will
either send a message to the object or activate a client-side
script.
The virtual world shall be able to specify key bindings, where
pressing a certain key sends a message to the object with
focus, or activates a client-side script. These key bindings
will be specified in a manner that allows the user to remap
the bindings on their client, and save that mapping so that it
is applied every time the user visits a particular virtual
space.
The virtual world shall be able to specify entry/exit events
when the mouse pointer enters or exits the boundary of an
object in its projection on screen. This will either send a
message to the object, or activate a client-side script.
The virtual world shall be able to specify mouse movement and
raw mouse click events send a message to an object on the
server, or associated with a script.
To support a "heads up display", the virtual world shall be
able to set up multiple layers for display. Each layer shall
have separate clickable objects, separate keybindings and
mouse events handlers.
Objects may be marked as "movable", meaning the object may be
manipulated and moved by the user in 3D space. The object's
motion may be subject to spatial constraints (such as: the
object can only be moved along a line, within a certain plane,
within a certain cube of space).
_________________________________________________________
1.4.4. Authoring
Users shall be able to share write access to objects or
documents.
Users shall be able to create new 3D objects. This shall
include loading meshes from supported file formats, cloning or
instancing existing 3D objects, or by creating and assembling
geometric primitive shapes that represent the desired
geometry.
Users shall be able to import from a variety of standard 3D
file formats, including X3D and Collada. In addition, some 3D
modeling programs may be supported through the use of plugins
that export to Interreality 3D file formats.
X3D (and VRML) shall be supported including the full immersive
profile. There shall be a bidirectional mapping between X3D
and Interreality 3D capabilities and semantics. X3D scripts
and triggers shall work within Interreality 3D, with
Interreality 3D events and objects visible to the X3D runtime.
Users shall be able to edit all aspects of the world using
interactive command-line tools.
Users shall be able to edit all aspects of the world using
interactive GUI tools. Such tools shall provide the user will
full access to aspects of the system with a user-friendly
interface
The server shall support version control of objects.
The user shall have the ability to specify multiple levels of
detail for a given object, as well as simplified geometry for
collision detection or physics.
The server shall be able to impose limits on the dimensions
and complexity of objects.
_________________________________________________________
1.4.5. Behaviors
All objects shall be scriptable in a way that permits
implementing behaviors that react to their environment.
3D Objects shall be subject to: gravity, collision detection.
Rigid body physics simulation shall be available with the
ability to turn off such simulation for individual objects or
the entire scene.
Users shall be able to transfer objects from one server to
another. Object behaviors shall also be transferrable, subject
to restrictions based on the capabilities of the target
server, the permissions of the user on the target server, or
pre-arranged trust arrangements between servers (such as two
servers hosting parts of the same online game).
_________________________________________________________
1.4.6. Audio
Users shall be able to use live audio to communicate in the 3D
space. To promote a sense of immersion, audio will be
spatialized so that they appear to come from the avatar.
Objects in the virtual world shall be able to emit sound
effects as a point source. This shall include both single-shot
and looped effects. To promote a sense of immersion, audio on
the client will be spatialized so that it appears to come from
a particular direction and distance relative to the user.
The virtual world be able to designate particular areas of 3D
space to have certain sound sound effects such as music or
ambient noise.
_________________________________________________________
1.5. Client Features
Users may install their own scripts as client extensions to
provide macro capabilities and new interface elements.
Users may move around the world using configurable control
schemes and input devices.
User movement may be constrained on the client side, to impose
basic physics/collision detection without requiring
intervention by the server.
A sample application provided with the client will be a 3D
view of the user's local computer, showing files, network
connections, processes and other interesting resources or data
points.
_________________________________________________________
1.6. 3D Graphics Requirements
1.6.1. Meshes and Effects
The system shall support geometric primitives: cube, cylinder,
cone, sphere.
The system shall support Lindin Labs "prims".
The system shall support triangle meshes.
The system shall support texture mapping.
The system shall support multitexturing and material
properties based on the Phong shading model.
The system shall support normal maps and other types of
material maps.
The system shall support material shaders written in the
OpenGL Shading Languge (GLSL) or Cg.
The system shall support common, standardized graphics file
formats for textures, including PNG and JPEG.
The system shall support rendering a variety of 2D graphics
and document formats onto a texture, such as: plain text,
HTML, PostScript, PDF, SVG, ODF.
The system shall support simple animated textures (such as GIF
or MNG) as well as playing streaming back movies on a texture
(such as MPG).
The system shall support procedural textures. Client-side
scripts may be used to generate the texture image.
The system shall support portals leading from one virtual
space to another, with space-warping transforms.
The system shall support point and directional dynamic lights.
The system shall support "baked-in" lightmaps.
The system shall support dynamic shadows, such as drop shadows
and stencil shadows.
The system shall support lighting models based on dynamic
material shaders.
The system shall support multiple levels of detail, to improve
rendering and download efficiency for objects distant from the
viewer.
The graphics renderer shall provide options to the user to
limit the level of detail, special effects, lighting, shadows,
contrast or other graphical options, so as to speed up
download, rendering, or simply produce the best display on the
user's hardware.
_________________________________________________________
1.6.2. Avatars
Users shall be given an avatar to represent them in the 3D
space.
Users shall be able to select from multiple avatars, and
configure the appearance of their avatar.
Avatars shall support parameterized construction, so that a
base model can be customized by selecting, hair, skin, eye
color, clothing, body shape, sex, and so forth.
At the discretion of the server administrator, users shall be
able to upload their own avatars.
Avatars shall provide, at minimum, "walking" and "standing"
animation loops.
The server shall be able to place limits on user avatars,
including dimensions and complexity.
A default avatar shall be available.
Scripts may create and control avatar representations in the
3D space to better interact with humans.
_________________________________________________________
1.6.3. Portals
The system shall support "portals" within and between 3D
worlds. A portal is an area of space which looks into another
3D space. A user looking through a portal sees a live view of
the target world.
Users shall be able to walk through portals to move from one
world to another.
A portal may supply a particular position and orientation on
the target space that it looks on to, or connect to a specific
destination portal on target world.
Servers shall be able to restrict avatars to joining and
leaving the space through specific portals.
Portals may start out "closed" to the user. Closed portals are
opaque and may display some description of where they lead.
"Opening" the portal causes the target world to be displayed
through the portal.
The client shall keep a "breadcrumb" trail of where the user
has been, particularly portal crossings between worlds.
_________________________________________________________
1.6.4. Animation
It shall be possible to animate the motion of any 3D object,
or set of objects. Multiple animations may be blended.
Animations shall consist of a sequence of key frames
specifying the relevant object's position and rotation.
Interpolation methods shall be available to describe the
transform curve from one keyframe to the next.
Skeletal animation shall be supported.
Humanoid animations shall use a common skeleton specification,
such as H-Anim.
Skeletal animations shall allow the same animation to be used
on any model with the same structure.
Users will be able to control and trigger avatar animations.
Animations shall include loops and one-shot animations (where
the animation plays once and then returns to the previous
loop).
Animations shall have a standard speed. It shall be possible
to scale the playback speed to be faster or slower.
The system shall support streaming animation in a fashion
similar to how position and rotation updates are propagated.
The system shall support live movement tracking controlled by
appropriate input devices (head trackers, data gloves,
cameras). Client-side kinematic solvers (command the avatar to
touch a certain point or assume a certain posture) will also
use streaming updates.
The user shall be able to halt animation loops on objects.
--
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
