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 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d