Web3D Working GroupsWeb3D Working Groups

Jyun-Ming ChenFall 2001

ContentsContents• X3d• H-Anim• UMEL• GEOVRML• MPEG• RM3D

• Others• User Input• Vrml-Streaming• Intellectual Property Right• Source Code Management• Dis-java-vrml• Vrml-EAI

Significant Work on VRML 97Significant Work on VRML 97• Many active working groups defining new functionality

• GeoVRML, UMEL, H-Anim

• Strong Implementation and Testing Work• Community Source Program• Conformance Testing / Defect Logging

• Specification work with ISO• Submitting EAI to ISO (VRML97 pt2)• Actively working on Amendment 1 – MPEG4 + Maintenance

X3DX3D• The next generation Open Web3D standard

• X3D will replace VRML 97 when approved as at ISO

• Concerted action by key VRML browser companies • Blaxxun, Nexternet, OpenWorlds, ParallelGraphics

• State-of-the-art Extensible Architecture• Enables small core plus flexibility to meet diverse market needs

• Provides full compatibility with VRML 97• Protecting existing content

• A key influencer on other industry standards• MPEG-4, XML

X3D’s Extensible ArchitectureX3D’s Extensible Architecture• X3D Core provides capable small, compact browser

• Core has been proposed to MPEG-4 as their 3D profile

• Add “Components” to create market-targeted “Profiles”• Enables rapid innovation and differentiated vertical solutions

• VRML 97 is first profile• Preserves existing content

X3DCore

ExtensionFramework

VRML 97Profile

Preserves VRML97 content

Small download,Capable browser for many applications

Cooperative framework to implement and distribute future

components and profiles

X3D ExtensibilityX3D Extensibility• A flexible infrastructure

• Enabling technical AND commercial cooperation over components

• Follow the example of OpenGL• Consortium maintains an component registry by vendor

• Any vendor can define and ship a new component• Enables rapid innovation

• Encourage multi-vendor components• Through the working group process• Popular extensions can be considered for future spec revisions

• Already significant work on defining advanced components• Tentative agreement that the group will adopt blaxxun NURBs

• Will define broad X3D levels provide common functionality• Balancing flexibility with simplicity

The Future of Open Web3DThe Future of Open Web3D• A foundation stone in the infrastructure of the web• A lingua franca for 3D broadcast and web applications• Enabling for both VRML and proprietary-based companies

UMEL (Universal Media Element Library)UMEL (Universal Media Element Library)• Universal Media is to Web3D worlds what fonts are to plain text documents: Unive

rsal Media resides locally on end user systems, eliminating the need for media to be distributed along with the 3D world. As a result, authors can incorporate any number of textures, sounds and 3D objects into their worlds without increasing the time it takes the world to download -- only the world definition itself (.wrl files) is sent over the wire, while media is retrieved from the user's local hard drive.

• A library of commonly used textures, sounds and 3D objects is installed on end user systems, allowing authors to reference any number of these elements in their worlds without concern for file sizes and download restrictions.

• Since the Universal Media resides on the end user's hard drive, only the 3D world itself (and any custom media elements it requires) is downloaded over the network.

• Universal Media savvy tools and browsers realize that references to Universal Media elements are actually references to locally resident media, and so load the appropriate media elements from the user's local hard drive rather than attempting to download them over the network.

UMEL ScenesUMEL Scenes

[demo sites]

H-Anim (Humanoid Animation)H-Anim (Humanoid Animation)• As the 3D Internet continues to grow, there will be an increasing need to represen

t human beings in online virtual environments. Achieving that goal will require the creation of libraries of interchangeable humanoids, as well as authoring tools that make it easy to create new humanoids and animate them in various ways.

• This document specifies a standard way of representing humanoids in VRML97. This standard will allow humanoids created using authoring tools from one vendor to be animated using tools from another. H-Anim humanoids can be animated using keyframing, inverse kinematics, performance animation systems and other techniques.

• Our design goals are as follows: • Compatibility: Humanoids should work in any VRML97 compliant browser. • Flexibility: No assumptions are made about the types of applications that will use human

oids. • Simplicity: When in doubt, leave it out. The specification can always be extended later.

H-Anim: OverviewH-Anim: Overview• The human body consists of a number of segments (such as the

forearm, hand and foot) which are connected to each other by joints (such as the elbow, wrist and ankle).

• For an application to animate a humanoid, it needs to obtain access to the joints and alter the joint angles.

• The application may also need to retrieve information about such things as joint limits and segment masses.

• Each segment of the body will typically be defined by a mesh of polygons, and an application may need to alter the locations of the vertices in that mesh.

• The application may also need to obtain information about which vertices should be treated as a group for the purpose of deformation.

H-Anim: Hierachy H-Anim: Hierachy • An H-Anim file contains a set of Joint nodes that are arranged to form a hierarchy.

Each Joint node can contain other Joint nodes, and may also contain a Segment node which describes the body part associated with that joint. Each Segment can also have a number of Site nodes, which define locations relative to the segment. Sites can be used for attaching clothing and jewelry, and can be used as end-effectors for inverse kinematics applications. They can also be used to define eyepoints and viewpoint locations.

• Each Segment node can have a number of Displacer nodes, that specify which vertices within the segment corresponds to a particular feature or configuration of vertices.

• The file also contains a single Humanoid node which stores human-readable data about the humanoid such as author and copyright information. That node also stores references to all the Joint, Segment and Site nodes, and serves as a "wrapper" for the humanoid. In addition, it provides a top-level Transform for positioning the humanoid in its environment.

Ex: The Joint HierarchyEx: The Joint Hierarchy

H-Anim 1.1 ModelH-Anim 1.1 Model

[link]

GeoVRMLGeoVRML• Working Group of the Web3D Consortium,formed on 27 Feb 1998 wit

h the goal of developing tools and recommended practice for the representation of geographical data using VRML

• The desire is to enable geo-referenced data, such as maps and 3-D terrain models, to be viewed over the web by a user with a standard VRML plugin for their web browser.

• The following list provides a high-level list of capabilities that are specifically addressed by GeoVRML 1.0. • Coordinate Systems• Precision - VRML97 provides only single-precision floating point values. This i

s insufficient to represent data on a planetary scale• Navigation - GeoVRML 1.0 provides some basic support for navigation scheme

s that are specific to geographic applications. Specifically, the issue of elevation scaled velocity is addressed.

GeoVRML Concepts:GeoVRML Concepts: • Geographic Coordinate Systems

• VRML world uses a simple Cartesian local coordinate system (LCS) with an origin at (0,0,0) and +Y representing the up direction. However, most georeferenced data are provided in a geodetic or projective coordinate system.

• A geodetic (or geographic) coordinate system is related to the ellipsoid used to model the earth, for example the latitude/longitude system. A projective coordinate system employs a projection of the ellipsoid onto some simple surface such as a cone or a cylinder, for example, the Lambert Conformal Conic (LCC) or the Universal Transverse Mercator (UTM) projections.

• In order to be useful to the geographic community, there must be some standard means of relating VRML's Cartesian coordinate system to any one of the standard geographic coordinate systems, i.e. a means for georeferencing VRML worlds.

Geographic Coordinate Systems (cont)Geographic Coordinate Systems (cont)• We have adopted the SEDRIS Spatial (or Geospatial) Reference Model (SRM). It is

a reference model and software package that currently supports 12 different coordinate systems and tools to convert reference marks automatically and losslessly between them. The coordinate systems supported include Geodetic (GDC or latitude/longitude), Geocentric (earth centered Cartesian), UTM, and LCC, among others. It also includes a large geoid and datum library for accurate localization using geodetic coordinates.

• In order to use these facilities within new VRML nodes, SRI International embarked upon a process to convert part of the SEDRIS Conversions API to Java. The result is the freely-available, open source Java package called GeoTransform. The GeoVRML 1.0 sample implementation is built on top of the GeoTransform package. It therefore supports conversions between geodetic, geocentric, and UTM coordinate systems, and also includes all of the SEDRIS ellipsoid definitions.

Multi-resolution Terrain RepresentationMulti-resolution Terrain Representation• Terrain models are typically massive in size. For example, the U.S. Geological Sur

vey (USGS) produce Digital Elevation Models (DEMs) that contain over one million points.

• The time to download and render terrain models of this complexity would prohibit any form of real-time interaction using the current generation of VRML browsers. It therefore becomes essential to implement some form of level of detail (LOD) management.

• LOD is the technique of changing a model's complexity based upon some selection criteria, such as distance from the viewpoint or projected screen size. In order to implement this, we need a mechanism to simplify the geometry and imagery for a dataset.

• Several polygon simplification algorithms exist that work well for terrain. However, many of these are view independent techniques that force the same degree of simplification across the entire terrain. These tend to be inappropriate for web-based applications because switching to the highest resolution would still involve loading every point of the original dataset.

Multi-Resolution Terrain (cont)Multi-Resolution Terrain (cont)• Similarly, there are various dynamic LOD techniques that can simplify a large heig

ht field grid in real-time taking the user's viewpoint into consideration. However, once again, these require the high-resolution dataset to be resident in memory first.

• For large distributed terrain datasets, a tiled pyramid approach is a common solution. This involves taking a high-resolution dataset and progressively downsampling it to produce a multi-resolution pyramid. Each level of this pyramid is then segmented into a grid of equally-sized rectangular tiles (for example 128 x 128 pixels). A tile at one level of the pyramid will therefore map onto four tiles on the immediately higher-resolution level, i.e. the tiles at the higher-resolution level cover a quarter of the geographical area of the former.

• Using such a representation, we can progressively display higher resolution data around some area of interest (e.g. the user's viewpoint) while other regions remain in low resolution. The use of tiling also allows us to only fetch and display sections of the dataset that are visible from a certain vantage point.

Limitations Of Single-PrecisionLimitations Of Single-Precision• VRML was designed primarily by the computer graphics community, and as such

it has some limitations which seem to be natural design constraints from the graphics perspective. The most obvious of these from a geosciences perspective is the reliance on single-precision (32-bit) values. Since computer graphics typically deals with small screens, there is no need to use double-precision since any increases in accuracy that it brings would be lost in sub-pixel noise.

• However, single-precision is insufficient to model data over the range of the earth at accurate ground resolutions. With only 23 bits of mantissa we can be accurate to only about 6 digits of precision. Since the equatorial diameter of the earth is 12,756,274 m, this leaves us unable to achieve resolutions better than 10s of meters using single-precision floating point numbers. Below this threshold, we will experience various floating point rounding artifacts such as vertices coalescing and camera jitter.

• With the widespread distribution of GPS transceivers, and the increased public availability of differential references, virtually anyone can now obtain accurate absolute locations with 1 meter resolution. There is no reason to suppose that professional cartographers should settle for less. We therefore desire to represent floating point values to precisions beyond that of single-precision.

Single-Precision Limitations (cont)Single-Precision Limitations (cont)• We treat this georeferencing problem as one of establishing a georeferenced local

Cartesian frame, or LCS. We define an absolute georeferenced location as the origin of the LCS. This becomes the reference point that correlates to the VRML world's (0,0,0) origin. Any subsequent geographic locations are translated into VRML's Cartesian coordinate system relative to this LCS origin. Moreover by allowing the user to define these local frames easily, we allow the creator of the georeferenced data to manage the accuracy of a 32-bit floating point representation by creating VRML worlds of only limited local extent.

• To illustrate this concept, imagine an example where we specify the LCS origin to be (310385.0 e, 4361550.0 n, 0 m, zone 13) in UTM coordinates. This will be transformed to a double-precision geocentric coordinate of (-1459877.12, -4715646.92, 4025213.19). If we then supply an absolute UTM coordinate of (310400.0 e, 4361600.0 n, 0 m, zone 13), then this will be transformed internally to a geocentric coordinate of (-1459854.51, -4715620.48, 4025252.11). Finally, we transform this absolute geocentric coordinate to a single-precision local Cartesian coordinate system by subtracting the LCS origin location to give (22.61, 26.44, 38.92), which is within single-precision range.

Navigation IssuesNavigation Issues• There are a number of navigation issues specific to the browsing of

large geographic areas. The two issues mentioned here are elevation scaled velocity and terrain following.

• The velocity at which users can navigate around a world should depend upon their height above the terrain. For example, when flying over the coast at a height of 100 m above the terrain, a velocity of 100 m/s could be considered relatively fast. However, when approaching the earth from outer space, a velocity of 100 m/s would be intolerably slow. Creators of geographic visualization systems have therefore learned to scale the velocity of the user's navigation in an attempt to maintain a constant pixel flow across the screen. A simple linear relationship between velocity and the user's elevation above an ellipsoid often provides an acceptable and easily computable solution to this problem.

Navigation (cont)Navigation (cont)• The second issue is that of terrain following. The earth is not a flat s

urface. As we navigate over the earth's surface we should therefore expect to follow a curved flight path through 3-D space. However, default navigation methods in VRML, such as WALK and FLY, propel the user along a linear flight path that is parallel to the X-Z plane. A more correct approach in terms of planetary visualizations would be to maintain a particular height about the surface of the earth.

• Note that, while elevation scaled velocity is partly addressed by this GeoVRML recommended practice document, the issue of terrain following is not addressed.

VRTPVRTP• The capabilities of the VRML permit buildi

ng large-scale virtual environments using the Internet and the WWW. However the underlying network support provided by the hypertext transfer protocol (http) is insufficient for large-scale virtual environments. Additional capabilities for many-to-many peer-to-peer communications plus network monitoring need to be combined with the client-server capabilities of http. To accomplish this task, we present a detailed design rationale for the virtual reality transfer protocol (vrtp).

• vrtp is designed to support interlinked VRML worlds in the same manner as http was designed to support interlinked HTML pages.

• Installing vrtp will provide any machine with client, server, peer-to-peer and network monitoring capabilities. People will use vrtp with 3D browsers to navigate and join large, interactive, fully internetworked, VRML worlds.

• Because the scene graph paradigm is common across a number of Web-based 3D programming methodologies, vrtp interfaces will also be developed that are adaptable to other APIs such as Java3D and VRML-NG.

VRTP (cont)VRTP (cont)• Just as the functionality of ftp, telnet a

nd gopher were integrated in http to support HTML, we are integrating and optimizing protocols for client, server, peer-to-peer and network monitoring in vrtp to support VRML.

• Combining and optimizing existing protocols is a well-understood challenge. It is also becoming clear that such functionality can be used for other 3D scene-graph APIs in addition to VRML.

• For a long time, many of our conversations with people about VE networking ended up in the same frustrating question: "are you discussing client-server OR peer-to-peer? We now realize this is a false dichotomy. A full spectrum of functionality exists between client-server and peer-to-peer. vrtp must support this entire spectrum well.

VRTP (cont)VRTP (cont)• We have done a lot of work implementing large-scale virtual environments over

the network. Most people have huge laundry lists on what functionality is required for a scalable network architecture. The real challenge is squeezing down on all these issues and understanding the core requirements. The design rationale explains in detail why these key components are needed to support the full variety of network needs in virtual environments.

VRML-MPEG4VRML-MPEG4• MPEG-4 builds on the proven success of digital television,

interactive graphics applications, and interactive multimedia systems such as the WWW. MPEG-4 can be thought of as toolkit for developing networked multimedia applications based on any combination of audio, video, 2D, and 3D content.

• Specifically, the MPEG-4 standard was designed for delivering both static and interactive multimedia content to any platform over any network. Based in part on the VRML standard developed by the Web3D Consortium, MPEG-4 has been under development since 1993 and is today ready for prime time.

• The first generation of MPEG-4 content servers and authoring tools are now available or on the horizon. By the end of this year we can expect a variety of commercial MPEG-4 products to arrive for the broadcast and Internet markets.

MPEG4MPEG4• Advances in the MPEG-4 standard continues to be made, particularly in the area o

f 3D, offering Web3D Members a unique opportunity to generate new revenue streams by way of MPEG-4 and related MPEG activities standards.

• The Animation Framework eXtension (AFX), for example, is a joint Web3D-MPEG effort that will define 2D and 3D capabilities for the next version of the MPEG-4 standard.

• Similarly, the MPEG group has recently initiated an effort to develop standards for Multi-User capabilities in MPEG-4. The newly established AFX and Multi-User efforts present Web3D Members with two promising areas for contributing to future MPEG-4 standards.

• These and other MPEG standards are developed through a combination of face-to-face meetings and email exchange through group email lists.