7.1 Introduction7.1 Introduction
7.1.1 Table of contents
7.1.2 Objectives
7.1.3 Scope
7.2 Conformance
7.2.1 Conformance of VRML files
7.2.2 Conformance of VRML
generators
7.2.3 Conformance of VRML
browsers
7.3 Minimum support requirements
7.3.1 Minimum support requirements
for generators
7.3.2 Minimum support requirements
for browsers
7.3.3 Sound priority, attenuation,
and spatialization
This clause addresses conformance of VRML files, VRML generators and VRML browsers.
The primary objectives of the specifications in this clause are:
Conformance is defined for VRML files and for VRML browsers. For VRML generators, conformance guidelines are presented for enhancing the likelihood of successful interoperability.
A concept of base profile conformance is defined to ensure interoperability of VRML generators and VRML browsers. Base profile conformance is based on a set of limits and minimal requirements. Base profile conformance is intended to provide a functional level of reasonable utility for VRML generators while limiting the complexity and resource requirements of VRML browsers. Base profile conformance may not be adequate for all uses of VRML.
This clause addresses the VRML data stream and implementation requirements. Implementation requirements include the latitude allowed for VRML generators and VRML browsers. This clause does not directly address the environmental, performance, or resource requirements of the generator or browser.
This clause does not define the application requirements or dictate application functional content within a VRML file.
The scope of this clause is limited to rules for the open interchange of VRML content.
7.2 ConformanceA VRML file is syntactically correct according to ISO/IEC 14772 if the following conditions are met:
A VRML file conforms to the base profile if:
A VRML generator is conforming to this part of ISO/IEC 14772 if all VRML files that are generated are syntactically correct.
A VRML generator conforms to the base profile if it can be configured such that all VRML files generated conform to the base profile.
A VRML browser conforms to the base profile if:
7.3 Minimum support requirementsThere is no minimum complexity which is required of (or appropriate for) VRML generators. Any compliant set of nodes of arbitrary complexity may be generated, as appropriate to represent application content.
This subclause defines the minimum complexity which shall be supported by a VRML browser. Browser implementations may choose to support greater limits but may not reduce the limits described in Table 7.1. When the VRML file contains nodes which exceed the limits implemented by the browser, the results are undefined. Where latitude is specified in Table 7.1 for a particular node, full support is required for other aspects of that node.
If the browser does not have the resources to play all of the currently active sounds, it is recommended that the browser sort the active sounds into an ordered list using the following sort keys in the order specified:
where priority is the priority field of the Sound node, now represents the current time, startTime is the startTime field of the audio source node specified in the source field, and intensity attenuation refers to the intensity multiplier derived from the linear decibel attenuation ramp between inner and outer ellipsoids.
It is important that sort key 2 be used for the high priority (event and cue) sounds so that new cues will be heard even when the browser is "full" of currently active high priority sounds. Sort key 2 should not be used for normal priority sounds, so selection among them will be based on sort key 3 (intensity at the location of the viewer).
The browser shall play as many sounds from the beginning of this sorted list as it can given available resources and allowable latency between rendering. On most systems, the resources available for MIDI streams are different from those for playing sampled sounds, thus it may be beneficial to maintain a separate list to handle MIDI data.
In order to create a linear decrease in loudness as the viewer moves from the inner to the outer ellipsoid of the sound, the attenuation must be based on a linear decibel ramp. To make the falloff consistent across browsers, the decibel ramp is to vary from 0 dB at the minimum ellipsoid to -20 dB at the outer ellipsoid. Sound nodes with an outer ellipsoid that is ten times larger than the minimum will display the inverse square intensity dropoff that approximates sound attenuation in an anechoic environment.
Browsers may support spatial localization of sounds whose spatialize field is TRUE as well as their underlying sound libraries will allow. Browsers shall at least support stereo panning of non-MIDI sounds based on the angle between the viewer and the source. This angle is obtained by projecting the Sound location (in global space) onto the XZ plane of the viewer. Determine the angle between the Z-axis and the vector from the viewer to the transformed location, and assign a pan value in the range [0.0, 1.0] as depicted in Figure 7.1. Given this pan value, left and right channel levels can be obtained using the following equations:
leftPanFactor = 1 - pan2
rightPanFactor = 1 - (1 - pan)2
Using this technique, the loudness of the sound is modified by the intensity field value, then distance attenuation to obtain the unspatialized audio output. The values in the unspatialized audio output are then scaled by leftPanFactor and rightPanFactor to determine the final left and right output signals. The use of more sophisticated localization techniques is encouraged, but not required (see E.[SNDB]).