[vos-d] second draft requirements
Rob Meyers
robmeyers at hotmail.com
Thu Feb 22 23:16:24 EST 2007
Hey yall, last time I wrote to this group was several years ago, but I have
been reading the messages as they come along. I took an interest in your
work back then as I was struck by the similarities it had with the project
VRSpace I was working on at the time. So I read this set of requirements
and thought I would throw in my two cents.
In terms of your scripts section, it would be great to have a COM binding to
your api. Although this is pretty winders specific, it opens up all your
code to .Net. I've done some work with editing worlds while you are in it,
i.e. your interactivity section. Being able to click on the movable objects
and having a visual interface to move it around is very helpful. But this
idea can be taken a lot further, namely having an editor that allows you to
click on an object and see all of its available properties, methods in and
out and allows you to change these fields, invoke the methods, etc. Very
useful for debugging.
And if anything is on the wish list, having 3D versions of the most common
controls available, i.e. panels, texboxes, labels, scrollbars, etc for
building a front end in the hud would be fantastic. If field/events from
these widgets are available throug the api, then viola 3d apps. No reason
to restrict them to placement in the hud... so you can put a textbox on some
object e.g. Either way this property editor mentioned above comes into to
augment the front end building experience. Way back when, I think I
suggested having the ability to drag a file onto the front end and have its
geometry to pop up in the world. Basically, I am in support of anything
that makes it easier to put content in the world and manipulate it.
I've recently been building a new framework for making 3d apps called
AstralX. To test out its capabilities, I originally wrote a chess program,
but that was a boring game. So I've built a version of HeroQuest, a
boardgame from way back, which is pretty much so completed. Check out some
screenshots of the game in play at:
https://sourceforge.net/project/screenshots.php?group_id=125518&ssid=53527
https://sourceforge.net/projects/astralx/
AstralX is written in C#, uses BitManagement Contact, so all the geometry is
VRML/X3D.
Good to see you guys still in action,
Rob
>From: Peter Amstutz <tetron at interreality.org>
>Reply-To: VOS Discussion <vos-d at interreality.org>
>To: vos-d at 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 ][ 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 ]
>
><< signature.asc >>
>_______________________________________________
>vos-d mailing list
>vos-d at interreality.org
>http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
_________________________________________________________________
Win a Zune™—make MSN® your homepage for your chance to win!
http://homepage.msn.com/zune?icid=hmetagline
More information about the vos-d
mailing list