'ChangeLog.html' is in reverse chronological order. This work is licensed under the Creative Commons Attribution License. To view a copy of this license, visit http://creativecommons.org/licenses/by/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. World is the root node for an xVRML instance. All attributes of all nodes are accessable after loading. A particular attribute of a particular node may be accessed in three ways. If the node has a non-empty name, then an attribute of that node may be accessed by the notation 'nodeName.attributeName'. A particular attribute of a particular node may also be accessed by treepath-index-value, as in the notation 'World.children[0].attributeName'. A particular attribute of a particular node may also be accessed using accessor and mutator functions following the function-naming pattern 'getAttributename()' or 'setAttributename()'. Any element which contains "children" as a sub-element must also provide four accessor and mutator functions: 'addChild()' inserts one child node onto the end of the list of children of that element. 'removeChild()' removes a particular child from the list of children of that element. 'getChildren()' returns a list of all the children of that element. 'setChildren()' replaces the list of children of that element with a new list of children. Root node for a top-level xVRML World. If a World is loaded by an Inline element, then its children and WorldInfo.info should be extracted. Its WorldInfo.info should be inserted into the WorldInfo of the top-level World (thereby retaining content-creator information). Its children should be placed in a new Group element befor insertion into the top-level World. For the purposes of navigation an application should do the following: (1) apply the current transform state of the enclosing hierarchy to the Viewpoint (2) apply the Viewpoint.position (3) apply the Avatar.cameraOffset (4) apply the Viewpoint.orientation. The sum of these transformations creates the final position and orientation against which all navigation (for example, due to user gestures) shall occur in the World. children required but might be empty. Optional AvatarList may be empty. One Avatar can not Use another. This used to be the NavigationInfo headlight attribute. This used to be the NavigationInfo visibilitylimit attribute. children and url required. When the user activates (e.g., selects with a pointing device) some geometry contained within the Anchor node's children, the Anchor node retrieves the contents at the URI listed in the url attribute. If that URI points to a valid xVRML file, then that World replaces the World of which the Anchor node is a part (except when the parameter field, described below, alters this behavior). If non-xVRML data is retrieved, then the xVRML application shall determine how to handle that data. Typically, it will be passed to an appropriate specialized media-handling application (in the case of a standalone xVRML viewer) or to the enclosing application (perhaps an xVRML Web browser plugin). By specifying a URI ending with "#ViewpointName" (where "ViewpointName" is the name attribute of a Viewpoint defined in the World being loaded), an Anchor node may be used to indicate the initial Viewpoint for the World being loaded. If the named Viewpoint is not found in the World being loaded, it is loaded using the default Viewpoint for that World. The description may be used by application-specific user interfaces wishing to present users with more detailed information about the Anchor. The parameter may be used to supply any additional information to be interpreted by the xVRML application. Each string shall consist of "keyword='value'" pairs. bboxCenter and bboxSize specify a bounding box that encloses the Anchor's children. This is a hint that may be used for optimization purposes. Results are undefined if the specified bounding box is smaller than the actual bounding box of the children at any time. If the actual bboxSize value is the default bboxSize value of (-1, -1, -1), then this implies that the bounding box is not specified and if needed shall be calculated by the xVRML application. Results are undefined if there are multiple Viewpoints with the same name in the Anchor's run-time name scope(s) (after Inlines have been processed). AudioClip should allow playback of at least the wavefile format in uncompressed PCM format (wav) and MPEG Audio Layer 3 (mp3). AudioClip is a time-dependent node that activates and deactivates itself at specified times. AudioClip can execute for 0 or more cycles. A cycle is defined by data within the node. If, at the end of a cycle, the value of loop is FALSE, execution is terminated. Conversely, if loop is TRUE at the end of a cycle, an AudioClip continues execution into the next cycle. An AudioClip continues cycling forever if stopTime is equal to 0. AudioClip is inactive until its startTime is reached. When time now becomes greater than or equal to startTime, an AudioClip becomes active. Now refers to the time at which the virtual world is simulated and displayed by the application. NOTE TO TEAM: we need to find a better way to deal with defining and expressing time, as "seconds since 1 JAN 1970" makes sense only to programmers. url specifies the URI from which the sound is loaded. The pitch field specifies a multiplier for the rate at which sampled sound is played. Values for the pitch field shall be greater than zero. Changing the pitch field affects both the pitch and playback speed of a sound. If pitch is set to 2.0, the sound shall be played one octave higher than normal and played twice as fast. For a sampled sound, the pitch field alters the sampling rate at which the sound is played. description specifies a textual description of the audio source. An application is not required to display the description field but may choose to do so in addition to playing the sound. startTime, stopTime, and url required. navigation is a whitespace-delimited list from 'ANY WALK EXAMINE FLY NONE'. For the purposes of navigation an application should do the following: (1) apply the current transform state of the enclosing hierarchy to the Viewpoint (2) apply the Viewpoint.position (3) apply the Avatar.cameraOffset (4) apply the Viewpoint.orientation. The sum of these transformations creates the final position and orientation against which all navigation (for example, due to user gestures) shall occur in the World. speed is a multiplier factor. cameraOffset is from center of children. mass is in kg. stepValue is the height of the tallest object over which the user Avatar can move (in meters). This allows (for example) staircases to be built with dimensions that can be ascended by users in WALK mode. stepValue is a non-negative float, and defaults to a value of 0.75 m. cameraOffset default is about eye-height for an average person. If a current Avatar is set for a given user then the cameraOffset of that Avatar is added to any Viewpoint settings. Viewpoints are not allowed in Avatar children to avoid the possibility of cyclic references. There are four basic combinations of Avatar and Viewpoint. No Avatar and no Viewpoint is specified in the file. In this case the initial user position in the World shall be a combination of the default Viewpoint position ('0.0 0.0 10.0') plus the default Avatar cameraOffset ('0.0 1.65 0.0'). This makes the default initial user position "0.0 1.65 10.0" and the default initial user rotation "0.0 0.0 1.0 0.0". An Avatar but no Viewpoint is specified in the file. In this case the initial user position in the World shall be a combination of the default Viewpoint position ('0.0 0.0 10.0') plus the cameraOffset of the first Avatar found loading the file. A Viewpoint but no Avatar is specified in the file. In this case the initial user position in the World shall be a combination of the Viewpoint position of the first Viewpoint found loading the file plus the default Avatar cameraOffset ('0.0 1.65 0.0'). Both an Avatar and a Viewpoint are specified in the file. In this case the initial user position in the World shall be a combination of the Viewpoint position of the first Viewpoint found loading the file plus the cameraOffset of the first Avatar found loading the file. bboxSize, if present, overrides bboxSize of children. name is required. This used to be the NavigationInfo type attribute. This used to be the NavigationInfo speed attribute. Background node is used to specify a color backdrop that simulates ground and sky, as well as a background texture, or panorama, that is placed behind all geometry in the scene and in front of the ground and sky. Background nodes are specified in the local coordinate system and are affected by the accumulated rotation of their ancestors as described below. The backdrop is conceptually a partial sphere (the ground) enclosed inside of a full sphere (the sky) in the local coordinate system with the viewer placed at the center of the spheres. Both spheres have infinite radius and each is painted with concentric circles of interpolated color perpendicular to the local Y-axis of the sphere. The Background node is subject to the accumulated rotations of its ancestors' transformations. Scaling and translation transformations are ignored. The sky sphere is always slightly farther away from the viewer than the ground partial sphere causing the ground to appear in front of the sky where they overlap. The skyColor field specifies the color of the sky at various angles on the sky sphere. The first value of the skyColor field specifies the color of the sky at 0.0 radians representing the zenith (i.e., straight up from the viewer). The skyAngle field specifies the angles from the zenith in which concentric circles of color appear. The zenith of the sphere is implicitly defined to be 0.0 radians, the natural horizon is at PI/2 radians, and the nadir (i.e., straight down from the viewer) is at PI radians. skyAngle is restricted to non-decreasing values in the range [0.0, PI]. There shall be one more skyColor value than there are skyAngle values. The first color value is the color at the zenith, which is not specified in the skyAngle field. If the last skyAngle is less than PI, then the color band between the last skyAngle and the nadir is clamped to the last skyColor. The sky color is linearly interpolated between the specified skyColor values. The groundColor field specifies the color of the ground at the various angles on the ground partial sphere. The first value of the groundColor field specifies the color of the ground at 0.0 radians representing the nadir (i.e., straight down from the user). The groundAngle field specifies the angles from the nadir that the concentric circles of color appear. The nadir of the sphere is implicitly defined at 0.0 radians. groundAngle is restricted to non-decreasing values in the range [0.0, PI/2]. There shall be one more groundColor value than there are groundAngle values. The first color value is for the nadir which is not specified in the groundAngle field. If the last groundAngle is less than PI/2, the region between the last groundAngle and the equator is non-existant. The ground color is linearly interpolated between the specified groundColor values. The backUrl, bottomUrl, frontUrl, leftUrl, rightUrl, and topUrl fields specify a set of images that define a background panorama between the ground/sky backdrop and the scene's geometry. The panorama consists of six images, each of which is mapped onto a face of an infinitely large cube contained within the backdrop spheres and centred in the local coordinate system. The images are applied individually to each face of the cube. On the front, back, right, and left faces of the cube, when viewed from the origin looking down the negative Z-axis with the Y-axis as the view up direction, each image is mapped onto the corresponding face with the same orientation as if the image were displayed normally in 2D (backUrl to back face, frontUrl to front face, leftUrl to left face, and rightUrl to right face). On the top face of the cube, when viewed from the origin looking along the +Y-axis with the +Z-axis as the view up direction, the topUrl image is mapped onto the face with the same orientation as if the image were displayed normally in 2D. On the bottom face of the box, when viewed from the origin along the negative Y-axis with the negative Z-axis as the view up direction, the bottomUrl image is mapped onto the face with the same orientation as if the image were displayed normally in 2D. Alpha values in the panorama images (i.e., two or four component images) specify that the panorama is semi-transparent or transparent in regions, allowing the groundColor and skyColor to be visible. Often, the bottomUrl and topUrl images will not be specified, to allow sky and ground to show. The other four images may depict surrounding mountains or other distant scenery. Applications shall support the PNG and JPEG image file formats. Support for other image formats (e.g., GIF) that can be rendered into a 2D image is recommended (including transparency). Ground colors, sky colors, and panoramic images do not translate with respect to the viewer, though they do rotate with respect to the viewer. That is, the viewer can never get any closer to the background but can turn to examine all sides of the panorama cube, and the viewer can look up and down to see the concentric rings of ground and sky (if visible). Background nodes are not affected by Fog nodes. Therefore, if a Background node is present while a Fog node is active, then the Background node will be displayed with no fogging effects. It is the author's responsibility to set the Background values to match the Fog values (e.g., ground colors fade to fog color with distance and panorama images tinted with fog color). Background nodes are not affected by light sources. Default skyColor is black (0.0 0.0 0.0). children required. The Billboard node is a grouping node which modifies its coordinate system so that the Billboard node's local Z-axis turns to point at the viewer. The Billboard node has children which may be other children nodes. The axisOfRotation field specifies which axis to use to perform the rotation. This axis is defined in the local coordinate system. When the axisOfRotation field is not (0, 0, 0), the following steps describe how to rotate the billboard to face the viewer: 1. Compute the vector from the Billboard node's origin to the viewer's position. This vector is called the billboard-to-viewer vector. 2. Compute the plane defined by the axisOfRotation and the billboard-to-viewer vector. 3. Rotate the local Z-axis of the billboard into the plane from b., pivoting around the axisOfRotation. When the axisOfRotation field is set to (0, 0, 0), the special case of viewer-alignment is indicated. In this case, the object rotates to keep the billboard's local Y-axis parallel with the Y-axis of the viewer. This special case is distinguished by setting the axisOfRotation to (0, 0, 0). The following steps describe how to align the billboard's Y-axis to the Y-axis of the viewer: 4. Compute the billboard-to-viewer vector. 5. Rotate the Z-axis of the billboard to be collinear with the billboard-to-viewer vector and pointing towards the viewer's position. 6. Rotate the Y-axis of the billboard to be parallel and oriented in the same direction as the Y-axis of the viewer. If the axisOfRotation and the billboard-to-viewer line are coincident, the plane cannot be established and the resulting rotation of the billboard is undefined. For example, if the axisOfRotation is set to (0,1,0) (Y-axis) and the viewer flies over the billboard and peers directly down the Y-axis, the results are undefined. Multiple instances of Billboard nodes operate as expected: each instance rotates in its unique coordinate system to face the viewer. The bboxCenter and bboxSize fields specify a bounding box that encloses the Billboard node's children. This is a hint that may be used for optimization purposes. The results are undefined if the specified bounding box is smaller than the actual bounding box of the children at any time. A default bboxSize value implies that the bounding box is not specified and if needed shall be calculated by the application. The Box node specifies a rectangular parallelepiped box centred at (0, 0, 0) in the local coordinate system and aligned with the local coordinate axes. By default, the box measures 2 units in each dimension, from -1 to +1. The size field specifies the extents of the box along the X-, Y-, and Z-axes respectively and each component value shall be greater than zero. Textures are applied individually to each face of the box. On the front (+Z), back (-Z), right (+X), and left (-X) faces of the box, when viewed from the outside with the +Y-axis up, the texture is mapped onto each face with the same orientation as if the image were displayed normally in 2D. On the top face of the box (+Y), when viewed from above and looking down the Y-axis toward the origin with the -Z-axis as the view up direction, the texture is mapped onto the face with the same orientation as if the image were displayed normally in 2D. On the bottom face of the box (-Y), when viewed from below looking up the Y-axis toward the origin with the +Z-axis as the view up direction, the texture is mapped onto the face with the same orientation as if the image were displayed normally in 2D. The Box node's geometry defaults to outside faces only. When viewed from the inside, no faces are visible if the solid attribute is true (the default). When solid is false, both sides of the faces are drawn. $figure01$ children required. The Collision node is a grouping node that specifies the collision detection properties for its children (and their descendants), specifies surrogate objects that replace its children during collision detection, and sends events signalling that a collision has occurred between the avatar and the Collision node's geometry or surrogate. By default, all geometric nodes in the scene are collidable with the viewer except IndexedLineSet, PointSet, and Text. Viewers shall detect geometric collisions between the avatar and the scene's geometry and prevent the avatar from 'entering' the geometry. If there are no Collision nodes specified in an xVRML file, then viewers shall detect collisions between the avatar and all objects during navigation. The Collision node's collide attribute enables and disables collision detection. If collide is set to false, then the children and all descendants of the Collision node shall not be checked for collision, even though they are drawn. This includes any descendent Collision nodes that have collide set to true (i.e., setting collide to false turns collision off for every node below it). Collision nodes with collide set to TRUE detect the nearest collision with their descendent geometry (or proxies). When the nearest collision is detected, the collided Collision node sends the time of the collision through a collide-time event. If a Collision node contains a child, descendant, or proxy (see below) then that is a Collision node and both Collision nodes detect that a collision has occurred, both send a collide-time event at the same time. A collide-time event shall be generated if the avatar is colliding with collidable geometry when the Collision node is read from an xVRML file or inserted into the transformation hierarchy. The bboxCenter and bboxSize attributes specify a bounding box that encloses the Collision node's children. This is a hint that may be used for optimization purposes. The results are undefined if the specified bounding box is smaller than the actual bounding box of the children at any time. A default bboxSize value, (-1, -1, -1), implies that the bounding box is not specified and if needed shall be calculated by the browser. The collision proxy, defined in the proxy element, is any legal groupingAndChildrenNodes node that is used as a substitute for the Collision node's children during collision detection. The proxy is used strictly for collision detection; it is not drawn. If the value of the collide field is true and the proxy element is non-null, the proxy element defines the scene on which collision detection is performed. If the proxy is not present, then collision detection is performed against the children of the Collision node. If proxy is specified, any descendent children of the Collision node are ignored during collision detection. If children is empty, collide is true, and proxy is specified, collision detection is performed against the proxy but nothing is displayed. In this manner, invisible collision objects may be supported. The collide-time event specifies the time when the avatar makes contact with the collidable children or proxy of the Collision node. An ideal implementation computes the exact time of collision. Implementations may approximate the ideal by sampling the positions of collidable objects and the user. Matched pairs key and keyValue required. This node interpolates among a list of MFColor key values to produce an SFColor (RGBA) value-changed event. The number of colors in the keyValue element shall be equal to the number of keyframes in the key element. The keyValue element and value-changed events are defined in RGBA color space. A linear interpolation using the values of the set-fraction message associated with the generated event as input is performed in HSV space. The results are undefined when interpolating between two consecutive keys with complementary hues. The Cone node specifies a cone which is centred in the local coordinate system and whose central axis is aligned with the local Y-axis. The bottomRadius attribute specifies the radius of the cone's base, and the height attribute specifies the height of the cone from the center of the base to the apex. By default, the cone has a radius of 1.0 at the bottom and a height of 2.0, with its apex at y = height/2 and its bottom at y = -height/2. Both bottomRadius and height shall be greater than zero. http://www.xvrml.net/images/cone.png illustrates the Cone node. The side attribute specifies whether sides of the cone are created and the bottom attribute specifies whether the bottom cap of the cone is created. A value of true specifies that this part of the cone exists, while a value of false specifies that this part does not exist (not rendered or eligible for collision or sensor intersection tests). When a texture is applied to the sides of the cone, the texture wraps counterclockwise (from above) starting at the back of the cone. The texture has a vertical seam at the back in the X=0 plane, from the apex (0, height/2, 0) to the point (0, -height/2, -bottomRadius). For the bottom cap, a circle is cut out of the texture square centred at (0, -height/2, 0) with dimensions (2 × bottomRadius) by (2 × bottomRadius). The bottom cap texture appears right side up when the top of the cone is rotated towards the -Z-axis. Transformations in the Texture node attributes affect the texture coordinates of the Cone. The Cone geometry defaults to outside faces only. When viewed from the inside, no faces are visible if the solid attribute is true (the default). When solid is false, both sides of the faces are drawn. $figure02$ Matched pairs key and keyValue required. This node linearly interpolates among a list of MFVec3f values. The number of coordinates in the keyValue element shall be an integer multiple of the number of keyframes in the key element. That integer multiple defines how many coordinates will be contained in the value-changed events. The Cylinder node specifies a capped cylinder centered at (0,0,0) in the local coordinate system and with a central axis oriented along the local Y-axis. By default, the cylinder is sized at "-1" to "+1" in all three dimensions. The radius attribute specifies the radius of the cylinder and the height attribute specifies the height of the cylinder along the central axis. Both radius and height shall be greater than zero. http://www.xvrml.net/images/cylinder.png illustrates the Cylinder node. The cylinder has three parts: the side, the top (Y = +height/2) and the bottom (Y = -height/2). Each part has an associated boolean attribute indicating whether the part exists (true) or does not exist (false). Parts which do not exist are not rendered and are not eligible for intersection tests (e.g., collision detection or sensor activation). When a texture is applied to a cylinder, it is applied differently to the sides, top, and bottom. On the sides, the texture wraps counterclockwise (from above) starting at the back of the cylinder. The texture has a vertical seam at the back, intersecting the X=0 plane. For the top and bottom caps, a circle is cut out of the unit texture squares centred at (0, +/- height/2, 0) with dimensions 2 × radius by 2 × radius. The top texture appears right side up when the top of the cylinder is tilted toward the +Z-axis, and the bottom texture appears right side up when the top of the cylinder is tilted toward the -Z-axis. Transformations in the Texture node affect the texture coordinates of the Cylinder node. The Cylinder node's geometry defaults to outside faces only. When viewed from the inside, no faces are visible if the solid attribute is true (the default). When solid is false, both sides of the faces are drawn. $figure03$ The CylinderSensor node maps pointer motion (e.g., a mouse or wand) into a rotation on an invisible cylinder that is aligned with the Y-axis of the local coordinate system. The CylinderSensor uses the descendent geometry of its parent node to determine whether it is liable to generate events. The enabled attribute enables and disables the CylinderSensor node. If true, then the sensor reacts appropriately to user events. If false, then the sensor does not track user input or send events. If enabled receives a false event and isActive is true, then the sensor becomes disabled and deactivated, and generates an isActive false event. If enabled receives a true event, then the sensor is enabled and ready for user activation. A CylinderSensor node generates events when the pointing device is activated while the pointer is indicating any descendent geometry nodes of the sensor's parent group. Upon activation of the pointing device while indicating the sensor's geometry, an isActive true event is generated. The initial acute angle between the bearing vector and the local Y-axis of the CylinderSensor node determines whether the sides of the invisible cylinder or the caps (disks) are used for manipulation. If the initial angle is less than the diskAngle, then the geometry is treated as an infinitely large disk lying in the local Y=0 plane and coincident with the initial intersection point. Dragging motion is mapped into a rotation around the local +Y-axis vector of the sensor's coordinate system. The perpendicular vector from the initial intersection point to the Y-axis defines zero rotation about the Y-axis. For each subsequent position of the bearing, a rotation-changed event is generated that equals the sum of the rotation about the +Y-axis vector (from the initial intersection to the new intersection) plus the offset value. trackPoint-changed events reflect the unclamped drag position on the surface of this disk. When the pointing device is deactivated and autoOffset is true, then offset is set to the last rotation-changed event value and an offset-changed event is generated. If the initial acute angle between the bearing vector and the local Y-axis of the CylinderSensor node is greater than or equal to diskAngle, then the sensor behaves like a cylinder. The shortest distance between the point of intersection (between the bearing and the sensor's geometry) and the Y-axis of the parent group's local coordinate system determines the radius of an invisible cylinder used to map pointing device motion and marks the zero rotation value. For each subsequent position of the bearing, a rotation-changed event is generated that equals the sum of the right-handed rotation from the original intersection about the +Y-axis vector plus the offset value. trackPoint-changed events reflect the unclamped drag position on the surface of the invisible cylinder. When the pointing device is deactivated and autoOffset is true, offset is set to the last rotation angle and an offset-changed event is generated. When the sensor generates an isActive true event, it grabs all further motion events from the pointing device until it is released and generates an isActive false event (other pointing-device sensors shall not generate events during this time). Motion of the pointing device while isActive is true is referred to as a "drag." If a 2D pointing device is in use, isActive events will typically reflect the state of the primary button associated with the device (i.e., isActive is true when the primary button is pressed and false when it is released). If a 3D pointing device (e.g., a wand) is in use, isActive events will typically reflect whether the pointer is within or in contact with the sensor's geometry. While the pointing device is activated, trackPoint-changed and rotation-changed events are output and are interpreted from pointing device motion based on the sensor's local coordinate system at the time of activation. trackPoint-changed events represent the unclamped intersection points on the surface of the invisible cylinder or disk. If the initial angle results in cylinder rotation (as opposed to disk behaviour) and if the pointing device is dragged off the cylinder while activated, then viewers may interpret this in a variety of ways (e.g., clamping all values to the cylinder and continuing to rotate as the point is dragged away from the cylinder). Each movement of the pointing device while isActive is true generates trackPoint-changed and rotation-changed events. The minAngle and maxAngle attributes clamp rotation-changed events to a range of values. If minAngle is greater than maxAngle, rotation-changed events are not clamped. The minAngle and maxAngle fields are restricted to the range [-2, 2]. Default LightColor is pure white. height required. crossSection and spine required. The Extrusion node's geometry defaults to outside faces only. When viewed from the inside, no faces are visible if the solid attribute is true (the default). When solid is false, both sides of the faces are drawn. color required. NOTE TO TEAM: look at implementing this as "if you are within x range of this fog node then turn it on." This would make Fog become essentially a function of the current position of the current Viewpoint. children required. imageUrl required. coord and coordIndex required. coordIndex and texCoordIndex tightly constrained. Each requires a set of three or more point references followed by a -1 per face. colorIndex and normalIndex may use -1s, depending upon the state of colorPerVertex and normalPerVertex. Runs of many point references. Each run of many must be followed by a -1, except for final run where -1 is optional. Runs of many point references. Each run of many must be followed by a -1, except for final run where -1 is optional. coord and coordIndex required. coordIndex tightly constrained. Requires point references followed by a -1 per line. colorIndex may use -1s, depending upon the state of colorPerVertex. Runs of many point references. Each run of many must be followed by a -1, except for final run where -1 is optional. Root World in the uri being loaded should be replaced by a Group element before it is inserted into the current top-level world. WorldInfo should be retained. url required. Matched pairs level and range required. Each type of color can support an alpha channel. Unlike the original VRML specifications, if you do not specify any color values it will default to pure black (RGBA = 0.0 0.0 0.0 1.0). MovieTexture should allow extraction and playback of the audio layer from an MPEG movie. Recommended that MovieTexture also allow extraction and playblack of the audio layer from a QuickTime movie. startTime, stopTime, and movieUrl required. Matched pairs key and keyValue required. Matched pairs key and keyValue required. NOTE TO TEAM: make regex for this so that maximum for numComponents is 4 Note that the number of pixelValue entries must be a power of 2 The PointLight node specifies a point light source at a 3D location in the local coordinate system. A point light source emits light equally in all directions; that is, it is omnidirectional. PointLight nodes are specified in the local coordinate system and are affected by ancestor transformations. The PointLight node contains a color element. It also has intensity and ambientIntensity attributes. The intensity attribute specifies the brightness of the direct emission from the light, and the ambientIntensity attribute specifies the intensity of the ambient emission from the light. Light intensity may range from 0.0 (no light emission) to 1.0 (full intensity). The color element specifies the spectral color properties of both the direct and ambient light emission as an RGBA value, defaulting to pure white (RGBA = 1.0 1.0 1.0 1.0). PointLights illuminate all objects in the world that fall within their volume of lighting influence regardless of location within the transformation hierarchy. PointLight defines this volume of influence as a sphere centered at the light (defined by the radius attribute). The location attribute specifies an offset from the local coordinate system. The illumination of a PointLight falls off with distance as specified by the three attenuation coefficients. The attenuation factor is 1/max(attenuation[0] + attenuation[1]*r + attenuation[2]*r^2, 1), where r is the distance from the light to the surface being illuminated. The default is no attenuation. An attenuation value of (0.0, 0.0, 0.0) is identical to (1.0, 0.0, 0.0). Attenuation values shall be greater than or equal to zero. coord required. Matched pairs key and keyValue required. name is required. Also has possibly empty children and zero to many FieldDefinition elements. FieldDefinition may have one (optional) child element which must be from this namespace and is to be strictly validated. This allows the setting of values for complex types. The optional defaultValue attribute allows setting of default values for simple types defined. FieldDefinition can have either a child element or a defaultValue, but not both. Field may have one (optional) child element which must be from this namespace and is to be strictly validated. This allows defining the value of a complex type. The optional value attribute allows setting of values for a simple type. Field can have either a child element or a value, but not both. from and to each hold the name of an object, while fromParameter and toParameter each name the property of interest. Should act as a change listener attached to from. from, fromParameter, to, and toParameter all required. Matched pairs key and keyValue required. There must be a better way to do this. url and type required. type provides MIME-type. appearance and geometry required. One and only one each of Material Texture TextureTransform allowed in any order. Any or all of them may be replaced by a Use. AudioClip should allow playback of at least the wavefile format in uncompressed PCM format (wav) and MPEG Audio Layer 3 (mp3). MovieTexture should allow extraction and playback of the audio layer from an MPEG movie. Recommended that MovieTexture also allow extraction and playblack of the audio layer from a QuickTime movie. AudioClip or MovieTexture required. The Sphere node's geometry defaults to outside faces only. When viewed from the inside, no faces are visible if the solid attribute is true (the default). When solid is false, both sides of the faces are drawn. The SpotLight node defines a light source that emits light from a specific point along a specific direction vector and constrained within a solid angle. Spotlights may illuminate geometry nodes that respond to light sources and intersect the solid angle defined by the SpotLight. Spotlight nodes are specified in the local coordinate system and are affected by ancestors' transformations. The location field specifies a translation offset of the center point of the light source from the light's local coordinate system origin. This point is the apex of the solid angle which bounds light emission from the given light source. The direction field specifies the direction vector of the light's central axis defined in the local coordinate system. The on field specifies whether the light source emits light. If on is true, the light source is emitting light and may illuminate geometry in the scene. If on is false, the light source does not emit light and does not illuminate any geometry. The radius field specifies the radial extent of the solid angle and the maximum distance from location that may be illuminated by the light source. The light source does not emit light outside this radius. The radius shall be greater than or equal to zero. Both radius and location are affected by ancestors' transformations (scales affect radius and transformations affect location). The cutOffAngle field specifies the outer bound of the solid angle. The light source does not emit light outside of this solid angle. The beamWidth field specifies an inner solid angle in which the light source emits light at uniform full intensity. The light source's emission intensity drops off from the inner solid angle (beamWidth) to the outer solid angle (cutOffAngle) as described in the following equations: angle = the angle between the Spotlight's direction vector and the vector from the Spotlight location to the point to be illuminated if (angle >= cutOffAngle): multiplier = 0 else if (angle >= beamWidth): multiplier = 1 else: multiplier = (angle - cutOffAngle) / (beamWidth - cutOffAngle) intensity(angle) = SpotLight.intensity × multiplier If the beamWidth is greater than the cutOffAngle, beamWidth is defined to be equal to the cutOffAngle and the light source emits full intensity within the entire solid angle defined by cutOffAngle. Both beamWidth and cutOffAngle shall be greater than 0.0 and less than or equal to PI/2. SpotLight illumination falls off with distance as specified by three attenuation coefficients. The attenuation factor is 1/max(attenuation[0] + attenuation[1]×r + attenuation[2]×r2 , 1) where r is the distance from the light to the surface being illuminated. The default is no attenuation. An attenuation value of (0, 0, 0) is identical to (1, 0, 0). Attenuation values shall be greater than or equal to zero. $figure04$ choice required. Contains an element of type groupingAndChildrenNodes which in turn may contain a Switch node. Will this be a problem? string required. When enabled, a TimeSensor will continuously, meaning as often as possible, output an event containing the current time as a float. System clock granularity will determine intervals between and values of output events. If the value of loop is true when a TimeSensor reaches the end of its duration, then that TimeSensor shall cycle back to its beginning state and restart. The value of duration specifies the (possibly fractional) number of seconds that a TimeSensor will generate output events. UNIX timeFormat is number of seconds since the beginning of 1 January 1970. WORLD timeFormat is number of seconds since World completed loading. RELATIVE timeFormat is number of seconds since TimeSensor was enabled. If TimeSensor was enabled when it was loaded, then RELATIVE and WORLD are effectively the same. children required. Allowed in groupingAndChildrenNodes. Also in Shape instead of an appearance, in Shape.appearance instead of a Material and/or a Texture, and in Shape.geometry instead of a Box or Cone or etc. element to be used must appear before Use statement. Application is responsible for insuring type is legal in that position. target attribute is required. target may NOT be an ancestor. name is required. The first Viewpoint encountered while loading an xVRML world shall become the default initial Viewpoint for the user. If no Viewpoint is located during the loading of an xVRML world, then the user Viewpoint shall default to a position at 0.0 on the X-axis and 0.0 on the Y-axis and +10.0 on the Z-axis. There are four basic combinations of Avatar and Viewpoint. No Avatar and no Viewpoint is specified in the file. In this case the initial user position in the World shall be a combination of the default Viewpoint position ("0.0 0.0 10.0") plus the default Avatar cameraOffset ("0.0 1.65 0.0"). This makes the default initial user position "0.0 1.65 10.0" and the default initial user rotation "0.0 0.0 1.0 0.0". An Avatar but no Viewpoint is specified in the file. In this case the initial user position in the World shall be a combination of the default Viewpoint position ("0.0 0.0 10.0") plus the cameraOffset of the first Avatar found loading the file. A Viewpoint but no Avatar is specified in the file. In this case the initial user position in the World shall be a combination of the Viewpoint position of the first Viewpoint found loading the file plus the default Avatar cameraOffset ("0.0 1.65 0.0"). Both an Avatar and a Viewpoint are specified in the file. In this case the initial user position in the World shall be a combination of the Viewpoint position of the first Viewpoint found loading the file plus the cameraOffset of the first Avatar found loading the file. For the purposes of navigation an application should do the following: (1) apply the current transform state of the enclosing hierarchy to the Viewpoint (2) apply the Viewpoint.position (3) apply the Avatar.cameraOffset (4) apply the Viewpoint.orientation. The sum of these transformations creates the final position and orientation against which all navigation (for example, due to user gestures) shall occur in the World. If inlined, discard title but retain info for copyright and etc. One to many integers in a row, each separated from the previous by whitespace. Negative numbers are allowed. One to many floats separated by whitespace. Negative numbers and scientific notation allowed. Fractional part is optional Two floats separated by whitespace. Negative numbers and scientific notation allowed. Fractional part is optional One to many groups of two floats separated by whitespace. Negative numbers and scientific notation allowed. Fractional part is optional Three floats separated by whitespace. Negative numbers and scientific notation allowed. Fractional part is optional One to many groups of three floats separated by whitespace. Negative numbers and scientific notation allowed. Fractional part is optional Four floats separated by whitespace. Negative numbers and scientific notation allowed. Fractional part is optional Need to modify pattern so minExclusive and maxExclusive work right. The first three values of a rotation specify a normalized rotation axis vector about which the rotation takes place. The fourth value specifies the amount of right-handed rotation about that axis in radians. Rotations are to be applied to the x-axis first, the y-axis second, and the z-axis last. One to many groups of four floats, all separated from the previous by whitespace. Negative numbers are allowed. Need to modify pattern so scientific notation is supported. Need to figure out how to modify pattern. minInclusive and maxInclusive should be made to work right. The first three values of each rotation specify a normalized rotation axis vector about which the rotation takes place. The fourth value specifies the amount of right-handed rotation about that axis in radians. Rotations are to be applied to the x-axis first, the y-axis second, and the z-axis last. Unlike the original VRML specifications. If you do not specify any color values then it will default to pure black (RGBA = 0.0 0.0 0.0 1.0). Unlike SFColor. If you do not specify any color values then it will default to pure white (RGBA = 1.0 1.0 1.0 1.0). One to many groups of four floats between 1.0 and 0.0, all separated from the previous by whitespace. Need to modify pattern so minExclusive and maxExclusive work right.