Chapter 5:
Conformance and
Minimum
Requirements
5.1 Intro
5.1.1 TOC
5.1.2 Goals
5.1.3 Scope
5.2 Conform
5.2.1 Files
5.2.2 Generators
5.2.3 Browsers
5.3 Min support
5.3.1 Generators
5.3.2 Browsers
5.3.3 Base profile
5.3.4 Sound
Chapter 5:
Conformance and
Minimum
Requirements
5.1 Intro
5.1.1 TOC
5.1.2 Goals
5.1.3 Scope
5.2 Conform
5.2.1 Files
5.2.2 Generators
5.2.3 Browsers
5.3 Min support
5.3.1 Generators
5.3.2 Browsers
5.3.3 Base profile
5.3.4 Sound
Chapter 5:
Conformance and
Minimum
Requirements
5.1 Intro
5.1.1 TOC
5.1.2 Goals
5.1.3 Scope
5.2 Conform
5.2.1 Files
5.2.2 Generators
5.2.3 Browsers
5.3 Min support
5.3.1 Generators
5.3.2 Browsers
5.3.3 Base profile
5.3.4 Sound
Chapter 5:
Conformance and
Minimum
Requirements
5.1 Intro
5.1.1 TOC
5.1.2 Goals
5.1.3 Scope
5.2 Conform
5.2.1 Files
5.2.2 Generators
5.2.3 Browsers
5.3 Min support
5.3.1 Generators
5.3.2 Browsers
5.3.3 Base profile
5.3.4 Sound
|
Chapter 5 Conformance and
Minimum Support Requirements
This chapter includes the VRML97 conformance guidelines. These
specifications define the minimum feature set that all VRML applications
must support. This information is useful to both implementors and authors.
This chapter addresses conformance of VRML files, VRML generators
and VRML browsers.
The primary objectives of the specifications in this chapter are:
- to promote interoperability by eliminating arbitrary subsets of,
or extensions to, ISO/IEC 14772;
- to promote uniformity in the development of conformance tests;
- to promote consistent results across VRML browsers;
- to facilitate automated test generation.
TIP:
This chapter is mostly intended for those writing VRML browsers
and authoring systems. However, the details described provide a
good idea of what features a user can expect to find in all
browsers. If you are creating VRML files and wish to ensure that
they run on as many browsers as possible, use only the features
described (and avoid features that are allowed to be "ignored").
|
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 chapter addresses the VRML data stream and implementation requirements.
Implementation requirements include the latitude allowed for VRML generators
and VRML browsers. This chapter does not directly address the environmental,
performance, or resource requirements of the generator or browser.
This chapter does not define the application requirements or dictate
application functional content within a VRML file.
The scope of this chapter is limited to rules for the open interchange
of VRML content.
A VRML file is syntactically correct according to ISO/IEC
14772 if the following conditions are met:
- The VRML file contains as its first element a VRML header
comment (see 4.4.1)
- All entities contained therein match the functional specification
of the corresponding entities of ISO/IEC 14772-1. The VRML file
shall obey the relationships defined in the formal grammar and all
other syntactic requirements.
- The sequence of entities in the VRML file obeys the relationships
specified in ISO/IEC 14772-1 producing the structure specified in
ISO/IEC 14772-1.
- All field values in the VRML file obey the relationships specified
in ISO/IEC 14772-1 producing the structure specified in ISO/IEC 14772-1.
- No nodes appear in the VRML file other than those specified
in ISO/IEC 14772-1 unless required for the encoding technique or those
defined by the PROTO or EXTERNPROTO entities.
- The VRML file is encoded according to the rules of ISO/IEC 14772.
A VRML file conforms to the base profile if:
- it is syntactically correct;
- it meets the restrictions of Table 5-1.
Unlike VRML files and VRML browsers, conformance of VRML generators
is not specifically defined. However, the probability of successful
interoperability of a VRML generator with VRML browsers conforming to
the base profile (see "5.2.3 Conformance of VRML
browsers") is significantly improved if the generator is capable
of operating in a mode that generates VRML files conforming to the base
profile.
A VRML browser conforms to the base profile if:
- it is able to read any VRML file that conforms to the base profile;
- it presents the graphical and audio characteristics of the VRML
nodes in any VRML file that conforms to the base profile, within the
latitude defined in this chapter;
- it correctly handles user interaction and generation of events
as specified in ISO/IEC 14772, within the latitude defined in this
chapter;
- it satisfies the requirements of "5.3.2 Minimum support requirements
for browsers" and as enumerated in Table 5-1.
There 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.
TIP:
The easiest way to test your generator (i.e., authoring system)
is to read the VRML output into the most conforming VRML browsers
that are available. |
This section 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 5-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
5-1 for a particular node, full support is required for other aspects
of that node.
In the following table, the first column defines the item for which
conformance is being defined. In some cases, general limits are defined
but are later overridden in specific cases by more restrictive limits.
The second column defines the requirements for a VRML file conforming
to the base profile; if a file contains any items that exceed these
limits, it may not be possible for a VRML browser conforming to the
base profile to successfully parse that file. The third column defines
the minimum complexity for a VRML scene that a VRML browser conforming
to the base profile shall be able to present to the user. The word "ignore"
in the minimum browser support column refers only to the display of
the item; in particular, set_ events to ignored exposedFields must still
generate corresponding _changed events.
Table 5-1: Specifications for VRML browsers conforming to the base
profile
- Item
(node/field/statement)
|
File Limit
|
Minimum Browser Support
|
All groups |
500 children. |
500 children. Ignore bboxCenter and bboxSize. |
All interpolators |
1000 key-value pairs. |
1000 key-value pairs. |
All lights |
8 simultaneous lights. |
8 simultaneous lights. |
Names for DEF/PROTO/field |
50 utf8 octets. |
50 utf8 octets. |
All url fields |
10 URLs. |
10 URLs. URN's ignored.
Support http, file, and ftp protocols.
Support relative URLs where relevant. |
PROTO/EXTERNPROTO |
30 fields, 30 eventIns, 30 eventOuts, 30 exposedFields. |
30 fields, 30 eventIns, 30 eventOuts, 30 exposedFields. |
PROTO definition nesting depth |
5 levels. |
5 levels. |
SFBool |
No restrictions. |
Full support. |
SFColor |
No restrictions. |
Full support. |
SFFloat |
No restrictions. |
Full support. |
SFImage |
256 width. 256 height. |
256 width. 256 height. |
SFInt32 |
No restrictions. |
Full support. |
SFNode |
No restrictions. |
Full support. |
SFRotation |
No restrictions. |
Full support. |
SFString |
30,000 utf8 octets. |
30,000 utf8 octets. |
SFTime |
No restrictions. |
Full support. |
SFVec2f |
15,000 values. |
15,000 values. |
SFVec3f |
15,000 values. |
15,000 values. |
MFColor |
15,000 values. |
15,000 values. |
MFFloat |
1,000 values. |
1,000 values. |
MFInt32 |
20,000 values. |
20,000 values. |
MFNode |
500 values. |
500 values. |
MFRotation |
1,000 values. |
1,000 values. |
MFString |
30,000 utf8 octets per string, 10 strings. |
30,000 utf8 octets per string, 10 strings. |
MFTime |
1,000 values. |
1,000 values. |
MFVec2f |
15,000 values. |
15,000 values. |
MFVec3f |
15,000 values. |
15,000 values. |
Anchor |
No restrictions. |
Ignore parameter. Ignore description. |
Appearance |
No restrictions. |
Full support. |
AudioClip |
30 second uncompressed PCM WAV. |
30 second uncompressed PCM WAV. Ignore description. |
Background |
No restrictions. |
One skyColor, one groundColor, panorama images as
per ImageTexture. |
Billboard |
Restrictions as for all groups. |
Full support except as for all groups. |
Box |
No restrictions. |
Full support. |
Collision |
Restrictions as for all groups. |
Full support except as for all groups. Any navigation behaviour
acceptable when collision occurs. |
Color |
15,000 colours. |
15,000 colours. |
ColorInterpolator |
Restrictions as for all interpolators. |
Full support except as for all interpolators. |
Cone |
No restrictions. |
Full support. |
Coordinate |
15,000 points. |
15,000 points. |
CoordinateInterpolator |
15,000 coordinates per keyValue. Restrictions as for all
interpolators. |
15,000 coordinates per keyValue. Support as for all interpolators.
|
Cylinder |
No restrictions. |
Full support. |
CylinderSensor |
No restrictions. |
Full support. |
DirectionalLight |
No restrictions. |
Not scoped by parent Group or Transform. |
ElevationGrid |
16,000 heights. |
16,000 heights. |
Extrusion |
(#crossSection points)*(#spine points) <= 2,500.
|
(#crossSection points)*(#spine points) <= 2,500.
|
Fog |
No restrictions. |
"EXPONENTIAL" treated as "LINEAR" |
FontStyle |
No restrictions. |
If the values of the text aspects character set, family,
style cannot be simultaneously supported, the order of precedence
shall be: 1) character set 2) family 3) style. Browser
must display all characters in ISO 8859-1 character set. |
Group |
Restrictions as for all groups. |
Full support except as for all groups. |
ImageTexture |
JPEG and PNG format. Restrictions as for PixelTexture. |
JPEG and PNG format. Support as for PixelTexture. |
IndexedFaceSet |
10 vertices per face. 5000 faces. Less than 15,000 indices. |
10 vertices per face. 5000 faces. 15,000 indices in any index field.
|
IndexedLineSet |
15,000 total vertices. 15,000 indices in any index field. |
15,000 total vertices. 15,000 indices in any index field. |
Inline |
No restrictions. |
Full support except as for all groups. |
LOD |
Restrictions as for all groups. |
At least first 4 level/range combinations interpreted,
and support as for all groups. Implementations may disregard level
distances. |
Material |
No restrictions. |
Ignore ambient intensity. Ignore specular colour. Ignore emissive
colour. One-bit transparency; transparency values >= 0.5 transparent.
|
MovieTexture |
MPEG1-Systems and MPEG1-Video formats. |
MPEG1-Systems and MPEG1-Video formats. Display one active movie
texture. Ignore speed field. |
NavigationInfo |
No restrictions. |
Ignore avatarSize. Ignore visibilityLimit. |
Normal |
15,000 normals |
15,000 normals |
NormalInterpolator |
15,000 normals per keyValue. Restrictions as for all interpolators.
|
15,000 normals per keyValue. Support as for all interpolators.
|
OrientationInterpolator |
Restrictions as for all interpolators. |
Full support except as for all interpolators. |
PixelTexture |
256 width. 256 height. |
256 width. 256 height. Display fully transparent and fully opaque
pixels. |
PlaneSensor |
No restrictions. |
Full support. |
PointLight |
No restrictions. |
Ignore radius. Linear attenuation. |
PointSet |
5000 points. |
5000 points. |
PositionInterpolator |
Restrictions as for all interpolators. |
Full support except as for all interpolators. |
ProximitySensor |
No restrictions. |
Full support. |
ScalarInterpolator |
Restrictions as for all interpolators. |
Full support except as for all interpolators. |
Script |
25 eventIns. 25 eventOuts. 25 fields. |
25 eventIns. 25 eventOuts. 25 fields. |
Shape |
No restrictions. |
Full support. |
Sound |
No restrictions. |
2 active sounds. Linear distance attenuation. No spatialization.
See 5.3.4. |
Sphere |
No restrictions. |
Full support. |
SphereSensor |
No restrictions. |
Full support. |
SpotLight |
No restriction |
Ignore beamWidth. Ignore radius. Linear attenuation. |
Switch |
Restrictions as for all groups. |
Full support except as for all groups. |
Text |
100 characters per string. 100 strings. |
100 characters per string. 100 strings. |
TextureCoordinate |
15,000 coordinates. |
15,000 coordinates. |
TextureTransform |
No restrictions. |
Full support. |
TimeSensor |
No restrictions. |
Ignored if cycleInterval < 0.01 second. |
TouchSensor |
No restrictions. |
Full support. |
Transform |
Restrictions as for all groups. |
Full support except as for all groups. |
Viewpoint |
No restrictions. |
Ignore fieldOfView. Ignore description. |
VisibilitySensor |
No restrictions. |
Always visible. |
WorldInfo |
No restrictions. |
Ignored. |
5.3.4.1 Sound priority
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:
- Decreasing priority;
- For sounds with priority > 0.5, increasing (now-startTime);
- Decreasing intensity at viewer location (intensity
* intensity attenuation);
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.
5.3.4.2 Sound attenuation and spatialization
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 5-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
Figure 5-1: Stereo Panning
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 [SNDB]).
|