`

`lightweight inline calculations, and Java for full-
`fledged programming and network access. If Java or
`JavaScript are supported in a VRML browser, they
`must conform to the formal interface specified in
`[12], Annexes B and C, respectively. Major browsers
`now support both. Ongoing development of VRML
`continues via open working groups supported by the
`nonprofit VRML Consortium
`(VRMLC)—see
`www.vrml.org.
`Behaviors. The term “behaviors” refers to making
`changes in the structure or appearance of a 3D scene.
`Thus a broad definition of a VRML behavior might be
`“any change in the nodes or fields of a VRML scene
`graph.” VRML 97 provides local key-frame animation
`mechanisms and remote scripting language hooks
`(such as an applications programming interface or
`API) to any scene graph component. Dynamic scene
`changes can be stimulated by scripted actions, mes-
`sage passing, user commands or behavior protocols,
`implemented using either via Java calls or complete
`VRML scene replacement. General approaches for
`VRML behaviors and scene animation are possible,
`
`sary before describing how Java works in combina-
`tion with it. This section describes the 3D-specific
`VRML nodes.
`Since VRML is a general 3D scene description lan-
`guage that can be used as an interchange file format,
`there are a large number of 3D graphics nodes available.
`These nodes are organized in a hierarchical structure
`called a scene graph (i.e., a directed acyclic graph). The
`primary interaction model for 3D VRML browsers is
`point and click, meaning that content can have the
`same embedded links as the 2D HTML. VRML 3D
`browsers are typically installed as plugins within 2D
`browsers (such as Netscape Navigator and Internet
`Explorer). VRML is optimized for general 3D render-
`ing and minimal network loading, taking advantage of
`extensive VRML browser capabilities. For examples,
`geometric primitives such as IndexedFaceSet allow
`authoring tools and datasets to create highly complex
`objects. Textures and MovieTextures can wrap 2D
`images over and around arbitrary geometry. Sound
`nodes embed spatialized audio together with the asso-
`ciated shapes. Lighting and camera control provide
`
`Using Java is the most powerful way for 3D scene authors
`to explore the many possibilities provided by VRML.
`
`providing simplicity, security, scalability, generality
`and open extensions. Using Java is the most powerful
`way for 3D scene authors to explore the many possi-
`bilities provided by VRML.
`Getting Started. Numerous useful resources for
`obtaining browser software, subscribing to the www-vrml
`mailing list, tutorials, and so forth, are available via the
`VRML Repository [11]. Excellent books for learning
`VRML include volumes by Andrea Ames [1] and Jed
`Hartman [6]. The VRML 97 specification is online, and
`an annotated version of the specification by principal
`VRML 97 architects Rikk Carey and Gavin Bell is avail-
`able in book form and online [2]. Resources on Java net-
`work programming include those by Elliott Rusty Harold
`[5] and Merlin Hughes [7]. Intermediate and advanced
`textbooks for combined VRML and Java programming
`have been written by Rodger Lea [8] and Bernie Roehl
`[10], respectively.
`
`3D Graphics Nodes
`Most programmers find that there are many unfa-
`miliar language concepts and terms in VRML. An
`overview of this admittedly large language is neces-
`
`complete control of presentation and rendering, includ-
`ing animation of camera position to create flyby explo-
`rations or dramatic visual transitions. Finally, the Script
`node interface to Java allows modification or generation
`of any VRML content.
`Shape. The Shape node is a container node that col-
`lects a pair of components called geometry and
`appearance. Nodes that describe the objects being
`drawn are typically used in the geometry and appear-
`ance fields of the Shape node.
`Geometry. Box, Cone, Cylinder and Sphere are
`nodes for simple regular polyhedra (sometimes called
`primitives) that provide basic building blocks for easy
`object construction. The Text node simplifies specifica-
`tion of planar or extruded polygonal text. Elevation-
`Grid is a table of height (y) values corresponding to x–z
`horizontal spacing indices. The Extrusion node
`stretches, rotates and scales a cross-section along a spine
`into a wide variety of possible shapes. IndexedFaceSet,
`IndexedLineSet and PointSet can create 3D geometry of
`arbitrary complexity. Since Extrusion, IndexedFaceSet,
`IndexedLineSet and PointSet are specified by sets of
`coordinate points, color values and normal vectors can
`
`
`
`ol. 41, No. 6 COMMUNICATIONS OF THE ACM
`
`Fitbit, Inc. v. Philips North America LLC
`IPR2020-00828
`
`Fitbit, Inc. Ex. 1027 Page 0002
`
`

`

`be specified point by point for these nodes.
`Appearance. The appearance of geometry is primarily
`controlled by specifying color values or texture images.
`The Material node permits specification of diffuse, emis-
`sive and specular color components (which roughly corre-
`spond to reflective, glowing, and shiny colors). Material
`nodes can also specify transparency. Colors are specified as
`red-green-blue (RGB) triples ranging from 0 (black) to 1
`(full intensity). Transparency values similarly range from
`0 (opaque) to 1 (completely transparent). As an alterna-
`tive or supplement to material values, three types of tex-
`ture nodes are provided. ImageTexture is the most
`common: a 2D image is wrapped around (or over) the
`corresponding geometry. MovieTexture allows use of
`time-dependent textures (for example, MPEG movie
`files) as the image source. Finally TextureTransform spec-
`ifies a 2D transformation in texture coordinates for
`advanced texture-mapping techniques such as applying
`specific repetitions or orientations of a texture to corre-
`sponding geometry features.
`
`Scene Topology: Grouping and
`Child Nodes
`VRML syntax and node typing also help enforce a
`strict hierarchical structure of parent-child relation-
`ships so that browsers can perform efficient render-
`ing and computational optimizations. Grouping
`nodes are used to describe relationships between
`Shapes and other child nodes. Moreover, the seman-
`tics of a scene graph carefully constrain the ways in
`which nodes can be grouped together. Child nodes
`come under grouping nodes to comply with the
`scene graph hierarchy inherent in any author’s
`VRML scene. In addition to Shapes, child nodes
`describe lighting, sound, viewing, action sensors and
`animation interpolators. This section summarizes
`the full scope of VRML, the language; readers famil-
`iar with 3D graphics concepts may prefer skipping
`ahead to the Java section.
`Grouping. Fundamental to any VRML scene is the
`notion that graphics nodes can only be grouped in
`ways that make sense. Grouping is used to describe
`spatial and logical relationships between nodes, and as
`an intentional side result, also enable efficient render-
`ing by 3D browsers. The Group node is the simplest
`of the grouping nodes: it merely collects children,
`with no implied ordering or relationship other than
`equivalent status in the scene graph. The Transform
`node similarly groups children, but first applies rota-
`tion, scaling, and translation to place children in the
`proper coordinating frame of reference. The Billboard
`node keeps its children aligned to always face the
`viewing camera, either directly or about an arbitrary
`rotation axis. The Collision node lets an author spec-
`
`ify a bounding box that serves as a proxy to simplify
`collision detection calculations for grouped children.
`The Switch node renders only one (or none) of its chil-
`dren, and is useful for collecting alternate renderings
`of an object that might be triggered by external
`behaviors. The level-of-detail (LOD) node also renders
`only one of multiple children, but child selection is
`triggered automatically based either on viewer-to-
`object distance or on frame rate. Thus LOD enables
`the browser to efficiently select high-resolution or
`low-detail alternative renderings on the fly in order to
`support interactive rendering.
`Grouping and the Web. Since the Web capabilities
`of VRML are analogous to HTML, two types of
`grouping nodes enable Web connectivity in 3D
`scenes. The Inline node imports additional 3D data
`from another VRML world into the current VRML
`world. In contrast, the Anchor node creates a link
`between its children and an associated Uniform
`Resource Locator (URL) Web address. When the user
`clicks the child geometry of an Anchor node, the cur-
`rent VRML scene is entirely replaced by the VRML
`scene specified in the Anchor URL. Multiple strings
`can be used to specify any URL, permitting browsers
`to preferentially load local copies before searching for
`remote scenes or backup locations. Typically browsers
`highlight “hot links” in a 3D scene by modifying the
`mouse cursor when it is placed over Anchor-enabled
`shapes.
`Lighting and Sound. Virtual lights in a 3D scene
`are used to determine illumination values when ren-
`dering. Lights cannot be “seen” directly, rather they
`are used to calculate visibility, shininess and reflec-
`tion in accordance with a carefully specified mathe-
`matical lighting model. The DirectionalLight node
`illuminates using parallel rays, the PointLight node
`models rays radiating omni-directionally from a
`point, and the SpotLight node similarly provides
`radial rays constrained within a conical angle. Lights
`include color and intensity values that are multiplied
`against material values to calculate and produce
`proper shading. The Sound node places an audio clip
`at a certain location, and with nonrendered ellipsoids
`surrounding it, determines minimum and maximum
`threshold distances. Sound can repeat, be rendered
`spatially relative to user location, and be triggered
`on/off by events. Embedding various lights and
`sounds at different locations within a scene can pro-
`duce dramatic results.
`Viewing. Most 3D nodes describe location, size,
`shape and appearance of a model. The Viewpoint node
`specifies position, orientation and field of view for the
`virtual camera that is used to view (i.e., calculate) the
`3D scene and render the screen image. Most objects
`
`COMMUNICATIONS OF THE ACM June 1998/Vol. 41, No. 6
`
`59
`
`Fitbit, Inc. v. Philips North America LLC
`IPR2020-00828
`
`Fitbit, Inc. Ex. 1027 Page 0003
`
`

`

`Figure 1b. VRML scene
`hello_world
`
`#VRML V2.0 utf8
`Group {
`children {
`
`description "initial view"
`position
`6 -1 0
`orientation 0 1 0 1.57
`
`Viewpoint {
`
`}S
`
`hape {
`
`{ radius 1 }
`Sphere
`geometry
`{
`Appearance
`appearance
`{
`texture ImageTexture
`url "earth-topo.png"
`
`}
`Transform {
`
`} }
`
`translation
`rotation
`children {
`
`0 -2 1.25
`0 1 0 1.57
`
`geometry
`string {"Hello" "world!"}
`
`Shape {
`Text {
`
`}
`
`} } }
`
`appearance Appearance {
`Material Material {
`diffuseColor 0.1 0.5 }
`
`}
`
`}
`
`}
`
`}
`
`Figure 1a. VRML source hello_world.wrl
`
`and scenes contain a number of named viewpoints to
`encourage easy user navigation. The NavigationInfo
`node extends the camera concept to include the notion
`of an Avatar bounding box, used to determine camera-
`to-object collision and height of eye when “gravity”
`(terrain following) is enabled. NavigationInfo also
`toggles a “headlight” in the field of view for default
`illumination, and can switch the browser among a
`variety of user-navigation metaphors (FLY, EXAM-
`INE, WALK, and so forth). The Fog node specifies
`color and intensity of obscuring fog, which is calcu-
`lated relative to distance from viewer. The Back-
`ground node allows specifying sky and ground color
`profiles, ranging smoothly from zenith to horizon to
`nadir. Background also permits specifying six images
`for texture box, which always sits beyond other ren-
`dered objects. These various viewing nodes provide
`rich functionality for animating viewpoint, assisting
`user navigation, and providing environmental effects.
`Action Sensors. Sensors detect change in the scene
`due to passage of time (TimeSensor), user intervention
`or other activity such as viewer proximity (Visibility-
`Sensor). Sensors produce time-stamped events whose
`values can be routed as inputs to other nodes in the
`scene. User intervention is often as simple as direct
`mouse interaction with a shape via a TouchSensor, or
`interaction with a constraining bounding geometry
`
`specified by PlaneSensor, ProximitySensor, or Sphere-
`Sensor. Consistently typed input and output events
`are connected to correspondingly typed fields in the
`scene graph via ROUTEs.
`Animation Interpolators. Key-frame animation
`typically consists of simple time-varying values
`applied to the fields of the appropriate node. Smooth
`in-between animation can be interpolated linearly as
`long as key values are at sufficient resolution. Linear
`interpolators are provided for Color, Coordinate, Nor-
`mal, Orientation, Position, and Scalar fields. Linear
`interpolation is sufficient for many demanding appli-
`cations, including most humanoid animation. As
`with Sensors, Interpolator inputs and outputs are con-
`nected with other nodes via ROUTEs. For perfor-
`mance reasons, use of these standard VRML sensors
`and interpolators is usually preferable to writing a
`custom script since they can efficiently perform most
`authors’ intended tasks. Scripts are the mechanism
`whereby authors can extend the action and animation
`capabilities of VRML.
`Prototypes. Prototypes (PROTO and EXTERN-
`PROTO) allow creation of new VRML node types by
`authoring combinations of nodes and fields from
`other preexisting node types. In this sense, a PROTO
`definition is somewhat analogous to a macro defini-
`tion. In order to avoid completely copying a PROTO
`
`
`
`ol. 41, No. 6 COMMUNICATIONS OF THE ACM
`
`Fitbit, Inc. v. Philips North America LLC
`IPR2020-00828
`
`Fitbit, Inc. Ex. 1027 Page 0004
`
`

`

`for each file in which it is used, the EXTERNPROTO
`definition specifies remote URLs where the original
`PROTO is defined, along with the interface to permit
`local type-checking by browsers during scene loading.
`The EXTERNPROTO mechanism thus allows con-
`struction of PROTO libraries for easy access and reuse.
`Graphics Example. No doubt dedicated readers
`are fully convinced by this point that VRML contains
`a great deal of functionality. To illustrate clarity, a
`canonical “Hello world” example in Figures 1a and 1b
`display basic VRML syntax. This scene is available at
`www.stl.nps.navy.mil/~brutzman/vrml/examples/
`course/hello_world.wrl.
`
`parameter semantics. Private fields are simply desig-
`nated as field rather than exposedField.
`DEF/USE Naming Conventions. Node naming
`and lightweight multiple instancing of nodes is possi-
`ble through the DEF (define) and USE mechanisms.
`DEF is used to associate names with nodes. USE per-
`mits duplicate instances of nodes to be efficiently ref-
`erenced without
`complete
`reinstantiation,
`significantly boosting performance. Node names cre-
`ated via DEF are also used for routing events to and
`from fields. Thus Script nodes (and other 3D nodes
`which interact with the script) all must be named
`using DEF. The scope of all DEFed names is kept local
`to the file (or PROTO) where the name is defined.
`ROUTEs. ROUTE statements define connections
`between named nodes and fields, allowing events to
`pass from source to target. ROUTE statements usually
`appear at the end of a file since all nodes must be
`DEFed (named) prior to referencing. Typically
`ROUTEs are used for all events passed into (or out of)
`Script nodes. Use of ROUTEs is not always required,
`however, since nodes in the VRML scene can be passed
`
`}
`
`VRML and Java: Scripts, Events, Naming
`and ROUTEs
`Interfaces between VRML and Java are effected
`through Script nodes, an event engine, DEF/USE
`naming conventions, and ROUTEs connecting vari-
`ous nodes and fields in the VRML scene. VRML pro-
`vides the 3D scene graph, Script nodes encapsulate
`Java functionality, and ROUTEs pro-
`vide the wiring that connects compu-
`tation to rendering.
`Scripts. Script nodes appear in the
`VRML file, encapsulating the Java
`code and providing naming conven-
`tions for interconnecting Java vari-
`ables with field values in the scene.
`(Similar scripting conventions are
`specified for JavaScript). Interfaced
`Java classes import the vrml.* class
`libraries in order to provide type conversion (for both
`nodes and simple data types) between Java and
`VRML. Java classes used by Script nodes must extend
`the vrml.node.Script class in order to interface prop-
`erly with the VRML browser. The basic interface and
`a good description of Script nodes is excerpted from
`the specification [12] in Figure 2. Script nodes typi-
`cally (1) signify a change or user action; (2) receive
`events from other nodes; (3) contain a program mod-
`ule that performs some computation; and (4) effect
`change somewhere else in the scene by sending events.
`Events. Events allow VRML scenes to be dynamic.
`Events are merely time-stamped values passed to and
`from different parts of a VRML world. EventIns
`accept events, and EventOuts send events (when trig-
`gered by some predefined behavior). Events must
`strictly match the simple type (such as integer, float,
`color) or node type (such as a Material node) being
`passed from input to output. Script parameters are
`designated as EventIn, EventOut or ExposedField,
`which respectively correspond to in, out or in/out
`
`Script {
`exposedField MFString url []
`field SFBool directOutput FALSE
`field SFBool mustEvaluate FALSE
`# And any number of:
`eventIn eventType eventName
`field fieldType fieldName initialValue
`eventOut eventType eventName
`
`Figure 2. Script node specification
`
`by reference as fields to the encapsulated Script code.
`This alternative approach permits direct manipulation
`of VRML by Java without using events or ROUTEs.
`Example: Event-Based Control. A scene demon-
`strating VRML-Java connectivity using Scripts,
`events, node naming, and ROUTEs is examined in
`Figure 3. This VRML scene and corresponding Java
`source code are available at www.stl.nps.navy.mil/ ~brutz-
`man/vrml/examples/course/ScriptNodeEventOutControl.
`wrl and ScriptNodeEventOutControl.java.
`Example: Field-Based Control. An alternative to
`passing events via ROUTEs is to pass references to
`VRML nodes as values for fields in the Script node. In
`effect Java gains direct control of VRML nodes and
`fields, rather than sending or receiving event messages
`to set/get values. Upon initialization, the Java class
`instantiates the node reference as a local variable. Dur-
`ing subsequent invocations the Java class can read or
`modify any referenced field in the scene graph directly,
`
`COMMUNICATIONS OF THE ACM June 1998/Vol. 41, No. 6
`
`61
`
`Fitbit, Inc. v. Philips North America LLC
`IPR2020-00828
`
`Fitbit, Inc. Ex. 1027 Page 0005
`
`

`

`Figure 3. Script node interface between VRML and Java. This example tests event-based
`VRML-Java functionality. Note start Time, ChangedText, and ChangedPosition.
`
`without using ROUTEs. An example follows,
`demonstrating the exact same functionality as the pre-
`ceding example, but uses field-based control instead
`of events and ROUTEs. Figure 4 shows how nodes in
`the VRML scene are first defined, then passed as para-
`meters to the Java class. The field-based example is
`available
`via
`www.stl.nps.navy.mil/
`~brutzman/vrml/examples/course/ScriptNodeField-
`Control.wrl and ScriptNodeFieldControl.java.
`Script Interface Performance Hints. Two author-
`ing hints are provided as fields in the Script node for
`potential browser optimization: mustEvaluate and
`directOutput. In the first example (event-based con-
`trol), mustEvaluate is set to FALSE as an author hint,
`allowing the browser to postpone event passing until
`convenient, in order to optimize rendering. Similarly,
`the author hint directOutput is set to FALSE since the
`script only passes events and doesn’t modify VRML
`nodes directly. In the second example (field-based
`control), the opposite values are used. Since values
`in the scene graph might be modified by the script
`directly (for instance, without notifying the browser
`via ROUTE activity), the hint field mustEvaluate is
`set to TRUE and the browser can’t delay event pass-
`ing as a performance optimization. Similarly,
`directOutput is set to TRUE to indicate that the
`script can modify VRML nodes directly via field con-
`trol. If a scene uses both event and field control, the
`safest approach is to keep both values set to TRUE to
`maximize browser responsiveness to script actions.
`Browser Interface. Java via the Script node is pro-
`
`vided with a variety of methods to interact with the
`host Web browser. GetName and getVersion provide
`browser identification information. getWorldURL
`provides a string containing the original URL for the
`top-level VRML scene. The top-level page heading is
`reset by setDescription. GetCurrentSpeed and
`getCurrentFrameRate show user navigation and win-
`dow redraw speeds. An author’s Java program can also
`create and insert VRML source code (including nodes,
`PROTOs and additional ROUTEs) at run time. Java
`modifies VRML
`in
`the
`scene using
`the
`replaceWorld, createVrmlFromString, createVrml-
`FromURL, addRoute, deleteRoute, and loadURL
`methods. Valuable examples demonstrating these
`techniques appear throughout the public-domain
`JVerge class libraries, which provide a complete Java
`API mirroring all VRML nodes. JVerge accomplishes
`scene graph changes by sending modifications
`through the browser interface [3, 10].
`
`Future Language Interfaces
`Java via VRML’s Script node is well specified and
`multiple compliant browsers exist. Other interfaces
`are also on the horizon that can further extend Java-
`VRML functionality as described in the following.
`External Authoring Interface (EAI). Rather than
`providing Java connectivity from “inside” the VRML
`scene via the Script node, the EAI defines a Java or
`JavaScript interface for external applets that commu-
`nicate from an “external” HTML Web browser [9].
`EAI applets can pass messages to and from VRML
`
`
`
`ol. 41, No. 6 COMMUNICATIONS OF THE ACM
`
`Fitbit, Inc. v. Philips North America LLC
`IPR2020-00828
`
`Fitbit, Inc. Ex. 1027 Page 0006
`
`

`

`Figure 4. Field interface between VRML and Java. This example tests field-based VRML-Java functionality.
`Note shared start time, and shared fields ChangedText and ChangedPosition. Operation of this example is similar
`to Figure 3, except that class directly manipulates VRML nodes via fields instead of sending events.
`
`scenes embedded in an HTML page. Much of the
`browser interface is similar but somewhat different
`semantics and syntax are necessary for event passing
`and flow of control. The primary benefit of the EAI is
`the ability for direct communications between the
`encapsulating HTML browser and the embedded
`VRML browser. The EAI will likely be proposed as an
`official extension to VRML 97. A next-generation
`Java-VRML working group is examining additional
`capabilities and possibly unifying the EAI with the
`Script node classes, for consideration in future versions
`of VRML.
`Java3D. Sun has released the Java3D class library
`for 3D graphics programming [4]. Java3D is an API
`providing an interface for 3D that is analogous to the
`Abstract Window Toolkit (AWT) for 2D graphics.
`Java3D programs are saved as Java bytecodes, not as a
`modeling format. Although Java3D is expected to
`include a loader capable of importing and exporting
`VRML geometry, it is not yet clear whether the
`Java3D event model will be able to similarly import
`and export VRML events. Public availability of the
`Java3D classes adds a number of new tools for pro-
`grammers interested in VRML scene authoring. A
`VRML-Java3D working group is exploring usage con-
`ventions for interoperability, and also prototyping pos-
`sible specification changes. Further unification of these
`already-complementary approaches holds promise.
`
`Java-VRML Research
`Programming Java with VRML provides great
`expressive power. The combination of capabilities
`appears to sufficiently provide a general entity
`model. VRML provides 3D rendering and dynamic
`interaction capabilities, while Java provides general
`computation capabilities and network access. A vari-
`ety of sample projects follows.
`Multiuser Server Worlds. A number of research
`laboratories and commercial companies are producing
`networked games and shared worlds that utilize cen-
`tralized servers to share data among multiple partici-
`pants. This approach can reliably scale to several
`hundred participants. An extensive example that
`builds such a world appears in Roehl’s work [10].
`Networking. In order to support many simultane-
`ous users, peer-to-peer interactions are necessary in
`addition to client-server query-response. One exam-
`ple, the IEEE 1278.1 Distributed Interactive Simula-
`tion (DIS) protocols, is a well-specified way to pass
`entity behavior such as position, orientation, collision,
`fire/detonate and other message types. Use of multi-
`cast networking enables scalable many-to-many com-
`munications, avoiding server bottlenecks. DIS is
`particularly effective at communicating physics infor-
`mation at interactive rates in real time. The DIS-Java-
`VRML working group
`is
`implementing
`a
`public-domain DIS library in Java for use in mul-
`
`COMMUNICATIONS OF THE ACM June 1998/Vol. 41, No. 6
`
`63
`
`Fitbit, Inc. v. Philips North America LLC
`IPR2020-00828
`
`Fitbit, Inc. Ex. 1027 Page 0007
`
`

`

`via
`
`available
`
`tiple-entity VRML worlds,
`www.stl.nps.navy.mil/dis-java-vrml.
`Physics of Motion. Displaying realistic entity
`motion requires properly modeling the underlying
`physics that govern entity equations of motion.
`Much work has been done in the graphics and robot-
`ics communities to produce kinematic (velocities
`only) and dynamic (forces, accelerations) models for
`many different types of entities. Such models typi-
`cally range from three-to-six spatial degrees of free-
`dom (x, y, z, roll, pitch, and yaw). The NPS Phoenix
`autonomous underwater vehicle (AUV) hydrodynam-
`ics model provides perhaps a worst-case example how
`computationally demanding physical responses can
`be calculated in real time (10Hz or better on a Pen-
`tium processor). NPS AUV software is available at
`www.stl.nps.navy.mil/~auv. Eventually we expect
`that interface conventions will emerge and physics
`libraries for most entity types will be widely avail-
`able. A particularly appealing feature of such an
`approach is that computational load is distributed
`evenly, with each entity responsible for its own phys-
`ical response calculations. Conventions for kinematic
`human body animation are already under develop-
`ment by the h-anim working group at ece.
`uwaterloo.ca/~h-anim/.
`Sound. Computational requirements for spatial
`audio rendering are demanding. VRML provides a
`simple sound node to localize sound clips with their
`corresponding geometry. Widespread work in stream-
`ing audio is beginning to provide relatively low-band-
`width protocols with adequate sound quality and
`scalability. Further work in spatialized audio is begin-
`ning to show that advanced techniques for aural ren-
`dering are becoming possible on desktop machines.
`Further information is available via the Sound in
`Interactive Environments (SIE) mailing list at
`www.cs.nps.navy.mil/ people/phd/storms.
`VRTP. Finally, as the demanding bandwidth and
`latency requirements of virtual environments begin
`to be exercised by VRML and Java, some client-
`server design assumptions of the HTTP may no
`longer be valid. Users won’t be satisfied with net-
`work mechanisms that break down after a few hun-
`dred players. A spectrum of functionality is needed
`on each desktop including client, server, peer-to-peer,
`and network monitoring. Our research group is
`building a Virtual Reality Transfer Protocol (VRTP)
`to better take advantage of available transport-layer
`functionality for VRML and overcome bottlenecks in
`HTTP. Experimentation and quantitative evaluation
`are essential to develop the next-generation code
`needed for diverse interentity virtual environment
`communications.
`
`
`
`ol. 41, No. 6 COMMUNICATIONS OF THE ACM
`
`Next Steps
`A great deal of implementation work is now in
`progress. The best news: VRML and Java are pow-
`erful software languages for 3D modeling, general
`computation and network access. They are well
`matched, well specified, openly available and
`portable to most platforms on the Internet. VRML
`scenes in combination with Java can serve as the
`building blocks of cyberspace. Large-scale internet-
`worked worlds now appear possible. Using VRML
`and Java, practical experience and continued suc-
`cess will move the field of virtual reality past spec-
`ulative fiction and isolated islands of research and
`onto desktops everywhere, creating the next-gener-
`c
`ation Web.
`
`References
`1. Ames, A,.L., Nadeau, D.R. and Moreland, J.L. VRML 2.0 Sourcebook,
`second edition. John Wiley & Sons, New York, 1997. Information
`available via www.wiley.com/compbooks/vrml2sbk/ cover/cover.htm
`2. Carey, R. and Bell, G. Annotated VRML 2.0 Reference Manual. Addison-
`Wesley, Reading Mass., 1997; www.best.com/~rikk/Book/book.shtml
`3. Couch, J. Vermlgen software distribution, Virtual Light Company, Decem-
`ber 1997. Available via www.vlc.com.au/JVerge.
`4. Deering, M. and Sowizral, H. Java3D Specification, Version 1.0. Sun
`Microsystems Corp., Palo Alto, Calif., Aug. 1997; java.sun.com/ prod-
`ucts/java-media/3D/
`5. Harold, E.R. Java Network Programming. O’Reilly and Associates,
`Sebastopol Calif., 1997; www.ora.com/catalog/javanetwk with software
`at ftp.ora.com/published/oreilly/ java/java.netprog.
`6. Hartman, J. and Wernecke, J. VRML 2.0 Handbook. Addison-Wesley,
`Reading Mass., 1996.
`7. Hughes, M., Conrad, S.M. and Winslow, M. Java Network Programming.
`Manning Publications, Greenwich England, 1997; www.browse-
`books.com/Hughes with software available on CD-ROM (due to cryp-
`tographic software export restrictions).
`8. Lea, R., Matsuda, K. and Miyashita, K. Java for 3D and VRML Worlds.
`New Riders Publishing, Indianapolis Ind., 1996.
`9. Marrin, C. External Authoring Interface (EAI) Proposal. Silicon Graphics
`Inc., Mountain View Calif., 1997; Available via www.vrml.org.
`10. Roehl, B., Couch, J., Reed-Ballreich, C., Rohaly, T. and Brown, G. Late
`Night VRML 2.0 with Java. Ziff-Davis Press, MacMillan Publishing,
`Emeryville Calif., 1997; ece.uwaterloo.ca/~broehl/vrml/lnvj
`11. San Diego Supercomputing Center (SDSC), VRML Repository, 1997;
`www.sdsc.edu/vrml.
`12. VRML 97, International Specification ISO/IEC IS 14772-1, Dec. 1997;
`www.vrml.org.
`
`Don Brutzman (brutzman@nps.navy.mil) is an assistant
`professor at the Naval Postgraduate School in Monterey, Calif., and
`the technology vice president for the VRML Consortium.
`
`Permission to make digital or hard copies of all or part of this work for personal or class-
`room use is granted without fee provided that copies are not made or distributed for
`profit or commercial advantage and that copies bear this notice and the full citation on
`the first page. To copy otherwise, to republish, to post on servers or to redistribute to
`lists, requires prior specific permission and/or a fee.
`
`© 1998 ACM 0002-0782/98/0600 $5.00
`
`Fitbit, Inc. v. Philips North America LLC
`IPR2020-00828
`
`Fitbit, Inc. Ex. 1027 Page 0008
`
`