[vos-d] VOS requirements
Peter Amstutz
tetron at interreality.org
Wed Jan 24 00:53:40 EST 2007
I've started writing up a requirements document for VOS. While we've
had unstructured "TODO" lists in the past with various ideas for
features, we've never sat down and tried to document exhaustively what
exactly it is that we want VOS todo. I think having it written down
will help us get on the same page with regards to what the ultimate
goals are. It's also necessary for planning, and for connecting
features in the actual design to specific capabilities we want.
By the way, I've started referring to the overall 3D platform (but
particularly the end-user browser application) as "Interreality 3D".
This means I're retiring the old name "Ter'Angreal", at least in terms
of the public branding. The name may stick around internally as a way
of distingushing the client application model from pieces like A3DL.
Everything is getting rewritten (again) for s5 anyways.
Why am I working on all this documentation stuff instead of coding?
Well aside from the reasons stated above, I'm working on finding funding
to be able to start "Interreality Consulting", which will enable me to
work on VOS full time. So I see this as a time investment now that will
help things to proceed more smoothly down the road. Also, I wanted to
start documenting the proposed design of s5, and the best way to do that
is to be able to connect each design decision to fufilling a specific
requirement.
So, here's the requirements. Comments and additions are welcome -- this
is a first draft and I'm sure there are lots of oversights. If you have
a pet feature you'd like to see, now is the time to get it in so it can
be considered seriously later on.
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. Scripts
1.4.2. Interactivity
1.4.3. Authoring
1.5. 3D Graphics Requirements
1.5.1. Meshes and Effects
1.5.2. Avatars
1.5.3. Animation requirements
Version 0.30.0
_________________________________________________________
Chapter 1. Requirements
An unsorted list of all the thing we want Interreality 3D to
do.
_________________________________________________________
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.
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.
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, scientific 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 use VOIP 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.
Users shall be able to establish accounts which persist when
the user is not logged in.
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.
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.
_________________________________________________________
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.
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 all chat messages.
At the discretion of the server administrator, users may be
disconnected and/or banned. The system shall support blocking
based on IP address.
_________________________________________________________
1.4. Platform Requirements
1.4.1. Scripts
The system shall be programmable in multiple languages. These
shall include at least one dynamic scripting language suitable
for on-the-fly development.
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.
Scripts shall be able to perform the same actions available to
the user.
Scripts shall be subject to the same permissions system as
users, with additional restrictions on cpu and memory usage.
_________________________________________________________
1.4.2. 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.
_________________________________________________________
1.4.3. 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 assemblinga
"prims" that represent the desired geometry.
Users shall be able to import from a variety of standard 3D
file formats, including X3D and Collada.
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.
_________________________________________________________
1.5. 3D Graphics Requirements
1.5.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 playing streaming back movies on a
texture.
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.
_________________________________________________________
1.5.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.
_________________________________________________________
1.5.3. Animation requirements
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.
If an animation is particularly lengthy, it shall be possible
to begin playing back an animation before it has been
completely downloaded.
--
[ Peter Amstutz ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[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 ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.interreality.org/pipermail/vos-d/attachments/20070124/42b26623/attachment-0001.pgp
More information about the vos-d
mailing list