An overview of Universal Avatars |
Working Draft #1
Revision 1b - 8-15-96
by
Moses Ma, Velocity, Inc -
moses@velo.com
Dan Greening, Chaco Communications, Inc. - greening@chaco.com
Maclen Marvit, Worlds, Inc. - maclen@worlds.net
Abbott Brush, IBM, Inc. - brush@vnet.ibm.com
This paper proposes an extension to the emerging VRML standard, to specify avatar descriptions (i.e., user representations).
Avatar standardization is critical for the growth of the virtual world industry. As virtual worlds become widely deployed, users will want to move from one virtual world to another, carrying their physical attributes, belongings, mood, behaviors and preferences with them in one universally recognized format. Virtual world content providers will market to those avatars, and so buying patterns, monetary exchange, security, and authentication must be maintained in the avatar. In addition these benefits, using standardized avatars can help in using Internet search engines for avatars and avatar properties. Finally, avatar companies have become common--they can price their avatars at a lower cost, make them available to more people and guarantee broader applicability, if there is a universal avatar format.
Virtual Reality Modeling Language (VRML) and HTML share the HTTP protocol and URL's. However, the act of constructing HTML and VRML documents differ significantly. VRML is a subset of the Silicon Graphics Inc. (SGI) Open Inventor three dimensional (3D) graphics object-oriented programming language with added network extensions. There are several reasons why such an undertaking was initiated. First, there is no provision within HTML for the description or inclusion of 3D objects or 3D representation of information. This omission from HTML excludes both the possibility of creating a standard 3D environment in which the objects have behavioral attributes and additionally the ability for users to interactively manipulate objects.
For a complete discussion of the full VRML specification the reader is directed to view the complete specification. However, in its simplest terms, VRML is an animated scene description language. Its simplicity comes from its primary reliance on simple geometric objects for the construction of all objects. So, the primitive sphere, cube, and cones are combined to form more complex objects. Following is an example of the source code for creating a cube.
(From the VRML Version 1.0 Specification.)
Various properties can be assigned to these objects such as color and dullness. Graphic image files can be mapped onto the objects to form the visual appearance of textures. Further, various MIME types can be associated with the objects, such as inline graphics and sound files.
With VRML 1.0, interaction with objects was quite limited. First, the objects themselves were static, such that the user was presented with only a two dimensional image of a three dimensional scene. The type of interaction the user will have with the image is simply one of "point and click". For example, a user can click on the visual representation of an object causing either a new image to be presented, initiating a link to a new virtual environment, or linking to an HTML document.. The VRML 2.0 specification includes behaviors for the 3D objects. This is a large step towards the creation of true virtual environments, but is still short of the description of a complete, living and immersive virtual world. Clearly, the description of the user's representation is an important first step in moving toward enabling complete virtual worlds.
VRML is the standard format for representing 3D graphics on the Internet, however it is not the only possible avatar format. Avatars are meaningful as 2D sprites, flat 2D objects, and proprietary 3D formats. This document presents a VRML 2.0 bias - avatars are required to present a VRML 2.0 representation of some form - however, other encodings can be added.
One of the first steps toward the creation of true multiuser virtual environments will be the formal description of the user's representation. This proposed Universal Avatar Specification is related to both HTML and VRML by its sharing of HTTP, URL's, and geometrical constructions delivered via VRML. It's primary purpose is to create a universal descriptor for intelligent avatars. By creating such a language, several benefits ensue -
We will now proceed to a brief discussion of how Universal Avatars might be implemented, presenting only the most basic elements of this specification.
The following section contains an example of the source code for creating a universal avatar. The idea is to create a container for the avatar description file with VRML, using special tags linking to more complex objects that will be ignored by standard browsers. Thus, the file would be parseable by any standard VRML parser. However, vital files are linked to this page, and stored in other file formats for use by the virtual world operators. At some date in the future, when the COM/CORBA war is either won or settled, avatars will become containers for lightweight, distributed components.
This Universal Avatars file would be divided into five logical sections.
The first portion would link to another file containing the user's profile information. This file would be coded in HTML and would contain any information the user wishes to share with the world about his identity. This file could contain either a real or imaginary identity. It's completely up to the user. The user's true identity would not be required, and this user could enter any world not requiring positive identification. This user profile would use standard HTML assets extensively, such as text, JPEGs, tables, and so forth. The only requirements for this file are the inclusion of a header identifying it as a universal avatar profile, and a optional anonymous mailto: tag that would link the user to the avatar vendor for remailing. If the file belonged to a minor, the user's parent could then instruct the remailer to refuse any unsolicited emails.
The second portion would contain basic information for the rendered avatar model, including 3D Model, Animation and Behaviors. We would like to allow users to maintain an identity that is as consistent as possible across several different platforms. Existing avatar representation technologies range from 2D sprites (The Palace) to 3D sprites (Id's Doom, Paragraph) to 3D non-hierarchical models (being developed by various VRML world companies, such as Worlds) to 3D hierarchical models. Each of these systems has its strengths and weaknesses. This plethora of options gives us a problem. Do we choose the "right" representation, or do we try to accommodate all of them? Where possible we have as a design goal the accommodation of all the different representations.
Each avatar will specify a major type and a minor type. An example of major type would be VRML1 or VRML2. An example of a minor type would be Live3D if one wanted to use proprietary extensions understood by that browser or generic to not use those extensions. The browser or world would have to know enough about its environment to determine which browser it was running, and choose the appropriate model based on that. However, it should be clearly noted that the preferred default format will always be a completely VRML 2.0 compliant model, that does not use any proprietary extensions. This methodology will then allow for proprietary extensions that could otherwise slowly rip apart the underlying standard, as various vendors have done to HTML this last year.
Additionally, certain metrics could be determined. For example, the height of a universal avatar could be measured in terms of a common metric, to represent the normalized default average height avatars are supposed to have in any specific world. Normal human height could be 1.0, and you could by 0.5 if you're a dog or 1.3 if you're Magic Johnson. Then the world server can send out info about how the avatar should be scaled for that world. The simplest way to deal with complexity is to include a tag that describes the complexity of each avatar and leave it to browsers or world owners to do with that information what they will.
The next design goal deals with behaviors. A simple classification system for behaviors is to separate behaviors that effect the world and possibly require a reaction from another avatar (which we will refer to as transitive behaviors) from those that effect solely one's own avatar (which we will refer to as intransitive behaviors). From an implementation standpoint, modifying solely one's own representation is more separable from the underlying server than behaviors that modify the world. We have chosen to delay including a methodology for handling transitive behaviors until we release our second working draft.
For behaviors dealing only with one's representation of self, we propose the following system:
The third portion would contain methods for establishing and using trust. This could begin by containing a public key, a Certificate or a Virtual PIN. This issue will be addressed in the second draft.
The fourth portion would contain information enabling inter-world communications. The idea is that it would be good to be able to connect to other users who may be connected in other worlds, possibly operated by disparate virtual world operators. However, if these two virtual world operators have implemented an Internet telephony system that is compliant with the ITU H.323 standard, the users would be able to connect to one another and hold a voice chat session. This approach would be vendor specific as well. If both virtual world operators used something like Voxware's Telephony Network Toolkit or OnLive, the users would connect using the Voxware or OnLive codec. If the operators have disparate voice codecs, the two systems could intelligently switch to H.323, and thus a Voxware user could speak to an OnLive user from within their worlds. Furthermore, we must deal with issues like an avatar global directory service system, so that users could seek and connect with one another more easily, and possibly do-not-disturb or other call management features. This will be more formally addressed in the second draft.
The fifth portion would contain vendor specific extensions and user history. For example, computer games producers could save information here that would be valuable to other game producers servicing the user. For example, a user with a high experience level, e.g., wizard status, in one virtual world would be transparently presented to another related world operator as someone with expert status or as a member of a certain guild, so that the user could avoid introductory sequences and be routed to more meaningful play areas. Finally, this section could contain secured marketing information as well, which would enable new ways to produce revenues more efficiently in virtual space.
Sample code follows:
#VRML Draft #2 V2.0 utf8
WorldInfo {
info [ "Sample source for Universal Avatar Definition file" ]
title "Avatar Sample"
}
# --- Begin sample source for Universal Avatar Definition File ---
# --- I. User Personal Profile ---
# All PROTOs in this sample file could be implemented as
# EXTERNPROTO instead.
PROTO AvatarPersonalProfile [
exposedField SFString userPage ""
exposedField SFString userData "" ]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
DEF MyPersonalProfile AvatarPersonalProfile
{
userPage "http://www.vwvendor.net/user3211/profile.html"
}
# --- II. Avatar Modeling and Behavior Information ---
PROTO AvatarTypes [ exposedField MFNode types [ ] ]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
PROTO AvatarOneType [
exposedField SFString type ""
exposedField SFString url ""
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
# --- Note: If the browser in use doesn't find a match in the list ---
# --- of AvatarTypes, it should choose a default ---
# --- Scale and complexity tags should go with each AvatarType---
DEF MyTypes AvatarTypes {
types [
AvatarOneType {
type "browser/generic"
url "http://www.avatar.com/avatars/alice/generic/avatar.gav"
}
AvatarOneType {
type "browser/netscape.com/vrml2"
url "http://www.avatar.com/avatars/alice/vrml2/live3d/alice.wrl"
}
AvatarOneType {
type "browser/paragraph.com/vrml2"
url "http://www.avatar.com/avatars/alice/vrml2/paragraph/alice.wrl"
}
AvatarOneType {
type "browser/sony.co.jp/vrml2"
url "http://www.avatar.com/avatars/alice/vrml2/sony/alice.wrl"
}
AvatarOneType {
type "browser/worlds.net/vrml2"
url "http://www.avatar.com/avatars/alice/vrml2/worlds/alice.wrl"
}
AvatarOneType {
type "browser/chaco.com/vrml2/pueblo2.02"
url "http://www.avatar.com/avatars/alice/vrml2/chaco/alice.wrl"
}
]
}
PROTO AvatarAnimations [ exposedField MFNode types [ ] ]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
PROTO AvatarOneAnimation [
exposedField SFString type ""
exposedField SFString url ""
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
DEF MyTypes AvatarAnimations {
types [
AvatarOneAnimationIndex {
type "animation/walk"
url "http://www.vwvendor.net/user3211/index.beh"
}
AvatarOneAnimation {
type "animation/walk"
url "http://www.vwvendor.net/user3211/walk.csc"
}
AvatarOneAnimation {
type "animation/turn/left"
url "http://www.vwvendor.net/user3211/turnleft.csc"
}
AvatarOneAnimation {
type "animation/turn/right"
url "http://www.vwvendor.net/user3211/turnright.csc"
}
AvatarOneAnimation {
type "animation/jump"
url "http://www.vwvendor.net/user3211/jump.csc"
}
]
}
# --- Behaviors to be addressed in Draft #2---
# --- III. The following are encrypted, encapsulated trust and commerce
systems ---
PROTO AvatarTrust [ exposedField MFNode certificates [ ]
exposedField SFString parentalControl "no"
exposedField SFString access "full"
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
PROTO AvatarOneCertificate [
exposedField SFString type ""
exposedField SFString url ""
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
DEF MyTrust AvatarTrust {
access "full"
certificates [
AvatarOneCertificate {
type "certificate/pgp.com/"
url "http://www.vwvendor.com/user3211/pgp/mycert.crt"
}
AvatarOneCertificate {
type "certificate/firstvirtual.com/"
url "http://www.vwvendor.com/user3211/fv/pin.enc"
}
]
}
# --- IV. The following are embedded interworld communications systems ---
PROTO AvatarCommunication [ exposedField MFNode communications [ ] ]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
PROTO AvatarOneCommunication [
exposedField SFString type ""
exposedField SFString url ""
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
AvatarCommunication {
communications [
AvatarOneCommunication {
type "communications/voxware.com/vapi"
url "http://vapi.vwvendor.com/vapiserver"
}
AvatarOneCommunication {
type "communications/itu.ch/h.323"
url "http://itu.vwvendor.com/itu.h.323"
}
]
}
# --- Lipsynching and emotional defaults to be handled later?---
# --- V. The following are embedded marketing profiling systems ---
# --- and vendor specific extensions ---
PROTO AvatarContact [
exposedField SFString address ""
exposedField SFString id ""
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
AvatarContact {
address "anon_mailto:client3211@vwvendor.com"
id "3456545600003211"
}
PROTO AvatarMarketProfile [
exposedField SFString agent ""
exposedField SFString representative ""
exposedField SFString access ""
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
AvatarMarketProfile {
agent "http://www.vwvendor.com/user3211/myagent.exe"
representative "http://market.vwvendor.com/marketserver"
access "compensated"
}
# --- End sample source ---
To review, part one would contain a general profile providing information about the user. This would not be required, but if contributed, it would provide a handle, location information, offered age/gender/marital status, etc. This would be equivalent to a home page.
We will probably need some way to deal with the aspects of avatar complexity. Possibly, a COMPUTER statement could be used by the world vendor to determine geometry processing limits for rendering. Like driving my car during rush hour, I get all the benefit of having a big, fancy avatar, but everyone else who sees me pays the cost in rendering time. It would probably make sense to include some mechanism by which world builders or owners could either restrict the complexity of a users avatar or perhaps even charge the user (to benefit the common good) for different levels of complexity.
Part two would contain both basic and advanced information for the rendered persona, including Model, Animation and Actions. Again, this would not be required, and if not provided, the vendor would use standard default representations. It would also contain the description of advanced objects and behaviors through LinkedAgents and virtual pets.
Part three contains information regarding trust and transactions. These would be encrypted, password protected Certificates, Virtual PINs, etc.
Part four contains information regarding inter-world communications.
Part five contains additional miscellaneous information, including game player profiles, vendor specific information, and secured marketing information.
Using these capabilities, the user would be able to enter any Universal Avatar compliant virtual world, and have all these useful presentations available without needing to re-create or re-key any of these media types.
Finally all modifications and extension should not interfere with the standard interpretation of VRML 2.0 files, they should merely complement. All extensions developed should be presented to the VRML specification community for commentary and adoption into future VRML specifications.
To conclude, it is of utmost importance that the virtual world community start to present avatar description concerns to the VRML community. This document attempts to deal with a number of standardization issues. Your comments will help to refine this document into a more robust, effective system for standardizing avatars, which will benefit both the virtual world development community, as well as the eventual consumer.
Those wishing to follow or participate in the development of the spec should subscribe to the Universal Avatars mailing list, by sending an email requesting subscription containing your email address to "uniavatar-request@chaco.com".