[Skip Navigation] [CSUSB] / [CNS] / [Comp Sci Dept] / [R J Botting] / [Samples] / vrml
[Index] [Contents] [Source Text] [About] [Notation] [Copyright] [Comment/Contact] [Search ]
Tue Sep 18 15:27:37 PDT 2007

Contents

    The Virtual Reality Modeling Language

      Introduction

        Note

         VRML developed in the 1990's as a way of encoding complex artificial three diemnsional worlds complete with vision and sound.

        It may be replaced by an XML based form called W3D (Web 3 dimensions) in the future.

        Official Specifications

        VRML Consortium home page [ home.html ]
      1. to find the new location;

        VRML Standards and Specifications [ Specifications ]

      2. to find a VRML document.

        Hint. if you are looking for an old or obsolete version of the VRML specification (e.g. VRML 2.0, VRML97 DIS, etc.), try putting ".old" at the end of the directory name. For example: .See http://www.vrml.org/Specifications/VRML2.0.old .

        Examples

        My Avatar [ me.wrl ]

        Air Hockey [ VRCS ]

        Leonard Daly's examples [ example.html ]

        Web3d.Guide's VRML Applications [ http://web3d.miningco.com/ ]

        Resources

        SGIs VRML resource page [ http://vrml.sgi.com/ ]

      . . . . . . . . . ( end of section Introduction) <<Contents | End>>

      UML Model

      The following is a downloadable Rational Rose 4.0 file describing many of the classes of objects and their associations [ vrml.mdl ]

      Syntax

        Source

         I based the Lexicon and Grammar on the syntax [ grammar.html ] written by rikk@best.com , cmarrin@sgi.com , and gavin@acm.org

        Disclaimer

        This VRML grammar is ambiguous; semantic knowledge of the names and types of fields, eventIns, and eventOuts for each node type (either builtIn or user-defined using PROTO or EXTERNPROTO) must be used to parse a VRML document correctly. See a specification of the various type of Nodes to find out the details.

        Lexicon

        The '#' (0x23) character begins a comment wherever it appears outside of quoted SFString or MFString fields. The '#' character and all characters until the next carriage-return or newline make up the comment and are treated as whitespace.

        The carriage return (0x0d), newline (0x0a), space (0x20), tab (0x09), and comma (0x2c) characters are whitespace characters wherever they appear outside of quoted SFString or MFString fields. Any number of whitespace characters and comments may be used to separate the syntactic entities of a VRML file.

        Some of the basic types that will typically be handled by a lexical analyzer:

      1. sfboolValue::="TRUE" | "FALSE".

      2. float::=sffloatValue.
      3. sffloatValue::lexeme=floating point number in ANSI C floating point format, [ c.syntax.html ]

      4. sfcolorValue::= float float float, the three floating point numbers must be in range 0..1 inclusive and indicate the amount of Red, Green, and Blue light making up the color -- see Colors.

      5. int32::=sfint32Value.
      6. sfint32Value::=N digit | "0x" N hexdigit.

      7. sfnodeValue::= "NULL" | nodeDeclaration. In many cases only certain types of node can be declared as nodeValue for a field in another node. In the definitions of the different kinds of nodes (Nodes below) I have attempted to indicate this explicitly.

      8. sfrotationValue::=float float float float. The first three values define an axis of rotation and the last float defines the rotation in radians. The Right-hand-grasp rule is used to determine the positive rotations: grasp the direction vector with your right hand and with its thumb in that directtion... your fingers are in the positive direction.

      9. sfstringValue::=quotes #( non(quotes|backslash) | backslash char ) quotes.
      10. mfstringValue::=mf(sfstringValue).

      11. sftimeValue::=double-precision number in ANSI C floating point format.

      12. sfvec2Value::=float float.
      13. sfvec3Value::=float float float. When used as a direction the coordinates are x,y,and z respectively. From the default viewers poit of view: Z points toward the viewer and Y is vertically up ward. X points to the viewers right.

      14. Id::=IdFirstChar # IdRestChars.

      15. IdFirstChar::=Any ISO-10646 character encoded using UTF-8 except: 0x30-0x39, 0x0-0x20, 0x22, 0x23, 0x27, 0x2c, 0x2e, 0x5b, 0x5c, 0x5d, 0x7b, 0x7d.

      16. IdRestChars::=Any number of ISO-10646 characters except: 0x0-0x20, 0x22, 0x23, 0x27, 0x2c, 0x2e, 0x5b, 0x5c, 0x5d, 0x7b, 0x7d.

      17. nodeNameId::@Id, declared in a nodeDeclaration. The following are either pre-defined or added by new PROTO nodes.
        1. nodeTypeId::@Id.
        2. fieldId::@Id.
        3. eventInId::@Id.
        4. eventOutId::@Id.
        5. exposedFieldId::@Id.
        The following are the kinds of access provided to fields in VRML:
        1. field::="field", indicates an attribute of a node that is essentially private.
        2. eventIn::="eventIn", indicates a value that can be sent to a node as a message.
        3. eventOut::="eventOut", indicates a value that comes from a node as a message.
        4. exposedField::="exposedField", indicates that a field can be changed and accessed by other nodes.
          1. For X: exposedFieldId, set_X ::= send message with new value for X.
          2. For X: exposedFieldId, X_value ::= get value of X.

        Grammar
      18. vrmlScene::= N(declaration).

      19. declaration::=nodeDeclaration | protoDeclaration | routeDeclaration | "NULL"

      20. nodeDeclaration::= node | "DEF" nodeNameId node | "USE" nodeNameId. DEF defines names for nodes. Use refers back to the names. Scope is within Groups.

      21. protoDeclaration::=proto | externproto. These two nodes actually create new types of nodes with name and fields.
      22. proto::="PROTO" nodeTypeId "[" N interfaceDeclaration "] "{" vrmlScene "}".
      23. externproto::= "EXTERNPROTO" nodeTypeId "[" N externInterfaceDeclaration"]" mfstringValue.

      24. restrictedInterfaceDeclaration::= eventIn fieldType eventInId | eventOut fieldType eventOutId | field fieldType fieldId fieldValue, used in scriptGut to define data used in scripts.

      25. interfaceDeclaration::=restrictedInterfaceDeclaration | exposedField fieldType fieldId fieldValue, used in proto as a Field_description.

      26. externInterfaceDeclaration::= eventIn fieldType eventInId | eventOut fieldType eventOutId | field fieldType fieldId | exposedField fieldType fieldId, used in externproto as a Field_description.

      27. routeDeclaration::= "ROUTE" nodeNameId "." eventOutId "TO" nodeNameId "." eventInId.

        Node Declaration

      28. node::= nodeTypeId "{" N nodeGut "}" | "Script" "{" N scriptGut "}".

      29. scriptGut::= nodeGut | restrictedInterfaceDeclaration | eventMapping.

      30. eventMapping::=eventIn fieldType eventInId "IS" eventInId | eventOut fieldType eventOutId "IS" eventOutId | field fieldType fieldId "IS" fieldId.

      31. nodeGut::= fieldId fieldValue | fieldId "IS" fieldId | eventInId "IS" eventInId | eventOutId "IS" eventOutId | routeDeclaration | protoDeclaration.

        Notation

        The following have been used to defined the syntax and are not part of the VRML itself.
      32. N::= (_) #(_).
      33. O::= ( | (_)).
      34. L::= (_) #( comma (_) ).
      35. Net::= indicates an abstract or mathematical data type with components and constraints.

      . . . . . . . . . ( end of section Syntax) <<Contents | End>>

      Fields

    1. data_type::=$ Net{ name:string, values:Sets }.
    2. data_types::@data_type=predefined_data_types | author_defined_data_types.
    3. fieldType::=name(data_types).
    4. fieldValue::=values(data_types).

      author_defined_types are generated by proto and externProto nodes.

    5. predefined_data_types::=terms defined in following,
      Net

        (SF):
      1. SFBool::=data_type with name="SFBool" and values=sfboolValue.
      2. SFColor::=data_type with name="SFColor" and values=sfcolorValue.
      3. SFFloat::=data_type with name="SFFloat" and values=sffloatValue.
      4. SFImage::=data_type with name="SFImage" and values=int32 int32 int32 #int32.
      5. SFInt32::=data_type with name="SFInt32" and values=sfint32Value.
      6. SFNode::=data_type with name="SFNode" and values=sfnodeValue.
      7. SFRotation::=data_type with name="SFRotation" and values=sfrotationValue.
      8. SFString::=data_type with name="SFString" and values=sfstringValue.
      9. SFTime::=data_type with name="SFTime" and values=sftimeValue.
      10. SFVec2f::=data_type with name="SFVec2f" and values=sfvec2Value.
      11. SFVec3f::=data_type with name="SFVec3f" and values=sfvec3Value.


        (MF):

      12. MFColor::=data_type with name="MFColor" and values=mf(sfcolorValue).
      13. MFFloat::=data_type with name="MFFloat" and values=mf(sffloatValue).
      14. MFInt32::=data_type with name="MFInt32" and values=mf(sfint32Value).
      15. MFNode::=data_type with name="MFNode" and values=mf(sfnodeValue).
      16. MFRotation::=data_type with name="MFRotation" and values=mf(sfrotationValue).
      17. MFString::=data_type with name="MFString" and values=mf(sfstringValue).
      18. MFVec2f::=data_type with name="MFVec2f" and values=mf(sfvec2Value).
      19. MFVec3f::=data_type with name="MFVec3f" and values=mf(sfvec3Value).

      (End of Net)

    6. singleValues::= { s:fieldType. s(1..2)="SF" }, see SF above.

    7. For X:singleValues, mf(X)::=X | "[ ]" | "[" L(X) "]", see MF above.

      Predefined Field Names

      There are many predefined field names:
    8. fieldId::@Id=programmer_defined | expression definitions following

      Predefined Events
    9. EventId::@Id=programmer_defined| expression definitions following

      Predefined Nodes

        This section of this document defines some semantic rules and so the context sensitive syntax of a VRML document. Every node declared in a VRML document can have the fields specified below. These fields must be of the right type. Here I describe each type of node by a list of possible field names, default values, types, and meaning. A node's field gets it's value from (1) the default value for the field, (2) from a value supplied in the node description. or (3) dynamically via and "eventIn" or "set_" method.
      1. Node::=$ Net{ name:NodeId, fields:@ Field_description}.
      2. Field_description::= $ Net{ access::Access, fieldname:FieldId, type: Type, default:optional_Value}.
      3. Access::= { exposedField, field, eventIn, eventOut }. The Access indicate the semantics of the field: Only exposedField and field have initial and default values. Events (eventIn and eventOut) have values that are generated internally and dynmaically.

      4. optional_Value::= Value | " ".
      5. Type::= (O("M") NodeId| fieldId ), -- the M indicates that one item, no items "[ ]", or a bracketed list of items are required.

        Geometrical Object

         Geometrical objects are used primarily in Shape nodes that combine the geometry of the object and its surface appearance.
      6. geometries::abstract= Box | Cone | Cylinder | Sphere | Text | PointSet | IndexedLineSet | IndexedFaceSet | ElevationGrid | Extrusion... .

        A Box for example is a rectangular parallelopiped with its center at the origin and a size determined by default or by its declaration. The VRML does not display a Box without making sure that the author has declared what it looks like - transparency, color, reflectivity, inner light, and so on.


        (morphing): Notice that it is possible for the geometry of a Shape to change, and yet the parameters defining a geometry (like the size of a Box) can not be changed. Morphing has to be done by changing the coordinates listed in the more flexible geometries: PointSet, IndexedLineSet, and IndexedFaceSet. The actually morphing is done by an Interpolator of the correct type.

        The geometries listed here are all positioned near the origin of the co-ordinate system and in a standard orientation and scale. They can not be transformed however. Instead the shapes that use them can be translated, rotated and scaled... and so positioned where the author wants them to be. This is because the appearances of the shape must also be transformed at the same time as its geometry.

      7. Box::Node with name="Box" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        fieldsizeSFVec3f2.0 2.0 2.0

      8. Sphere::Node with name="sphere" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        fieldradiusSFFloat2.0

      9. Cone::Node with name="Cone" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        fieldbottomRadiusSFfloat1.0
        fieldheightSFfloat2.0
        fieldsideSFBoolTRUE
        fieldbottomSFBoolTRUE

      10. Cylinder::Node with name="Cylinder" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        fieldradiusSFfloat1.0
        fieldheightSFfloat2.0
        fieldsideSFBoolTRUE
        fieldtopSFBoolTRUE
        fieldbottomSFBoolTRUE

      11. Text::=Node with name="Text" and fields = following
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldstringMFString[ ]
        exposedFieldlengthMFFloat[ ]
        exposedFieldmaxExtentSFFloat0.0
        exposedFieldfontStyleFontStyleNULL

      12. FontStyle::=Node with name="FontStyle" and fields = following
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        fieldfamily("SERIF"|"SANS"|"TYPEWRITER"}"SERIF"
        fieldstyle("PLAIN"|"BOLD"|"ITALIC"|"BOLDITALIC")"PLAIN"
        exposedFieldsizeSFFloat1.0
        exposedFieldspacingSFFloat1.0
        fieldjustify("BEGIN"|"FIRST"|"MIDDLE"|"END"}"BEGIN"
        fieldleftToRightSFFBool"TRUE"
        fieldhorizontalSFFBool"TRUE"
        fieldtopToBottomSFFBool"TRUE"
        fieldlanguagelanguage_value""
      13. language_value::@SFString= "ar" | "de" | "en" | "hi" | "jp" "ru" | "sa" | "sw" | "zh" | ...

      14. PointSet::=Node with name="PointSet" and fields = following
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldcoordCoordinateNULL
        exposedFieldcolorColorNULL
        A PointSet combines an array of coordinates and an array of colors. The default color is inherited from the material of the shape in which the pointset is declared. Note: No Collisions or textures for points. Also note that the coordinates and colors are dynamic.

      15. IndexedLineSet::=Node with name="IndexedLineSet" and fields = following
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldcoordCoordinateNULL
        fieldcoordIndexMFInt32[ ]
        eventInset_coordIndexMFInt32
        exposedFieldcolorColorNULL
        fieldcolorIndexMFInt32[ ]
        eventInset_colorIndexMFInt32
        fieldcolorPerVertexMFBoolTRUE
        The coordIndex array is a sequence of segments each made of a series of indexes of points, separated by a -1. The array can be described by:
      16. coord_index::=poly_line, -1, poly_line, -1, ... .
      17. poly_line::= L( indices_of_point_in_coord ). Each pair of indices defines a line in the poly_line.
      18. indices_of_point_in_coord::= 0..(number_points_in_coord-1).

        If colorPerVertex is FALSE then each color in the colorIndex describes the color of a polyline, else it describes the colors of the points and the colors are interpolated on the lines.

      19. L(X)::=list of X separated by commas.

        A faceted object has faces. IndexedFaceSet, ElevationGrid and fields = following, Extrusion are all faceted:

      20. faceted::=Node with fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        fieldccwMFBoolTRUE
        fieldconvexMFBoolTRUE
        fieldsolidMFBoolTRUE
        fieldcreaseAngleSFFloat0.0

        A surface is a faceted object where the shading varies from place to place. It is an abstraction shared by IndexedFaceSet and ElevationGrid:

      21. surface::abstract=faceted with shading.

      22. shading::abstract=Node with fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldnormalNormalNULL
        fieldnormalIndexMFInt32[ ]
        fieldnormalPerVertexMFBoolTRUE

      23. Normal::=Node with name="Normal" and fields = following
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldvectorMFVec3f[ ]
        Notice that the shading can be animated because vector of Normal is exposed and there is a NormalInterpolator.

      24. IndexedFaceSet::=IndexedLineSet and surface with name="IndexedFaceSet" and fields = following
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldtexCoordTextureCoordinateNULL
        fieldtexCoordIndexMFInt32[ ]
        eventInset_texCoordIndexMFInt32[ ]
        eventInset_normalIndexMFInt32
        The coordIndex array is a sequence of faces each made of a series of indexes of points, separated by a -1. The sequence can be described by:
      25. coord_index::=face, -1, face, -1, face, ....
      26. face::= L( indices_of_point_in_coord ).
      27. indices_of_point_in_coord::= 0..(number_points_in_coord-1). If colorPerVertex is FALSE then each color in the colorIndex describes the color of a face, else it describes the points in each face and the colors are interpolated on the surface.

      28. ElevationGrid::=surface with name="ElevationGrid" and fields = following
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        fieldxDimensionSFInt320
        fieldxSpacingSFFloat0.0
        fieldzDimensionSFInt320
        fieldzSpacingSFFloat0.0
        fieldheightMFFloat[ ]
        eventInset_heightMFFloat
        exposedFieldtexCoordTextureCoordinateNULL
        If colorPerVertex is FALSE then each color in the colorIndex describes the color of each square in the grid, else it describes the points in each grid square and the colors are interpolated on the surface.

      29. Extrusion::=faceted with name="Extrusion" and fields = following
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        fieldcrossSectionMFVec2fdefault_crosssection
        eventInset_crossSectionMFVec2f
        fieldspineMFVec3fdefault_spine
        eventInset_spineMFVec3f
        fieldscaleMFVec2f1.0 1.0
        eventInset_scaleMFVec2f
        fieldorientationMFRotation0.0 0.0 1.0 0.0
        eventInset_orientationMFRotation
        fieldbeginCapSFBoolTRUE
        fieldendCapSFBoolTRUE
      30. default_crosssection::MFVec2f= "[ 1.0 1.0, 1.0 -1.0, -1.0 -1.0, -1.0 1.0, 1.0 1.0]", a 2 unit square with origin at the center..
      31. default_spine::MFVec3f= "[ 0.0 0.0 0.0, 0.0 1.0 0.0 ]", a unit line point straight up (along the Y axes).

        Colors

        Colors in VRML are specified using the RGB(Red-Green-Blue) coding. [ colors.html ]

        A list of colors is described by a Color node. This is used in several ways: to describe the colors of faces or surfaces, to allow a range of colors to be mapped onto an object, to attach colors to points, to allow colors to change, etc.

      32. Color::=Node with name="Color" and fields = following
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldcolorMFColor[ ]
        The colors in the color array in a Color node can over-ride the diffuseColor specified in the Material Appearance of a shape.

        It is also possible to interpolate colors, see ColorInterpolator.

        Visual Properties of Objects

        These properties are used when defining geometries and Shapes. Also see Colors.

      33. Coordinate::=Node with name="Coordinate" and fields = following
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldpointMFVec3f[ ]
        Actually a dynamic array of points. Also see CoordinateInterpolator for morphing.

      34. Appearance::Node with name="Appearance" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldmaterialMaterialNULL
        exposedFieldtexturetextureNodeNULL
        exposedFieldtextureTransformtextureTransformNodeNULL

      35. Material::Node with name="Material" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFielddiffuseColorSFColor0.8 0.8 0.8
        exposedFieldemissiveColorSFColor0.0 0.0 0.0
        exposedFieldspecularColorSFColor0.0 0.0 0.0
        exposedFieldambientIntensitySFfloat0.2
        exposedFieldshininessSFfloat0.2
        exposedFieldtransparencySFFloat0.0

        Textures
      36. textures::abstract=Node with fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        fieldrepeatSSFBoolTRUE
        fieldrepeatTSFBoolTRUE
      37. ImageTexture::=textures with name="ImageTexture" and fields = following
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldurlMFString[ ]

      38. PixelTexture::=textures with name="PixelTexture" and fields = following
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldimageSFImage0 0 0
        An SFImage has at least three components: width, height, number_of_bytes. These are followed by the bytes that describe the texture:
      39. SFImage::=width height number_of_bytes #byte.

        if number_of_bytes = 0 then texturing is disabled else following
        number_of_bytesMeaning of each byte
        1Grayscale
        2Grayscale plus alpha
        3RGB
        4RGB plus alpha
        An alpha value indicates the transparency of the pixel.

      40. alpha::@hex^2= transparent..opaque.
      41. transparent::=0x00.
      42. opaque::=0xFF.
      43. RGB::= (hex^2)^3, see Colors.
      44. Grayscale::@hex^2= black..white. black:=0x00.
      45. white::=0xFF.

      46. MovieTexture::=textures and timing with name="MovieTexture" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldurlMFString[ ]
        exposedFieldspeedSFFloat1.0
        eventOutisActiveSFTIme
        eventOutduration_changedSFFloat
        Uses MPEG files, also see Sounds.

      47. TextureCoordinate::=Node with name="TextureCoordinate" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldpointMFVec3[ ]
        Used in IndexFaceSet and ElevationGrid to describe surfaces.

      48. TextureTransform::=Node with name="TextureTransform" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldtranslationSFVec2f0.0 0.0
        exposedFieldscaleSFVec2f0.0 0.0
        exposedFieldcenterSFVec2f0.0 0.0
        exposedFieldrotationSFVec2f0.0

        Shapes

      49. Shape::Node with name="Shape" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldappearanceAppearanceNULL
        exposedFieldgeometrygeometriesNULL

        Selections

        Switch chooses to display a choice to display.
      50. Switch::=Node with name="Switch" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldchoiceMFNode[ ]
        exposedFieldwhichChoiceSFInt32-1

        Grouping

        Certain nodes have a field called "children": Group, Transform, etc. Others have the property of being able to be bounded by a box.
      51. parental::abstract=Node with fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldchildrenM Node[ ]
        eventInaddChildrenM Node
        eventOutremoveChildrenM Node
        The above allows children of all types.... some parental nodes may only allow certain types of nodes. Notice that children can not be simple datatypes.

      52. bounded::abstract=Node with fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        fieldbboxCenterSFVec3f0.0 0.0 0.0
        fieldbboxSizeSFVec3f-1.0 -1.0 -1.0

        Grouping nodes share the both of the above properties:

      53. group::=parental & bounded.
      54. groups::=Group | BillBoard | Transform.

      55. Group::group with name="Group".

      56. BillBoard::=group with name="BillBoard" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldaxisOfRotationSVec3f0.0 1.0 0.0
        A BillBoard group does not rotate when the viewer rotates... or more precisely it remains in the user's face as they rotate round it.

      57. Inline::=bounded with name="Inline" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldurlMFString[ ]
        Allows a previously written file to be referred to. Modularity! Inlined files can included further inlined files. Notice the use of Universal Resource Locators to access worlds defined any where on the world wide web.

        Anchors and the WWW

        An Anchor group of nodes makes it easy to move from one world to a different one found on the WWW.
      58. Anchor::=group with name="Anchor" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldurlMFString[ ]
        exposedFieldparameterMFString[ ]
        exposedFielddescriptionSFString""
        A browser can automatically display an anchors description.

        Transformations
      59. Transform::=parental and bounded with name="Transform" with fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldtranslationSFVec3f0.0 0.0 0.0
        exposedFieldrotationSFRotation0.0 0.0 1.0 0.0
        exposedFieldscaleSFVec3f1.0 1.0 1.0
        exposedFieldscaleOrientationSFRotation0.0 0.0 1.0 0.0
        exposedFieldcenter"SFVec30.0 0.0 0.0

        Rotation uses the Right-Hand-Grasp-Rule: if your right hand grasps the vector (first three numbers) and its thumb points in the direction of the vector then its fingers point in the direction of a positive rotation. The center specifies the position about which the rotation occurs.

        Rotation and translation can be used together. The object is rotated and then translated

        Lighting

        By default a VRML world is provided with two forms of lighting: a head-light for the viewer and a degree of reflected "ambient" light. Other sources of light can be added easily but the shadows cast by objects from these light sources are not automatic. VRML interpreters treat each facet as it was all the same lighting so with special light sources it may be necessary to divide up a flat surface into a series of facets using an elevation grid or indexed face list. On the otherhand VRML has define the specularColor and shininess fields for a Material that describe like a mirror (speculum) a material is. Glowing objects contain a light sources and given a larger ambientIntensity.

      60. light_source::abstract=Node with fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldonSFBoolTRUE
        exposedFieldintensitySFFloat1.0
        exposedFieldambientIntensitySFFloat0.0
        exposedFieldcolorSFColor1.0 1.0 1.0

      61. PointLight::=light_source with fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldlocationSFVec30.0 0.0 0.0
        exposedFieldradiusSFFloat100.0
        exposedFieldattenuationSFVec3f1.0 0.0 0.0

      62. DirectionalLight::=light_source with fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFielddirectionSFVec30.0 0.0 -1.0

      63. SpotLight::=PointLight with fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldbeamWidthSFFloat1.570796
        exposedFieldcutOffAngleSFFloat0.785398

        Backgrounds

        It possible, by including a special Background node in a world to describe a standard sky and ground plus a backdrop or panorama. A new Background can be stacked on top the current one as part of an animation.
      64. Background::=bindable with name "Background" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldskyColorMFColor[ 0.0 0.0 0.0 ]
        exposedFieldskyAngleMFFloat[ ]
        exposedFieldgroundColorMFColor[ ]
        exposedFieldgroundAngleMFFloat[ ]
        exposedFieldbackUrlMFString[ ]
        exposedFieldfrontUrlMFString[ ]
        exposedFieldrightUrlMFString[ ]
        exposedFieldleftUrlMFString[ ]
        exposedFieldtopUrlMFString[ ]

        Fogs
      65. Fog::=bindable with name "Fog" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldcolorSFColor1.0 1.0 1.0
        exposedFieldvisibillityRangeSFFLoat0.0
        exposedFieldfogType"LINEAR" | "EXPONENTIAL""LINEAR"

        Bindings

         Fog and Background are both bindable Nodes. This means that they both accept set_bind inputs and generate bind_changed output events. There is a stack of each type of nodes...
      66. bindable::abstract=Node with fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        eventInset_bindSFBool
        eventOutbind_changeSFBool

        Sounds

         A VRML world can include sounds based on files that contain audio clips. These can be played as parts of animations or broadcast as if from an object in the world. As the viewer seems to move within range the sounds start to be heard. Further this allows the playback of "talkies" and the animation of sound sources. This increases the impact of the world on the viewer greatly.
      67. sound_source::= AudioClip | MovieTexture.

      68. Sound::=Node with name="Sound" and fields = following,
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldsourcesound_source[ ]
        exposedFieldintensitySFFloat1.0
        exposedFielddirectionSFVec30.0 0.0 1.0
        exposedFieldminFrontSFFloat1.0
        exposedFieldmaxFrontSFFloat10.0
        exposedFieldminBackSFFloat1.0
        exposedFieldmaxBackSFFloat10.0
        exposedFieldprioritySFFloat0.0
        fieldspatializeSFBoolTRUE

      69. AudioClip::=Node with name="AudioClip" and fields = following
        access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
        exposedFieldurlMFString[ ]
        duration""SFString
        exposedFieldstartTimeSFTime0.0
        exposedFieldstopTimeSFTime0.0
        exposedFieldcycleIntervalSFTime1.0
        exposedFieldloopSFBoolFALSE
        exposedFieldpitchSFFloat1.0
        eventOutisActiveSFBool
        eventOutduration_changedSFBool

        Movies can also contain synchronized sounds and VRML permits movies to supply textures to surfaces of objects... thus also making them play various sounds. The teture has to appear in two contexts: as a texture of an object and as a source in a Sound. The "DEF" and "USE" syntax handles this well. See MovieTexture.

        Animation

          A VRML world is a dynamic world. The objects can be animated. Events can change the shapes, positions, etc of different objects. The events can come from the user, timers, or any object with an eventout field.

          Sensors

           A sensor reacts to timing and use events and generates output events:
        1. sensors::= TimeSensor | TouchSensor | PlaneSensor | SphereSensor | CylinderCensor. All sensors share some common properties abstracted by sensor next:
        2. sensor::abstract=Node with following
          access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
          exposedFieldenabledSFBoolTRUE
          eventOutisActiveSFTIme

          Timing

           Timing in sensors and movies is described the same way:
        3. timing::abstract=Node with fields = following,
          access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
          exposedFieldstartTimeSFTime0.0
          exposedFieldstopTimeSFTime0.0
          exposedFieldcycleIntervalSFTime1.0
          exposedFieldloopSFBoolFALSE
        4. TimeSensor::=sensor and timing with name="TimeSensor" and fields = following
          access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
          eventOuttimeSFTime
          eventOutcycleTimeSFTime
          eventOutfraction_changedSFTime
          The fraction_changed is commonly routed to one or more an interpolator nodes (below) as it varies from 0 to 1. Standard Effects
          loopConditionEffect
          TRUEstopTime<=startTime Runs forever
          TRUEstartTime<stopTimeRun until stopTime
          FALSEstopTime<=startTime Run for one cycle at startTime+cycleInterval
          FALSEstrtTime<startTime+cycleInterval<=stopTimeRun for one cycle at startTime+cycleInterval
          FalsestartTime<stopTime<startTime+cycleIntervalRun for less than one cycle then stop at stopTime.

          Sensing the User
        5. TouchSensor::=sensor with name="TouchSensor" and fields = following
          access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
          eventOutisOverSFBool
          eventOuttouchTimeSFTime
          eventOuthitPoint_changedDFVec3f
          eventOuthitNormal_changedDFVec3f
          eventOuthitTexCoord_changedDFVec3f

        6. ProximitySensor::=sensor with fields = following,
          access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
          exposedField centerSFVec3f0.0 0.0 0.0
          exposedField sizeSFVec3f0.0 0.0 0.0
          eventOutenterTimeSFTime
          eventOutexitTimeSFTime
          eventOutposition_changedSFVec3f
          eventOutorientation_changedSFSFRotation
          Note. A large proximitySensor can be used to track where the viewer is.

        7. Collision::=parental and bounded and fields=following,
          access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
          exposedField collideSFBoolTRUE
          fieldproxySFNodeNULL
          eventOutcollideTimeSFTime

        8. geometric_sensors::=PlaneSensor | SphereSensor.
        9. geometric_sensor::abstract=Node with fields = following,
          access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
          exposedFieldautoOffsetSFBoolTRUE
          exposedFieldoffsetSFVec3f0.0 0.0 0.0
          exposedFieldmaxPositionSFVec3f-1.0 -1.0
          exposedFieldminPositionSFVec3f0.0 0.0
          eventOuttrackPoint_changedSFVec3f

        10. PlaneSensor::=geometric_sensor with name="PlanSensor" and fields = following
          access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
          eventOuttranslation_changedSFVec3f

        11. SphereSensor::=geometric_sensor with name="SphereSensor" and fields = following
          access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
          eventOutrotation_changedSFRotation

        12. CylinderSensor::=sensor with name="CylinderSensor" and fields = following
          access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
          exposedFieldautoOffsetSFBoolTRUE
          exposedFieldoffsetSFFloat0.0
          exposedFieldmaxAngleSFFloat-1.0
          exposedFieldminAngleSFFloat0.0
          eventOuttrackPoint_changedSFVec3f
          eventOutrotation_changedSFRotation

          Interpolators

          Movement is smoothed by the use of Interpolators that have lists of times and values. When they receive a number (a float eventIn called set_fraction that varies) between 0 and 1. They output (via an eventout) a position, rotation, color or some other field value. They have a table of keys and a table of keyValues. If the input float is a key then the corresponding keyValue is output. If the input value is not in the table the work out a suitable intermediate value. They can output positions, rotations, colors, scales, and co-ordinates. The following describes an abstract and generic interpolator that is not implemented in VRML but describes the shared properties of all the different interpolators that have been implemented:
        13. For Type T, interpolator(T)::abstract=Node with fields = following,
          access:Accessfieldname:FieldIdtype:Typedefault:optional_Value
          exposedFieldkeyMFFloat[ ]
          exposedFieldkeyValueT[ ]
          eventInset_fractionSFFloat
          eventOutvalue_changedT
        14. PositionInterpolator::=interpolator(SFVec3) with name="PositionInterpolator". PositionInterpolators are used to set_translation and set_scale in a Transform node.

        15. OrientationInterpolator::=interpolator(SFRotation) with name="OrientationInterpolator". OrientationInterpolators are used to set_rotation in a Transform node.

        16. ColorInterpolator::=interpolator(SFColor) with name="ColorInterpolator", -- uses HSV color space to fill in missing colors.

        17. ScalarInterpolator::=interpolator(SFFloat) with name="ScalarInterpolator".

        18. CoordinateInterpolator::=interpolator(MFVec3f) with name="CoordinateInterpolator", interpolates whole arrays of points at one time. The output should be routed to a Coordinate.set_point. The array of keyValues must be a series of coordinate point lists, one for each key:
        19. coordinate_key_values::= L(coordinate_point_list).
        20. coordinate_point_list::= L(MFVec3f).

        21. NormalInterpolator::= interpolator(MFVec3f) with name="NormalInterpolator", used to animate shading on surfaces.

        . . . . . . . . . ( end of section Animation) <<Contents | End>>

      . . . . . . . . . ( end of section Predefined Nodes) <<Contents | End>>

      Things left out

        Scripts

        It is possible to embed either Javascript or Java programs inside a node in a VRML world. In theory other languages might be used as well but none are standardized as yet. A Script node must have an url field. Often however this will have a "javascript:" protocol and so allow the script to be embedded in the node itself. The Script can also declare a number of fields, eventIns, and eventOuts that act as an interface between the VRML world and the variables in the script. See the syntax Script. The interface also described a new type of node along with its events and fields.

        See also

      1. Java::= See http://www.csci.csusb.edu/dick/samples/java.html.
      2. Javascript::= See http://www.csci.csusb.edu/dick/samples/javascript.html.

        Creating new types of Node

        The PROTO and EXTERNPROTO nodes define whole new classes of node -- complete with public and private parts. The verb "IS" is used to connect fields and interface items.

        Details.... later.

        Level Of Detail

      3. LOD::=Node with name "LOD" ..., allows world maker to provide alternate forms of an object depending how close the viewer is to it.

        WorldInfo

         The world builder can include a node that gives the world a title and other information that can be used and displayed by a browser.

        The Viewer

          Viewpoints

           A VRML world can have a number of predefined viewpoints and allow the user to move quickly from one to another. They are bindable and include a position, orientation, fiedlOfView field. They can even be part of another moving object -- for example in a game where the viewer is in an elevator and looking out at the world.

          Visibility Sensors

           There is a special sensor that detects when the viewer can see an object:
        1. VisibilitySensor

          Avatars

          The NavigationInfo Node permits the world designer to describe how the viewer appears to other viewers in the same world.

          Navigation

           It is possible to restrict how the viewer can move using a NavigationInfo Node.

        . . . . . . . . . ( end of section The Viewer) <<Contents | End>>

        Semantics

        Each node describes an object in a class of objects. In terms of the MATHS model the objects described by a node with fields F belong to a set of structured objects $ N with fields based on F, where
      4. declarations(N) = { (f.name, f.type). for some f:F}.

        The default object is similar but is a set of objects $ I with only has the fields and exposed fields of the node defined:

      5. definitions(I) = { (f.name, f.type, f.default). for some f:F(f.access = "field" or f.access = "exposedField" ) }.

        The actual object at any time has values taken from the default object, overridden and extended by the values supplie in the node declaration, and updated by the last values to arrive as eventIns.

      . . . . . . . . . ( end of section Things left out) <<Contents | End>>

      Abstractions

      A number of names for classes of nodes have been created to simplify this description and make it a little more meaningful. Terms such as parental, group, sensor, and so on are not part of the VRML syntax but used to explain the VRML. I've tagged the definitions of these terms:
    10. abstract::= a class of node types that share a common property but are not named in the VRM syntax.

      Glossary

    11. XML::= See http://www.csci.csusb.edu/dick/samples/xml.html

    . . . . . . . . . ( end of section The Virtual Reality Modeling Language) <<Contents | End>>

End