VRML 2.0
Request for Proposals
January 4, 1996
The Virtual Reality Modeling Language (VRML) is a language for
describing virtual worlds networked via the global Internet and
hyperlinked through World Wide Web.
The first revision of VRML, based upon Silicon Graphics' Open
Inventor, served as a common scene-description language which
has now been accepted as the standard for 3D communication on
the Internet.
VRML must grow again, to enable a new generation of scaleable,
interactive, high-performance applications. As part of this growth
process, the VRML Architecture Group
and the membership of the www-vrml mailing list are now issuing
a call for proposals which will be considered as candidates for
the next major revision of VRML.
Process:
The history of VRML is that of a community coming together to
act in concert to solve a series of large problems. The specification
process which brought us through to VRML 1.0 was composed of :
- a requirements phase,
- a request for proposals,
- an open debate on these proposals,
- generation of consensus around a proposal,
- changes to that proposal to make it perfectly acceptable.
Starting in 1994 we were able to complete this process in a short
amount of time. It is now time to pick up the pace and light a
fire under the same process for VRML 2.0. The VAG and VRML community
have been discussing various aspects and requirements of VRML
2.0. This means that we have already moved into the request for
proposals phase. This document is a formalization that will serve
as a guideline for individuals who wish to make a proposal.
We expect there to be several serious VRML 2.0 candidates; the
VAG believes that it's far better for proposals to find a "middle
way", rather than to engage in endless wars.
Requirements:
- Performance - Speed is a key to a good interactive
experience, so any proposed VRML syntax and technology must be
able to be optimized. In particular, this means allowing for consistent,
fast frame rates at the best possible image quality.
- Scalability - VRML must allow the creation
of very large virtual worlds. Any feature which limits scalability
is unacceptable. In addition, any VRML technology must be portable
to many different computer systems.
- Composability - Related to scalability, one
must be able to compose VRML worlds or objects to create larger
worlds. Authors should be able combine worlds that are created
by different people simply by making a 'meta-world' that refers
to the other objects and VRML systems previously created and published.
- Authoring - Sophisticated VRML authoring
tools must be able to be created, and it should be possible to
perform most of the tasks necessary to create an interesting,
interactive VRML world using a graphical user interface. VRML
will only be successful when artists, designers and other non-programmers
are able to create compelling and interactive VRML content.
- Power - Programmers must be able to seamlessly
extend VRML's functionality, by allowing them to create arbitrary
scripts, applets or VRML code that can then be easily re-used
by other non-programmers.
- Interoperability - VRML 2.0 must be able
to interoperate with and take advantage of other network, graphics
and language based standards. This could include but is not limited
to VRML 1.0, HTTP, Java, Safe TCL and JPEG.
- Multi-user potential - VRML will evolve into
a multi-user shared experience in the near future, allowing complete
collaboration and communication in interactive 3D spaces. Any
proposal must anticipate the needs of multi-user VRML in its design,
considering the possibility that VRML browsers might eventually
need to support synchronization of changes to the world, locking,
persistent distributed worlds, event rollback and dead reckoning.
- Open Standard - VRML must be based in standards
and technologies that are both open and available without any
licensing. While a proposal may interoperate with an owned technology
it must not be a requirement.
- Backward Compatibility - As much as is possible
(given the changes that will be required for interactivity) VRML
2.0 should be backward-compatible with VRML 1.0.
- Completeness - The proposal should stand
on its own, as a complete proposal, integrating each of the requirements.
Works-in-progress are strongly discouraged. Any independent developer
should be able to use the specification as the single source of
documentation when implementing VRML technology. Ambiguities in
concepts, syntax or wording definitions should be avoided.
How to Submit a Proposal:
There are several requirements that must be included in any VRML
2.0 proposal:
- Contact person - The author list plus the individual
responsible as the key contact.
- Affiliation - Company, university or organization
who claims ownership of the work.
- Address - Place of business for the affiliation listed
above.
- Phone - Telephone number of the key contact person
listed above.
- Email - Electronic mail address of the key contact
person listed above.
Additionally any VRML proposal should contain the following information:
- Reference Implementation - There should be
at least one reference implementation of the proposal.
- Examples - list any examples that exist which demonstrate
the use of the VRML technology in the proposal. This can be working
WWW sites, sample code, past demonstrations or upcoming events.
- Background - A brief statement of the history of the
technology. This will be a useful starting place for those who
wish to learn about previous projects and how the proposal was
derived. This should also include any published references.
- Legal Issues - Any VRML 2.0 proposal should clearly
state the legal status of the technology. If the proposed technology
is being given to the public domain, partially owned by a group
of companies, what ever the situation it must be disclosed. When
we accept a proposal it is very important to know who owns the
technology and how the community and market must respond.
Please send the complete proposal, in electronic form, to the
VRML Architecture Group, vrml20@vag.vrml.org
as well as to www-vrml@wired.com.
Printed proposals are discouraged, as it makes it difficult to
publish the information for examination by www-vrml.
All proposals must be submitted to vrml20@vag.vrml.org
by 5:00pm Pacific Time Zone on Friday February 2, 1996. Any proposal
received after this date will not be considered.
This email address is to be used only for proposal submissions.
Discussion or other inquires should be sent to www-vrml@wired.com.
All submissions will receive a confirmation email saying that
their proposal has been received. If you do not receive this
confirmation with 4 calendar days assume that your email was not
received and please resubmit.
VRML Architecture Group