home *** CD-ROM | disk | FTP | other *** search
/ Collection of Hack-Phreak Scene Programs / cleanhpvac.zip / cleanhpvac / FAQSYS18.ZIP / FAQS.DAT / VRML~1.SPE < prev    next >
Text File  |  1996-08-18  |  64KB  |  1,560 lines
  1. [VRML]
  2.  
  3. The Virtual Reality Modeling Language
  4.  
  5.    Version 1.0 Specification
  6.  
  7. 26-MAY-95
  8.  
  9.      Gavin Bell, Silicon Graphics, Inc.
  10.      Anthony Parisi, Intervista Software
  11.      Mark Pesce, VRML List Moderator
  12.  
  13. -------------------------------------------------------------------------------
  14.  
  15. Acknowledgements
  16.  
  17.      I want to thank three people who have been absolutely instrumental in
  18.      the design process: Brian Behlendorf, whose drive (and disk space)
  19.      made this process happen; and Tony Parisi and Gavin Bell, the final
  20.      authors of this specification, who have put in a great deal of design
  21.      work, ensuring that we have a satisfactory product. My hat goes off
  22.      to all of them, and to all of you who have made this process a
  23.      success.
  24.  
  25. Mark Pesce
  26.  
  27.      I would like to add a personal note of thanks to Jan Hardenbergh of
  28.      Oki Advanced Products for his diligent efforts to keep the
  29.      specification process on track, and his invaluable editing
  30.      assistance. I would also like to acknowledge Chris Marrin of Silicon
  31.      Graphics for his timely contributions to the final design.
  32.  
  33. Tony Parisi
  34.  
  35. Revision History
  36.  
  37.    * First Draft - November 2, 1994
  38.    * Second Draft - May 8, 1995
  39.    * Third Draft - May 26, 1995
  40.  
  41. Table of Contents
  42.  
  43.    *  Introduction
  44.  
  45.         o  VRML Mission Statement
  46.         o  History
  47.         o  Version 1.0 Requirements
  48.  
  49.    *  Language Specification
  50.  
  51.         o  Language Basics
  52.         o  Coordinate System
  53.         o  Fields
  54.         o  Nodes
  55.         o  Instancing
  56.         o  Extensibility
  57.         o  An Example
  58.  
  59.    *  Browser Considerations
  60.  
  61.         o  File Extensions
  62.         o  MIME Types
  63.  
  64. -------------------------------------------------------------------------------
  65.  
  66.    Introduction
  67.  
  68. The Virtual Reality Modeling Language (VRML) is a language for describing
  69. multi-participant interactive simulations -- virtual worlds networked via the
  70. global Internet and hyperlinked with the World Wide Web. All aspects of virtual
  71. world display, interaction and internetworking can be specified using VRML. It
  72. is the intention of its designers that VRML become the standard language for
  73. interactive simulation within the World Wide Web.
  74.  
  75. The first version of VRML allows for the creation of virtual worlds with
  76. limited interactive behavior. These worlds can contain objects which have
  77. hyperlinks to other worlds, HTML documents or other valid MIME types. When the
  78. user selects an object with a hyperlink, the appropriate MIME viewer is
  79. launched. When the user selects a link to a VRML document from within a
  80. correctly configured WWW browser, a VRML viewer is launched. Thus VRML viewers
  81. are the perfect companion applications to standard WWW browsers for navigating
  82. and visualizing the Web. Future versions of VRML will allow for richer
  83. behaviors, including animations, motion physics and real-time multi-user
  84. interaction.
  85.  
  86. This document specifies the features and syntax of Version 1.0 of VRML.
  87.  
  88.    VRML Mission Statement
  89.  
  90. The history of the development of the Internet has had three distinct phases;
  91. first, the development of the TCP/IP infrastructure which allowed documents and
  92. data to be stored in a proximally independent way; that is, Internet provided a
  93. layer of abstraction between data sets and the hosts which manipulated them.
  94. While this abstraction was useful, it was also confusing; without any clear
  95. sense of "what went where", access to Internet was restricted to the class of
  96. sysops/net surfers who could maintain internal cognitive maps of the data
  97. space.
  98.  
  99. Next, Tim Berners-Lee's work at CERN, where he developed the hypermedia system
  100. known as World Wide Web, added another layer of abstraction to the existing
  101. structure. This abstraction provided an "addressing" scheme, a unique
  102. identifier (the Universal Resource Locator), which could tell anyone "where to
  103. go and how to get there" for any piece of data within the Web. While useful, it
  104. lacked dimensionality; there's no there there within the web, and the only type
  105. of navigation permissible (other than surfing) is by direct reference. In other
  106. words, I can only tell you how to get to the VRML Forum home page by saying,
  107. "http://www.wired.com/", which is not human-centered data. In fact, I need to
  108. make an effort to remember it at all. So, while the World Wide Web provides a
  109. retrieval mechanism to complement the existing storage mechanism, it leaves a
  110. lot to be desired, particularly for human beings.
  111.  
  112. Finally, we move to "perceptualized" Internetworks, where the data has been
  113. sensualized, that is, rendered sensually. If something is represented
  114. sensually, it is possible to make sense of it. VRML is an attempt (how
  115. successful, only time and effort will tell) to place humans at the center of
  116. the Internet, ordering its universe to our whims. In order to do that, the most
  117. important single element is a standard that defines the particularities of
  118. perception. Virtual Reality Modeling Language is that standard, designed to be
  119. a universal description language for multi-participant simulations.
  120.  
  121. These three phases, storage, retrieval, and perceptualization are analogous to
  122. the human process of consciousness, as expressed in terms of semantics and
  123. cognitive science. Events occur and are recorded (memory); inferences are drawn
  124. from memory (associations), and from sets of related events, maps of the
  125. universe are created (cognitive perception). What is important to remember is
  126. that the map is not the territory, and we should avoid becoming trapped in any
  127. single representation or world-view. Although we need to design to avoid
  128. disorientation, we should always push the envelope in the kinds of experience
  129. we can bring into manifestation!
  130.  
  131. This document is the living proof of the success of a process that was
  132. committed to being open and flexible, responsive to the needs of a growing Web
  133. community. Rather than re-invent the wheel, we have adapted an existing
  134. specification (Open Inventor) as the basis from which our own work can grow,
  135. saving years of design work and perhaps many mistakes. Now our real work can
  136. begin; that of rendering our noospheric space.
  137.  
  138.    History
  139.  
  140. VRML was conceived in the spring of 1994 at the first annual World Wide Web
  141. Conference in Geneva, Switzerland. Tim Berners-Lee and Dave Raggett organized a
  142. Birds-of-a-Feather (BOF) session to discuss Virtual Reality interfaces to the
  143. World Wide Web. Several BOF attendees described projects already underway to
  144. build three dimensional graphical visualization tools which interoperate with
  145. the Web. Attendees agreed on the need for these tools to have a common language
  146. for specifying 3D scene description and WWW hyperlinks -- an analog of HTML for
  147. virtual reality. The term Virtual Reality Markup Language (VRML) was coined,
  148. and the group resolved to begin specification work after the conference. The
  149. word 'Markup' was later changed to 'Modeling' to reflect the graphical nature
  150. of VRML.
  151.  
  152. Shortly after the Geneva BOF session, the www-vrml mailing list was created to
  153. discuss the development of a specification for the first version of VRML. The
  154. response to the list invitation was overwhelming: within a week, there were
  155. over a thousand members. After an initial settling-in period, list moderator
  156. Mark Pesce of Labyrinth Group announced his intention to have a draft version
  157. of the specification ready by the WWW Fall 1994 conference, a mere five months
  158. away. There was general agreement on the list that, while this schedule was
  159. aggressive, it was achievable provided that the requirements for the first
  160. version were not too ambitious and that VRML could be adapted from an existing
  161. solution. The list quickly agreed upon a set of requirements for the first
  162. version, and began a search for technologies which could be adapted to fit the
  163. needs of VRML.
  164.  
  165. The search for existing technologies turned up a several worthwhile candidates.
  166. After much deliberation the list came to a consensus: the Open Inventor ASCII
  167. File Format from Silicon Graphics, Inc. The Inventor File Format supports
  168. complete descriptions of 3D scenes with polygonally rendered objects, lighting,
  169. materials, ambient properties and realism effects. A subset of the Inventor
  170. File Format, with extensions to support networking, forms the basis of VRML.
  171. Gavin Bell of Silicon Graphics has adapted the Inventor File Format for VRML,
  172. with design input from the mailing list. SGI has publicly stated that the file
  173. format is available for use in the open market, and have contributed a file
  174. format parser into the public domain to bootstrap VRML viewer development.
  175.  
  176.    Version 1.0 Requirements
  177.  
  178. VRML 1.0 is designed to meet the following requirements:
  179.  
  180.    *  Platform independence
  181.    *  Extensibility
  182.    *  Ability to work well over low-bandwidth connections
  183.  
  184. As with HTML, the above are absolute requirements for a network language
  185. standard; they should need little explanation here.
  186.  
  187. Early on the designers decided that VRML would not be an extension to HTML.
  188. HTML is designed for text, not graphics. Also, VRML requires even more finely
  189. tuned network optimizations than HTML; it is expected that a typical VRML scene
  190. will be composed of many more "inline" objects and served up by many more
  191. servers than a typical HTML document. Moreover, HTML is an accepted standard,
  192. with existing implementations that depend on it. To impede the HTML design
  193. process with VRML issues and constrain the VRML design process with HTML
  194. compatibility concerns would be to do both languages a disservice. As a network
  195. language, VRML will succeed or fail independent of HTML.
  196.  
  197. It was also decided that, except for the hyperlinking feature, the first
  198. version of VRML would not support interactive behaviors. This was a practical
  199. decision intended to streamline design and implementation. Design of a language
  200. for describing interactive behaviors is a big job, especially when the language
  201. needs to express behaviors of objects communicating on a network. Such
  202. languages do exist; if we had chosen one of them, we would have risked getting
  203. into a "language war." People don't get excited about the syntax of a language
  204. for describing polygonal objects; people get very excited about the syntax of
  205. real languages for writing programs. Religious wars can extend the design
  206. process by months or years. In addition, networked inter-object operation
  207. requires brokering services such as those provided by CORBA or OLE, services
  208. which don't exist yet within WWW; we would have had to invent them. Finally, by
  209. keeping behaviors out of Version 1, we have made it a much smaller task to
  210. implement a viewer. We acknowledge that support for arbitrary interactive
  211. behaviors is critical to the long-term success of VRML; they will be included
  212. in Version 2.
  213.  
  214. -------------------------------------------------------------------------------
  215.  
  216.    Language Specification
  217.  
  218. The language specification is divided into the following sections:
  219.  
  220.    *  Language Basics
  221.    *  Coordinate System
  222.    *  Fields
  223.    *  Nodes
  224.    *  Instancing
  225.    *  Extensibility
  226.    *  An Example
  227.  
  228.    Language Basics
  229.  
  230. At the highest level of abstraction, VRML is just a way for objects to read and
  231. write themselves. Theoretically, the objects can contain anything -- 3D
  232. geometry, MIDI data, JPEG images, anything. VRML defines a set of objects
  233. useful for doing 3D graphics. These objects are called Nodes.
  234.  
  235. Nodes are arranged in hierarchical structures called scene graphs. Scene graphs
  236. are more than just a collection of nodes; the scene graph defines an ordering
  237. for the nodes. The scene graph has a notion of state -- nodes earlier in the
  238. scene can affect nodes that appear later in the scene. For example, a Rotation
  239. or Material node will affect the nodes after it in the scene. A mechanism is
  240. defined to limit the effects of properties (separator nodes), allowing parts of
  241. the scene graph to be functionally isolated from other parts.
  242.  
  243. A node has the following characteristics:
  244.  
  245.    *  What kind of object it is. A node might be a cube, a sphere, a texture
  246.      map, a transformation, etc.
  247.  
  248.    *  The parameters that distinguish this node from other nodes of the same
  249.      type. For example, each Sphere node might have a different radius, and
  250.      different texture maps nodes will certainly contain different images to
  251.      use as the texture maps. These parameters are called Fields. A node can
  252.      have 0 or more fields.
  253.  
  254.    *  A name to identify this node. Being able to name nodes and refer to them
  255.      elsewhere is very powerful; it allows a scene's author to give hints to
  256.      applications using the scene about what is in the scene, and creates
  257.      possibilities for very powerful scripting extensions. Nodes do not have to
  258.      be named, but if they are named, they can have only one name. However,
  259.      names do not have to be unique-- several different nodes may be given the
  260.      same name.
  261.  
  262.    *  Child nodes. Object hierarchy is implemented by allowing some types of
  263.      nodes to contain other nodes. Parent nodes traverse their children in
  264.      order during rendering. Nodes that may have children are referred to as
  265.      group nodes. Group nodes can have zero or more children.
  266.  
  267. The syntax chosen to represent these pieces of information is straightforward:
  268.  
  269. DEF objectname objecttype { fields  children }
  270.  
  271. Only the object type and curly braces are required; nodes may or may not have a
  272. name, fields, and children.
  273.  
  274. Node names must not begin with a digit, and must not contain spaces or control
  275. characters, single or double quote characters, backslashes, curly braces, the
  276. plus character or the period character.
  277.  
  278. For example, this file contains a simple scene defining a view of a red cone
  279. and a blue sphere, lit by a directional light:
  280.  
  281. #VRML V1.0 ascii
  282. Separator {
  283.     DirectionalLight {
  284.         direction 0 0 -1  # Light shining from viewer into scene
  285.     }
  286.     PerspectiveCamera {
  287.         position    -8.6 2.1 5.6
  288.         orientation -0.1352 -0.9831 -0.1233  1.1417
  289.         focalDistance       10.84
  290.     }
  291.     Separator {   # The red sphere
  292.         Material {
  293.             diffuseColor 1 0 0   # Red
  294.         }
  295.         Translation { translation 3 0 1 }
  296.         Sphere { radius 2.3 }
  297.     }
  298.     Separator {  # The blue cube
  299.         Material {
  300.             diffuseColor 0 0 1  # Blue
  301.         }
  302.         Transform {
  303.             translation -2.4 .2 1
  304.             rotation 0 1 1  .9
  305.         }
  306.         Cube {}
  307.     }
  308.  
  309.  
  310. General Syntax
  311.  
  312. For easy identification of VRML files, every VRML file must begin with the
  313. characters:
  314.  
  315. #VRML V1.0 ascii
  316.  
  317. Any characters after these on the same line are ignored. The line is terminated
  318. by either the ASCII newline or carriage-return characters.
  319.  
  320. The '#' character begins a comment; all characters until the next newline or
  321. carriage return are ignored. The only exception to this is within string
  322. fields, where the '#' character will be part of the string.
  323.  
  324. Note: Comments and whitespace may not be preserved; in particular, a VRML
  325. document server may strip comments and extraneous whitespace from a VRML file
  326. before transmitting it. Info nodes should be used for persistent information
  327. like copyrights or author information. Info nodes could also be used for object
  328. descriptions.
  329.  
  330. Blanks, tabs, newlines and carriage returns are whitespace characters wherever
  331. they appear outside of string fields. One or more whitespace characters
  332. separates the syntactical entities in VRML files, where necessary.
  333.  
  334. After the required header, a VRML file contains exactly one VRML node. That
  335. node may of course be a group node, containing any number of other nodes.
  336.  
  337.    Coordinate System
  338.  
  339. VRML uses a cartesian, right-handed, 3-dimensional coordinate system. By
  340. default, objects are projected onto a 2-dimensional device by projecting them
  341. in the direction of the positive Z axis, with the positive X axis to the right
  342. and the positive Y axis up. A camera or modeling transformation may be used to
  343. alter this default projection.
  344.  
  345. The standard unit for lengths and distances specified is meters. The standard
  346. unit for angles is radians.
  347.  
  348.    Fields
  349.  
  350. There are two general classes of fields; fields that contain a single value
  351. (where a value may be a single number, a vector, or even an image), and fields
  352. that contain multiple values. Single-valued fields all have names that begin
  353. with "SF", multiple-valued fields have names that begin with "MF". Each field
  354. type defines the format for the values it writes.
  355.  
  356. Multiple-valued fields are written as a series of values separated by commas,
  357. all enclosed in square brackets. If the field has zero values then only the
  358. square brackets ("[]") are written. The last may optionally be followed by a
  359. comma. If the field has exactly one value, the brackets may be omitted and just
  360. the value written. For example, all of the following are valid for a
  361. multiple-valued field containing the single integer value 1:
  362.  
  363.  
  364. [1,]
  365. [ 1 ]
  366.  
  367. SFBitMask
  368.  
  369. A single-value field that contains a mask of bit flags. Nodes that use this
  370. field class define mnemonic names for the bit flags. SFBitMasks are written to
  371. file as one or more mnemonic enumerated type names, in this format:
  372.  
  373. ( flag1 | flag2 | ... )
  374.  
  375. If only one flag is used in a mask, the parentheses are optional. These names
  376. differ among uses of this field in various node classes.
  377.  
  378. SFBool
  379.  
  380. A field containing a single boolean (true or false) value. SFBools may be
  381. written as 0 (representing FALSE), 1, TRUE, or FALSE.
  382.  
  383. SFColor
  384.  
  385. A single-value field containing a color. SFColors are written to file as an RGB
  386. triple of floating point numbers in standard scientific notation, in the range
  387. 0.0 to 1.0.
  388.  
  389. SFEnum
  390.  
  391. A single-value field that contains an enumerated type value. Nodes that use
  392. this field class define mnemonic names for the values. SFEnums are written to
  393. file as a mnemonic enumerated type name. The name differs among uses of this
  394. field in various node classes.
  395.  
  396. SFFloat
  397.  
  398. A field that contains one single-precision floating point number. SFFloats are
  399. written to file in standard scientific notation.
  400.  
  401. SFImage
  402.  
  403. A field that contain an uncompressed 2-dimensional color or greyscale image.
  404.  
  405. SFImages are written to file as three integers representing the width, height
  406. and number of components in the image, followed by width*height hexadecimal
  407. values representing the pixels in the image, separated by whitespace. A
  408. one-component image will have one-byte hexadecimal values representing the
  409. intensity of the image. For example, 0xFF is full intensity, 0x00 is no
  410. intensity. A two-component image puts the intensity in the first (high) byte
  411. and the transparency in the second (low) byte. Pixels in a three-component
  412. image have the red component in the first (high) byte, followed by the green
  413. and blue components (so 0xFF0000 is red). Four-component images put the
  414. transparency byte after red/green/blue (so 0x0000FF80 is semi-transparent
  415. blue). A value of 1.0 is completely transparent, 0.0 is completely opaque.
  416. Note: each pixel is actually read as a single unsigned number, so a 3-component
  417. pixel with value "0x0000FF" can also be written as "0xFF" or "255" (decimal).
  418. Pixels are specified from left to right, bottom to top. The first hexadecimal
  419. value is the lower left pixel of the image, and the last value is the upper
  420. right pixel.
  421.  
  422. For example,
  423.  
  424. 1 2 1 0xFF 0x00
  425.  
  426. is a 1 pixel wide by 2 pixel high greyscale image, with the bottom pixel white
  427. and the top pixel black. And:
  428.  
  429. 2 4 3 0xFF0000 0xFF00 0 0 0 0 0xFFFFFF 0xFFFF00
  430.  
  431. is a 2 pixel wide by 4 pixel high RGB image, with the bottom left pixel red,
  432. the bottom right pixel green, the two middle rows of pixels black, the top left
  433. pixel white, and the top right pixel yellow.
  434.  
  435. SFLong
  436.  
  437. A field containing a single long (32-bit) integer. SFLongs are written to file
  438. as an integer in decimal, hexadecimal (beginning with '0x') or octal (beginning
  439. with '0') format.
  440.  
  441. SFMatrix
  442.  
  443. A field containing a transformation matrix. SFMatrices are written to file in
  444. row-major order as 16 floating point numbers separated by whitespace. For
  445. example, a matrix expressing a translation of 7.3 units along the X axis is
  446. written as:
  447.  
  448. 1 0 0 0  0 1 0 0  0 0 1 0  7.3 0 0 1
  449.  
  450. SFRotation
  451.  
  452. A field containing an arbitrary rotation. SFRotations are written to file as
  453. four floating point values separated by whitespace. The 4 values represent an
  454. axis of rotation followed by the amount of right-handed rotation about that
  455. axis, in radians. For example, a 180 degree rotation about the Y axis is:
  456.  
  457. 0 1 0  3.14159265
  458.  
  459. SFString
  460.  
  461. A field containing an ASCII string (sequence of characters). SFStrings are
  462. written to file as a sequence of ASCII characters in double quotes (optional if
  463. the string doesn't contain any whitespace). Any characters (including newlines)
  464. may appear within the quotes. To include a double quote character within the
  465. string, precede it with a backslash. For example:
  466.  
  467. Testing
  468. "One, Two, Three"
  469. "He said, \"Immel did it!\""
  470.  
  471. are all valid strings.
  472.  
  473. SFVec2f
  474.  
  475. Field containing a two-dimensional vector. SFVec2fs are written to file as a
  476. pair of floating point values separated by whitespace.
  477.  
  478. SFVec3f
  479.  
  480. Field containing a three-dimensional vector. SFVec3fs are written to file as
  481. three floating point values separated by whitespace.
  482.  
  483. MFColor
  484.  
  485. A multiple-value field that contains any number of RGB colors. MFColors are
  486. written to file as one or more RGB triples of floating point numbers in
  487. standard scientific notation. When more than one value is present, all of the
  488. values must be enclosed in square brackets and separated by commas. For
  489. example:
  490.  
  491. [ 1.0 0.0 0.0, 0 1 0, 0 0 1 ]
  492.  
  493. represents the three colors red, green, and blue.
  494.  
  495. MFLong
  496.  
  497. A multiple-value field that contains any number of long (32-bit) integers.
  498. MFLongs are written to file as one or more integer values, in decimal,
  499. hexadecimal or octal format. When more than one value is present, all the
  500. values are enclosed in square brackets and separated by commas; for example:
  501.  
  502. [ 17, -0xE20, -518820 ]
  503.  
  504. MFVec2f
  505.  
  506. A multiple-value field that contains any number of two-dimensional vectors.
  507. MFVec2fs are written to file as one or more pairs of floating point values
  508. separated by whitespace. When more than one value is present, all of the values
  509. are enclosed in square brackets and separated by commas; for example:
  510.  
  511. [ 0 0, 1.2 3.4, 98.6 -4e1 ]
  512.  
  513. MFVec3f
  514.  
  515. A multiple-value field that contains any number of three-dimensional vectors.
  516. MFVec3fs are written to file as one or more triples of floating point values
  517. separated by whitespace. When more than one value is present, all of the values
  518. are enclosed in square brackets and separated by commas; for example:
  519.  
  520. [ 0 0 0, 1.2 3.4 5.6, 98.6 -4e1 212 ]
  521.  
  522.    Nodes
  523.  
  524. VRML defines several different classes of nodes. Most of the nodes can be
  525. classified into one of three categories; shape, property or group. Shape nodes
  526. define the geometry in the scene. Conceptually, they are the only nodes that
  527. draw anything. Property nodes affect the way shapes are drawn. And grouping
  528. nodes gather other nodes together, allowing collections of nodes to be treated
  529. as a single object. Some group nodes also control whether or not their children
  530. are drawn.
  531.  
  532. Nodes may contain zero or more fields. Each node type defines the type, name,
  533. and default value for each of its fields. The default value for the field is
  534. used if a value for the field is not specified in the VRML file. The order in
  535. which the fields of a node are read is not important; for example, "Cube {
  536. width 2 height 4 depth 6 }" and "Cube { height 4 depth 6 width 2 }" are
  537. equivalent.
  538.  
  539. Here are the 36 nodes grouped by type. The first group are the shape nodes.
  540. These specify geometry:
  541.  
  542. AsciiText, Cone, Cube, Cylinder, IndexedFaceSet, IndexedLineSet, PointSet,
  543. Sphere,
  544.  
  545. The second group are the properties. These can be further grouped into
  546. properties of the geometry and its appearance, matrix or transform properties,
  547. and cameras and lights: Coordinate3, FontStyle, Info, LOD, Material,
  548. MaterialBinding, Normal, NormalBinding, Texture2, Texture2Transform,
  549. TextureCoordinate2, ShapeHints
  550.  
  551. MatrixTransform, Rotation, Scale, Transform, Translation
  552.  
  553. OrthographicCamera, PerspectiveCamera
  554.  
  555. DirectionalLight, PointLight, SpotLight
  556.  
  557. These are the group nodes:
  558.  
  559. Group, Separator, Switch, TransformSeparator, WWWAnchor
  560.  
  561. Finally, the WWWInline node does not fit neatly into any category.
  562.  
  563. WWWInline
  564.  
  565. AsciiText
  566.  
  567. This node represents strings of text characters from the ASCII coded character
  568. set. The first string is rendered with its baseline at (0,0,0). All subsequent
  569. strings advance y by -(size * spacing). See FontStyle for a description of the
  570. size field. The justification field determines the placement of the strings in
  571. the x dimension. LEFT (the default) places the left edge of each string at x=0.
  572. CENTER places the center of each string at x=0. RIGHT places the right edge of
  573. each string at x=0. Text is rendered from left to right, top to bottom in the
  574. font set by FontStyle. The width field defines a suggested width constraint for
  575. each string. The default is to use the natural width of each string. Setting
  576. any value to 0 indicates the natural width should be used for that string.
  577.  
  578. The text is transformed by the current cumulative transformation and is drawn
  579. with the current material and texture.
  580.  
  581. Textures are applied to 3D text as follows. The texture origin is at the origin
  582. of the first string, as determined by the justification. The texture is scaled
  583. equally in both S and T dimensions, with the font height representing 1 unit. S
  584. increases to the right. The T origin can occur anywhere along each character,
  585. depending on how that character's outline is defined.
  586.  
  587. JUSTIFICATION
  588.      LEFT     Align left edge of text to origin
  589.      CENTER   Align center of text to origin
  590.      RIGHT    Align right edge of text to origin
  591.  
  592. FILE FORMAT/DEFAULTS
  593.      AsciiText {
  594.           string         ""    # MFString
  595.           spacing        1     # SFFloat
  596.           justification  LEFT  # SFEnum
  597.           width          0     # MFFloat
  598.      }
  599.  
  600. Cone
  601.  
  602. This node represents a simple cone whose central axis is aligned with the
  603. y-axis. By default, the cone is centered at (0,0,0) and has a size of -1 to +1
  604. in all three directions. The cone has a radius of 1 at the bottom and a height
  605. of 2, with its apex at 1 and its bottom at -1. The cone has two parts: the
  606. sides and the bottom.
  607.  
  608. The cone is transformed by the current cumulative transformation and is drawn
  609. with the current texture and material.
  610.  
  611. If the current material binding is PER_PART or PER_PART_INDEXED, the first
  612. current material is used for the sides of the cone, and the second is used for
  613. the bottom. Otherwise, the first material is used for the entire cone.
  614.  
  615. When a texture is applied to a cone, it is applied differently to the sides and
  616. bottom. On the sides, the texture wraps counterclockwise (from above) starting
  617. at the back of the cone. The texture has a vertical seam at the back,
  618. intersecting the yz-plane. For the bottom, a circle is cut out of the texture
  619. square and applied to the cone's base circle. The texture appears right side up
  620. when the top of the cone is rotated towards the -Z axis.
  621.  
  622. PARTS
  623.      SIDES       The conical part
  624.      BOTTOM      The bottom circular face
  625.      ALL         All parts
  626.  
  627. FILE FORMAT/DEFAULTS
  628.      Cone {
  629.           parts         ALL     # SFBitMask
  630.           bottomRadius  1       # SFFloat
  631.           height        2       # SFFloat
  632.      }
  633.  
  634. Coordinate3
  635.  
  636. This node defines a set of 3D coordinates to be used by a subsequent
  637. IndexedFaceSet, IndexedLineSet, or PointSet node. This node does not produce a
  638. visible result during rendering; it simply replaces the current coordinates in
  639. the rendering state for subsequent nodes to use.
  640.  
  641. FILE FORMAT/DEFAULTS
  642.      Coordinate3 {
  643.           point  0 0 0  # MFVec3f
  644.      }
  645.  
  646. Cube
  647.  
  648. This node represents a cuboid aligned with the coordinate axes. By default, the
  649. cube is centered at (0,0,0) and measures 2 units in each dimension, from -1 to
  650. +1. The cube is transformed by the current cumulative transformation and is
  651. drawn with the current material and texture.
  652.  
  653. If the current material binding is PER_PART, PER_PART_INDEXED, PER_FACE, or
  654. PER_FACE_INDEXED, materials will be bound to the faces of the cube in this
  655. order: front (+Z), back (-Z), left (-X), right (+X), top (+Y), and bottom (-Y).
  656.  
  657. Textures are applied individually to each face of the cube; the entire texture
  658. goes on each face. On the front, back, right, and left sides of the cube, the
  659. texture is applied right side up. On the top, the texture appears right side up
  660. when the top of the cube is tilted toward the camera. On the bottom, the
  661. texture appears right side up when the top of the cube is tilted towards the -Z
  662. axis.
  663.  
  664. FILE FORMAT/DEFAULTS
  665.      Cube {
  666.           width   2     # SFFloat
  667.           height  2     # SFFloat
  668.           depth   2     # SFFloat
  669.      }
  670.  
  671. Cylinder
  672.  
  673. This node represents a simple capped cylinder centered around the y-axis. By
  674. default, the cylinder is centered at (0,0,0) and has a default size of -1 to +1
  675. in all three dimensions. The cylinder has three parts: the sides, the top (y =
  676. +1) and the bottom (y = -1). You can use the radius and height fields to create
  677. a cylinder with a different size.
  678.  
  679. The cylinder is transformed by the current cumulative transformation and is
  680. drawn with the current material and texture.
  681.  
  682. If the current material binding is PER_PART or PER_PART_INDEXED, the first
  683. current material is used for the sides of the cylinder, the second is used for
  684. the top, and the third is used for the bottom. Otherwise, the first material is
  685. used for the entire cylinder.
  686.  
  687. When a texture is applied to a cylinder, it is applied differently to the
  688. sides, top, and bottom. On the sides, the texture wraps counterclockwise (from
  689. above) starting at the back of the cylinder. The texture has a vertical seam at
  690. the back, intersecting the yz-plane. For the top and bottom, a circle is cut
  691. out of the texture square and applied to the top or bottom circle. The top
  692. texture appears right side up when the top of the cylinder is tilted toward the
  693. +Z axis, and the bottom texture appears right side up when the top of the
  694. cylinder is tilted toward the -Z axis.
  695.  
  696. PARTS
  697.      SIDES   The cylindrical part
  698.      TOP     The top circular face
  699.      BOTTOM  The bottom circular face
  700.      ALL     All parts
  701.  
  702. FILE FORMAT/DEFAULTS
  703.      Cylinder {
  704.           parts   ALL   # SFBitMask
  705.           radius  1     # SFFloat
  706.           height  2     # SFFloat
  707.      }
  708.  
  709. DirectionalLight
  710.  
  711. This node defines a directional light source that illuminates along rays
  712. parallel to a given 3-dimensional vector.
  713.  
  714. A light node defines an illumination source that may affect subsequent shapes
  715. in the scene graph, depending on the current lighting style. Light sources are
  716. affected by the current transformation. A light node under a separator does not
  717. affect any objects outside that separator.
  718.  
  719. FILE FORMAT/DEFAULTS
  720.      DirectionalLight {
  721.           on         TRUE       # SFBool
  722.           intensity  1          # SFFloat
  723.           color      1 1 1      # SFColor
  724.           direction  0 0 -1     # SFVec3f
  725.      }
  726.  
  727. FontStyle
  728.  
  729. This node defines the current font style used for all subsequent AsciiText.
  730. Font attributes only are defined. It is up to the browser to assign specific
  731. fonts to the various attribute combinations. The size field specifies the
  732. height (in object space units) of glyphs rendered and determines the vertical
  733. spacing of adjacent lines of text.
  734.  
  735. FAMILY
  736.  
  737.      SERIF       Serif style (such as TimesRoman)
  738.      SANS        Sans Serif Style (such as Helvetica)
  739.      TYPEWRITER  Fixed pitch style (such as Courier)
  740.  
  741. STYLE
  742.      NONE        No modifications to family
  743.      BOLD        Embolden family
  744.      ITALIC      Italicize or Slant family
  745.  
  746. FILE FORMAT/DEFAULTS
  747.      FontStyle {
  748.           size     10      # SFFloat
  749.           family   SERIF   # SFEnum
  750.           style    NONE    # SFBitMask
  751.      }
  752.  
  753. Group
  754.  
  755. This node defines the base class for all group nodes. Group is a node that
  756. contains an ordered list of child nodes. This node is simply a container for
  757. the child nodes and does not alter the traversal state in any way. During
  758. traversal, state accumulated for a child is passed on to each successive child
  759. and then to the parents of the group (Group does not push or pop traversal
  760. state as separator does).
  761.  
  762. FILE FORMAT/DEFAULTS
  763.      Group {
  764.      }
  765.  
  766. IndexedFaceSet
  767.  
  768. This node represents a 3D shape formed by constructing faces (polygons) from
  769. vertices located at the current coordinates. IndexedFaceSet uses the indices in
  770. its coordIndex field to specify the polygonal faces. An index of -1 indicates
  771. that the current face has ended and the next one begins.
  772.  
  773. The vertices of the faces are transformed by the current transformation matrix.
  774.  
  775. Treatment of the current material and normal binding is as follows: The
  776. PER_PART and PER_FACE bindings specify a material or normal for each face.
  777. PER_VERTEX specifies a material or normal for each vertex. The corresponding
  778. _INDEXED bindings are the same, but use the materialIndex or normalIndex
  779. indices. The DEFAULT material binding is equal to OVERALL. The DEFAULT normal
  780. binding is equal to PER_VERTEX_INDEXED; if insufficient normals exist in the
  781. state, vertex normals will be generated automatically.
  782.  
  783. Explicit texture coordinates (as defined by TextureCoordinate2) may be bound to
  784. vertices of an indexed shape by using the indices in the textureCoordIndex
  785. field. As with all vertex-based shapes, if there is a current texture but no
  786. texture coordinates are specified, a default texture coordinate mapping is
  787. calculated using the bounding box of the shape. The longest dimension of the
  788. bounding box defines the S coordinates, and the next longest defines the T
  789. coordinates. The value of the S coordinate ranges from 0 to 1, from one end of
  790. the bounding box to the other. The T coordinate ranges between 0 and the ratio
  791. of the second greatest dimension of the bounding box to the greatest dimension.
  792.  
  793. Be sure that the indices contained in the coordIndex, materialIndex,
  794. normalIndex, and textureCoordIndex fields are valid with respect to the current
  795. state, or errors will occur.
  796.  
  797. FILE FORMAT/DEFAULTS
  798.      IndexedFaceSet {
  799.           coordIndex         0  # MFLong
  800.           materialIndex      -1 # MFLong
  801.           normalIndex        -1 # MFLong
  802.           textureCoordIndex  -1 # MFLong
  803.      }
  804.  
  805. IndexedLineSet
  806.  
  807. This node represents a 3D shape formed by constructing polylines from vertices
  808. located at the current coordinates. IndexedLineSet uses the indices in its
  809. coordIndex field to specify the polylines. An index of -1 indicates that the
  810. current polyline has ended and the next one begins.
  811.  
  812. The coordinates of the line set are transformed by the current cumulative
  813. transformation.
  814.  
  815. Treatment of the current material and normal binding is as follows: The
  816. PER_PART binding specifies a material or normal for each segment of the line.
  817. The PER_FACE binding specifies a material or normal for each polyline.
  818. PER_VERTEX specifies a material or normal for each vertex. The corresponding
  819. _INDEXED bindings are the same, but use the materialIndex or normalIndex
  820. indices. The DEFAULT material binding is equal to OVERALL. The DEFAULT normal
  821. binding is equal to PER_VERTEX_INDEXED; if insufficient normals exist in the
  822. state, the lines will be drawn unlit. The same rules for texture coordinate
  823. generation as IndexedFaceSet are used.
  824.  
  825. FILE FORMAT/DEFAULTS
  826.      IndexedLineSet {
  827.           coordIndex         0  # MFLong
  828.           materialIndex      -1 # MFLong
  829.           normalIndex        -1 # MFLong
  830.           textureCoordIndex  -1 # MFLong
  831.      }
  832.  
  833. Info
  834.  
  835. This class defines an information node in the scene graph. This node has no
  836. effect during traversal. It is used to store information in the scene graph,
  837. typically for application-specific purposes, copyright messages, or other
  838. strings.
  839.  
  840.      Info {
  841.           string  "<Undefined info>"      # SFString
  842.      }
  843.  
  844. LOD
  845.  
  846. This group node is used to allow applications to switch between various
  847. representations of objects automatically. The children of this node typically
  848. represent the same object or objects at varying levels of detail, from highest
  849. detail to lowest.
  850.  
  851. The specified center point of the LOD is transformed by the current
  852. transformation into world space, and the distance from the transformed center
  853. to the world-space eye point is calculated. If the distance is less than the
  854. first value in the ranges array, then the first child of the LOD group is
  855. drawn. If between the first and second values in the ranges array, the second
  856. child is drawn, etc. If there are N values in the ranges array, the LOD group
  857. should have N+1 children. Specifying too few children will result in the last
  858. child being used repeatedly for the lowest levels of detail; if too many
  859. children are specified, the extra children will be ignored. Each value in the
  860. ranges array should be less than the previous value, otherwise results are
  861. undefined.
  862.  
  863. FILE FORMAT/DEFAULTS
  864.      LOD {
  865.           range [ ]    # MFFloat
  866.           center 0 0 0  # SFVec3f
  867.      }
  868.  
  869. Material
  870.  
  871. This node defines the current surface material properties for all subsequent
  872. shapes. Material sets several components of the current material during
  873. traversal. Different shapes interpret materials with multiple values
  874. differently. To bind materials to shapes, use a MaterialBinding node.
  875.  
  876. FILE FORMAT/DEFAULTS
  877.      Material {
  878.           ambientColor   0.2 0.2 0.2    # MFColor
  879.           diffuseColor   0.8 0.8 0.8    # MFColor
  880.           specularColor  0 0 0          # MFColor
  881.           emissiveColor  0 0 0          # MFColor
  882.           shininess      0.2            # MFFloat
  883.           transparency   0              # MFFloat
  884.      }
  885.  
  886. MaterialBinding
  887.  
  888. This node specifies how the current materials are bound to shapes that follow
  889. in the scene graph. Each shape node may interpret bindings differently. The
  890. current material always has a base value, which is defined by the first value
  891. of all material fields. Since material fields may have multiple values, the
  892. binding determines how these values are distributed over a shape.
  893.  
  894. The bindings for faces and vertices are meaningful only for shapes that are
  895. made from faces and vertices. Similarly, the indexed bindings are only used by
  896. the shapes that allow indexing.
  897.  
  898. When multiple material values are bound, the values are cycled through, based
  899. on the period of the material component with the most values. For example, the
  900. following table shows the values used when cycling through (or indexing into) a
  901. material with 2 ambient colors, 3 diffuse colors, and 1 of all other components
  902. in the current material. (The period of this material cycle is 3):
  903.  
  904. Material        Ambient color   Diffuse color   Other
  905.  0                     0               0           0
  906.  1                     1               1           0
  907.  2                     1               2           0
  908.  3 (same as 0)         0               0           0
  909.  
  910. BINDINGS
  911.      DEFAULT            Use default binding
  912.      OVERALL            Whole object has same material
  913.      PER_PART           One material for each part of object
  914.      PER_PART_INDEXED   One material for each part, indexed
  915.      PER_FACE           One material for each face of object
  916.      PER_FACE_INDEXED   One material for each face, indexed
  917.      PER_VERTEX         One material for each vertex of object
  918.      PER_VERTEX_INDEXED One material for each vertex, indexed
  919.  
  920. FILE FORMAT/DEFAULTS
  921.      MaterialBinding {
  922.           value  DEFAULT        # SFEnum
  923.      }
  924.  
  925. MatrixTransform
  926.  
  927. This node defines a geometric 3D transformation with a 4 by 4 matrix. Note that
  928. some matrices (such as singular ones) may result in errors.
  929.  
  930. FILE FORMAT/DEFAULTS
  931.      MatrixTransform {
  932.           matrix  1 0 0 0       # SFMatrix
  933.                   0 1 0 0
  934.                   0 0 1 0
  935.                   0 0 0 1
  936.      }
  937.  
  938. Normal
  939.  
  940. This node defines a set of 3D surface normal vectors to be used by vertex-based
  941. shape nodes (IndexedFaceSet, IndexedLineSet, PointSet) that follow it in the
  942. scene graph. This node does not produce a visible result during rendering; it
  943. simply replaces the current normals in the rendering state for subsequent nodes
  944. to use. This node contains one multiple-valued field that contains the normal
  945. vectors.
  946.  
  947. FILE FORMAT/DEFAULTS
  948.      Normal {
  949.           vector  0 0 1 # MFVec3f
  950.      }
  951.  
  952. NormalBinding
  953.  
  954. This node specifies how the current normals are bound to shapes that follow in
  955. the scene graph. Each shape node may interpret bindings differently.
  956.  
  957. The bindings for faces and vertices are meaningful only for shapes that are
  958. made from faces and vertices. Similarly, the indexed bindings are only used by
  959. the shapes that allow indexing. For bindings that require multiple normals, be
  960. sure to have at least as many normals defined as are necessary; otherwise,
  961. errors will occur.
  962.  
  963. BINDINGS
  964.      DEFAULT            Use default binding
  965.      OVERALL            Whole object has same normal
  966.      PER_PART           One normal for each part of object
  967.      PER_PART_INDEXED   One normal for each part, indexed
  968.      PER_FACE           One normal for each face of object
  969.      PER_FACE_INDEXED   One normal for each face, indexed
  970.      PER_VERTEX         One normal for each vertex of object
  971.      PER_VERTEX_INDEXED One normal for each vertex, indexed
  972.  
  973. FILE FORMAT/DEFAULTS
  974.      NormalBinding {
  975.           value  DEFAULT        # SFEnum
  976.      }
  977.  
  978. OrthographicCamera
  979.  
  980. An orthographic camera defines a parallel projection from a viewpoint. This
  981. camera does not diminish objects with distance, as an PerspectiveCamera does.
  982. The viewing volume for an orthographic camera is a rectangular parallelepiped
  983. (a box).
  984.  
  985. By default, the camera is located at (0,0,1) and looks along the negative
  986. z-axis; the position and orientation fields can be used to change these values.
  987. The height field defines the total height of the viewing volume.
  988.  
  989. A camera can be placed in a VRML world to specify the initial location of the
  990. viewer when that world is entered. VRML browsers will typically modify the
  991. camera to allow a user to move through the virtual world.
  992.  
  993. Cameras are affected by the current transformation, so you can position a
  994. camera by placing a transformation node before it in the scene graph . The
  995. default position and orientation of a camera is at (0,0,1) looking along the
  996. negative z-axis.
  997.  
  998. FILE FORMAT/DEFAULTS
  999.      OrthographicCamera {
  1000.           position         0 0 1        # SFVec3f
  1001.           orientation      0 0 1  0     # SFRotation
  1002.           focalDistance    5            # SFFloat
  1003.           height           2            # SFFloat
  1004.      }
  1005.  
  1006. PerspectiveCamera
  1007.  
  1008. A perspective camera defines a perspective projection from a viewpoint. The
  1009. viewing volume for a perspective camera is a truncated right pyramid.
  1010.  
  1011. By default, the camera is located at (0,0,1) and looks along the negative
  1012. z-axis; the position and orientation fields can be used to change these values.
  1013. The heightAngle field defines the total vertical angle of the viewing volume.
  1014.  
  1015. See more on cameras in the OrthographicCamera description.
  1016.  
  1017. FILE FORMAT/DEFAULTS
  1018.      PerspectiveCamera {
  1019.           position         0 0 1        # SFVec3f
  1020.           orientation      0 0 1  0     # SFRotation
  1021.           focalDistance    5            # SFFloat
  1022.           heightAngle      0.785398     # SFFloat
  1023.      }
  1024.  
  1025. PointLight
  1026.  
  1027. This node defines a point light source at a fixed 3D location. A point source
  1028. illuminates equally in all directions; that is, it is omni- directional.
  1029.  
  1030. A light node defines an illumination source that may affect subsequent shapes
  1031. in the scene graph, depending on the current lighting style. Light sources are
  1032. affected by the current transformation. A light node under a separator does not
  1033. affect any objects outside that separator.
  1034.  
  1035. FILE FORMAT/DEFAULTS
  1036.      PointLight {
  1037.           on         TRUE       # SFBool
  1038.           intensity  1          # SFFloat
  1039.           color      1 1 1      # SFColor
  1040.           location   0 0 1      # SFVec3f
  1041.      }
  1042.  
  1043. PointSet
  1044.  
  1045. This node represents a set of points located at the current coordinates.
  1046. PointSet uses the current coordinates in order, starting at the index specified
  1047. by the startIndex field. The number of points in the set is specified by the
  1048. numPoints field. A value of -1 for this field indicates that all remaining
  1049. values in the current coordinates are to be used as points.
  1050.  
  1051. The coordinates of the point set are transformed by the current cumulative
  1052. transformation. The points are drawn with the current material and texture.
  1053.  
  1054. Treatment of the current material and normal binding is as follows: PER_PART,
  1055. PER_FACE, and PER_VERTEX bindings bind one material or normal to each point.
  1056. The DEFAULT material binding is equal to OVERALL. The DEFAULT normal binding is
  1057. equal to PER_VERTEX. The startIndex is also used for materials or normals when
  1058. the binding indicates that they should be used per vertex.
  1059.  
  1060. FILE FORMAT/DEFAULTS
  1061.      PointSet {
  1062.           startIndex  0 # SFLong
  1063.           numPoints   -1        # SFLong
  1064.      }
  1065.  
  1066. Rotation
  1067.  
  1068. This node defines a 3D rotation about an arbitrary axis through the origin. The
  1069. rotation is accumulated into the current transformation, which is applied to
  1070. subsequent shapes.
  1071.  
  1072. FILE FORMAT/DEFAULTS
  1073.      Rotation {
  1074.           rotation  0 0 1  0    # SFRotation
  1075.      }
  1076.  
  1077. See rotation field description for more information.
  1078.  
  1079. Scale
  1080.  
  1081. This node defines a 3D scaling about the origin. If the components of the
  1082. scaling vector are not all the same, this produces a non-uniform scale.
  1083.  
  1084. FILE FORMAT/DEFAULTS
  1085.      Scale {
  1086.           scaleFactor  1 1 1    # SFVec3f
  1087.      }
  1088.  
  1089. Separator
  1090.  
  1091. This group node performs a push (save) of the traversal state before traversing
  1092. its children and a pop (restore) after traversing them. This isolates the
  1093. separator's children from the rest of the scene graph. A separator can include
  1094. lights, cameras, coordinates, normals, bindings, and all other properties.
  1095.  
  1096. Separators can also perform render culling. Render culling skips over traversal
  1097. of the separator's children if they are not going to be rendered, based on the
  1098. comparison of the separator's bounding box with the current view volume.
  1099. Culling is controlled by the renderCulling field. These are set to AUTO by
  1100. default, allowing the implementation to decide whether or not to cull.
  1101.  
  1102. CULLING ENUMS
  1103.      ON    Always try to cull to the view volume
  1104.      OFF   Never try to cull to the view volume
  1105.      AUTO  Implementation-defined culling behavior
  1106.  
  1107. FILE FORMAT/DEFAULTS
  1108.      Separator {
  1109.           renderCulling       AUTO      # SFEnum
  1110.      }
  1111.  
  1112. ShapeHints
  1113.  
  1114. The ShapeHints node indicates that IndexedFaceSets are solid, contain ordered
  1115. vertices, or contain convex faces.
  1116.  
  1117. These hints allow VRML implementations to optimize certain rendering features.
  1118. Optimizations that may be performed include enabling back-face culling and
  1119. disabling two-sided lighting. For example, if an object is solid and has
  1120. ordered vertices, an implementation may turn on backface culling and turn off
  1121. two-sided lighting. If the object is not solid but has ordered vertices, it may
  1122. turn off backface culling and turn on two-sided lighting.
  1123.  
  1124. The ShapeHints node also affects how default normals are generated. When an
  1125. IndexedFaceSet has to generate default normals, it uses the creaseAngle field
  1126. to determine which edges should be smoothly shaded and which ones should have a
  1127. sharp crease. The crease angle is the angle between surface normals on adjacent
  1128. polygons. For example, a crease angle of .5 radians (the default value) means
  1129. that an edge between two adjacent polygonal faces will be smooth shaded if the
  1130. normals to the two faces form an angle that is less than .5 radians (about 30
  1131. degrees). Otherwise, it will be faceted.
  1132.  
  1133. VERTEX ORDERING ENUMS
  1134.      UNKNOWN_ORDERING    Ordering of vertices is unknown
  1135.      CLOCKWISE           Face vertices are ordered clockwise
  1136.                           (from the outside)
  1137.      COUNTERCLOCKWISE    Face vertices are ordered counterclockwise
  1138.                           (from the outside)
  1139.  
  1140. SHAPE TYPE ENUMS
  1141.      UNKNOWN_SHAPE_TYPE  Nothing is known about the shape
  1142.      SOLID               The shape encloses a volume
  1143.  
  1144. FACE TYPE ENUMS
  1145.      UNKNOWN_FACE_TYPE   Nothing is known about faces
  1146.      CONVEX              All faces are convex
  1147.  
  1148. FILE FORMAT/DEFAULTS
  1149.      ShapeHints {
  1150.           vertexOrdering  UNKNOWN_ORDERING      # SFEnum
  1151.           shapeType       UNKNOWN_SHAPE_TYPE    # SFEnum
  1152.           faceType        CONVEX                # SFEnum
  1153.           creaseAngle     0.5                   # SFFloat
  1154.      }
  1155.  
  1156. Sphere
  1157.  
  1158. This node represents a sphere. By default, the sphere is centered at the origin
  1159. and has a radius of 1. The sphere is transformed by the current cumulative
  1160. transformation and is drawn with the current material and texture.
  1161.  
  1162. A sphere does not have faces or parts. Therefore, the sphere ignores material
  1163. and normal bindings, using the first material for the entire sphere and using
  1164. its own normals. When a texture is applied to a sphere, the texture covers the
  1165. entire surface, wrapping counterclockwise from the back of the sphere. The
  1166. texture has a seam at the back on the yz-plane.
  1167.  
  1168. FILE FORMAT/DEFAULTS
  1169.      Sphere {
  1170.           radius  1     # SFFloat
  1171.      }
  1172.  
  1173. SpotLight
  1174.  
  1175. This node defines a spotlight light source. A spotlight is placed at a fixed
  1176. location in 3-space and illuminates in a cone along a particular direction. The
  1177. intensity of the illumination drops off exponentially as a ray of light
  1178. diverges from this direction toward the edges of the cone. The rate of drop-off
  1179. and the angle of the cone are controlled by the dropOffRate and cutOffAngle
  1180. fields.
  1181.  
  1182. A light node defines an illumination source that may affect subsequent shapes
  1183. in the scene graph, depending on the current lighting style. Light sources are
  1184. affected by the current transformation. A light node under a separator does not
  1185. affect any objects outside that separator.
  1186.  
  1187. FILE FORMAT/DEFAULTS
  1188.      SpotLight {
  1189.           on           TRUE     # SFBool
  1190.           intensity    1        # SFFloat
  1191.           color        1 1 1    # SFVec3f
  1192.           location     0 0 1    # SFVec3f
  1193.           direction    0 0 -1   # SFVec3f
  1194.           dropOffRate  0        # SFFloat
  1195.           cutOffAngle  0.785398 # SFFloat
  1196.      }
  1197.  
  1198. Switch
  1199.  
  1200. This group node traverses one, none, or all of its children. One can use this
  1201. node to switch on and off the effects of some properties or to switch between
  1202. different properties.
  1203.  
  1204. The whichChild field specifies the index of the child to traverse, where the
  1205. first child has index 0.
  1206.  
  1207. A value of -1 (the default) means do not traverse any children. A value of -3
  1208. traverses all children, making the switch behave exactly like a regular Group.
  1209.  
  1210. FILE FORMAT/DEFAULTS
  1211.      Switch {
  1212.           whichChild  -1        # SFLong
  1213.      }
  1214.  
  1215. Texture2
  1216.  
  1217. This property node defines a texture map and parameters for that map. This map
  1218. is used to apply texture to subsequent shapes as they are rendered.
  1219.  
  1220. The texture can be read from the URL specified by the filename field. To turn
  1221. off texturing, set the filename field to an empty string ("").
  1222.  
  1223. Textures can also be specified inline by setting the image field to contain the
  1224. texture data. Specifying both a URL and data inline will result in undefined
  1225. behavior.
  1226.  
  1227. WRAP ENUM
  1228.      REPEAT  Repeats texture outside 0-1 texture coordinate range
  1229.      CLAMP   Clamps texture coordinates to lie within 0-1 range
  1230.  
  1231. FILE FORMAT/DEFAULTS
  1232.      Texture2 {
  1233.           filename    ""        # SFString
  1234.           image       0 0 0     # SFImage
  1235.           wrapS       REPEAT    # SFEnum
  1236.           wrapT       REPEAT    # SFEnum
  1237.      }
  1238.  
  1239. Texture2Transform
  1240.  
  1241. This node defines a 2D transformation applied to texture coordinates. This
  1242. affects the way textures are applied to the surfaces of subsequent shapes. The
  1243. transformation consists of (in order) a non-uniform scale about an arbitrary
  1244. center point, a rotation about that same point, and a translation. This allows
  1245. a user to change the size and position of the textures on shapes.
  1246.  
  1247. FILE FORMAT/DEFAULTS
  1248.      Texture2Transform {
  1249.           translation  0 0      # SFVec2f
  1250.           rotation     0        # SFFloat
  1251.           scaleFactor  1 1      # SFVec2f
  1252.           center       0 0      # SFVec2f
  1253.      }
  1254.  
  1255. TextureCoordinate2
  1256.  
  1257. This node defines a set of 2D coordinates to be used to map textures to the
  1258. vertices of subsequent PointSet, IndexedLineSet, or IndexedFaceSet objects. It
  1259. replaces the current texture coordinates in the rendering state for the shapes
  1260. to use.
  1261.  
  1262. Texture coordinates range from 0 to 1 across the texture. The horizontal
  1263. coordinate, called S, is specified first, followed by the vertical coordinate,
  1264. T.
  1265.  
  1266. FILE FORMAT/DEFAULTS
  1267.      TextureCoordinate2 {
  1268.           point  0 0    # MFVec2f
  1269.      }
  1270.  
  1271. Transform
  1272.  
  1273. This node defines a geometric 3D transformation consisting of (in order) a
  1274. (possibly) non-uniform scale about an arbitrary point, a rotation about an
  1275. arbitrary point and axis, and a translation.
  1276.  
  1277. FILE FORMAT/DEFAULTS
  1278.      Transform {
  1279.           translation       0 0 0       # SFVec3f
  1280.           rotation          0 0 1  0    # SFRotation
  1281.           scaleFactor       1 1 1       # SFVec3f
  1282.           scaleOrientation  0 0 1  0    # SFRotation
  1283.           center            0 0 0       # SFVec3f
  1284.      }
  1285.  
  1286. The transform node
  1287.  
  1288. Transform {
  1289.     translation T1
  1290.     rotation R1
  1291.     scaleFactor S
  1292.     scaleOrientation R2
  1293.     center T2
  1294.   }
  1295.  
  1296. is equivalent to the sequence
  1297.  
  1298. Translation { translation T1 }
  1299. Translation { translation T2 }
  1300. Rotation { rotation R1 }
  1301. Rotation { rotation R2 }
  1302. Scale { scaleFactor S }
  1303. Rotation { rotation -R2 }
  1304. Translation { translation -T2 }
  1305.  
  1306. TransformSeparator
  1307.  
  1308. This group node is similar to the separator node in that it saves state before
  1309. traversing its children and restores it afterwards. However, it saves only the
  1310. current transformation; all other state is left as is. This node can be useful
  1311. for positioning a camera, since the transformations to the camera will not
  1312. affect the rest of the scene, even through the camera will view the scene.
  1313. Similarly, this node can be used to isolate transformations to light sources or
  1314. other objects.
  1315.  
  1316. FILE FORMAT/DEFAULTS
  1317.      TransformSeparator {
  1318.      }
  1319.  
  1320. Translation
  1321.  
  1322. This node defines a translation by a 3D vector.
  1323.  
  1324. FILE FORMAT/DEFAULTS
  1325.      Translation {
  1326.           translation  0 0 0    # SFVec3f
  1327.      }
  1328.  
  1329. WWWAnchor
  1330.  
  1331. The WWWAnchor group node loads a new scene into a VRML browser when one of its
  1332. children is chosen. Exactly how a user "chooses" a child of the WWWAnchor is up
  1333. to the VRML browser; typically, clicking on one of its children with the mouse
  1334. will result in the new scene replacing the current scene. A WWWAnchor with an
  1335. empty ("") name does nothing when its children are chosen. The name is an
  1336. arbitrary URL.
  1337.  
  1338. WWWAnchor behaves like a Separator, pushing the traversal state before
  1339. traversing its children and popping it afterwards.
  1340.  
  1341. The description field in the WWWAnchor allows for a friendly prompt to be
  1342. displayed as an alternative to the URL in the name field. Ideally, browsers
  1343. will allow the user to choose the description, the URL or both to be displayed
  1344. for a candidate WWWAnchor.
  1345.  
  1346. The WWWAnchor's map field is an enumerated value that can be either NONE (the
  1347. default) or POINT. If it is POINT then the object-space coordinates of the
  1348. point on the object the user chose will be added to the URL in the name field,
  1349. with the syntax "?x,y,z".
  1350.  
  1351. MAP ENUM
  1352.      NONE  Do not add information to the URL
  1353.      POINT Add object-space coordinates to URL
  1354.  
  1355. FILE FORMAT/DEFAULTS
  1356.      WWWAnchor {
  1357.           name ""        # SFString
  1358.           description "" # SFString
  1359.           map NONE       # SFEnum
  1360.      }
  1361.  
  1362. WWWInline
  1363.  
  1364. The WWWInline node reads its children from anywhere in the World Wide Web.
  1365. Exactly when its children are read is not defined; reading the children may be
  1366. delayed until the WWWInline is actually displayed. A WWWInline with an empty
  1367. name does nothing. The name is an arbitrary URL.
  1368.  
  1369. The effect of referring to a non-VRML URL in a WWWInline node is undefined.
  1370.  
  1371. If the WWWInline's bboxSize field specifies a non-empty bounding box (a
  1372. bounding box is non-empty if at least one of its dimensions is greater than
  1373. zero), then the WWWInline's object-space bounding box is specified by its
  1374. bboxSize and bboxCenter fields. This allows an implementation to view-volume
  1375. cull or LOD switch the WWWInline without reading its contents.
  1376.  
  1377. FILE FORMAT/DEFAULTS
  1378.      WWWInline {
  1379.           name ""               # SFString
  1380.           bboxSize 0 0 0        # SFVec3f
  1381.           bboxCenter 0 0 0      # SFVec3f
  1382.      }
  1383.  
  1384.    Instancing
  1385.  
  1386. A node may be the child of more than one group. This is called "instancing"
  1387. (using the same instance of a node multiple times, called "aliasing" or
  1388. "multiple references" by other systems), and is accomplished by using the "USE"
  1389. keyword.
  1390.  
  1391. The DEF keyword both defines a named node, and creates a single instance of it.
  1392. The USE keyword indicates that the most recently defined instance should be
  1393. used again. If several nodes were given the same name, then the last DEF
  1394. encountered during parsing "wins". DEF/USE is limited to a single file; there
  1395. is no mechanism for USE'ing nodes that are DEF'ed in other files.
  1396.  
  1397. A name goes into scope as soon as the DEF is encountered, and does not go out
  1398. of scope until another DEF of the same name or end-of-file are encountered.
  1399. Nodes cannot be shared between files (you cannot USE a node that was DEF'ed
  1400. inside the file to which a WWWInline refers).
  1401.  
  1402. For example, rendering this scene will result in three spheres being drawn.
  1403. Both of the spheres are named 'Joe'; the second (smaller) sphere is drawn
  1404. twice:
  1405.  
  1406. Separator {
  1407.         DEF Joe Sphere { }
  1408.         Translation { translation 2 0 0 }
  1409.         Separator {
  1410.                 DEF Joe Sphere { radius .2 }
  1411.                 Translation { translation 2 0 0 }
  1412.         }
  1413.         USE Joe    # radius .2 sphere will be used here
  1414.  
  1415.  
  1416.    Extensibility
  1417.  
  1418. Extensions to VRML are supported by supporting self-describing nodes. Nodes
  1419. that are not part of standard VRML must write out a description of their fields
  1420. first, so that all VRML implementations are able to parse and ignore the
  1421. extensions.
  1422.  
  1423. This description is written just after the opening curly-brace for the node,
  1424. and consists of the keyword 'fields' followed by a list of the types and names
  1425. of fields used by that node, all enclosed in square brackets and separated by
  1426. commas. For example, if Cube was not a standard VRML node, it would be written
  1427. like this:
  1428.  
  1429. Cube {
  1430.   fields [ SFFloat width, SFFloat height, SFFloat depth ]
  1431.   width 10 height 4 depth 3
  1432.  
  1433.  
  1434. Specifying the fields for nodes that ARE part of standard VRML is not an error;
  1435. VRML parsers must silently ignore the field specification.
  1436.  
  1437. Is-a relationships
  1438.  
  1439. A new node type may also be a superset of an existing node that is part of the
  1440. standard. In this case, if an implementation for the new node type cannot be
  1441. found the new node type can be safely treated as as the existing node it is
  1442. based on (with some loss of functionality, of course). To support this, new
  1443. node types can define an MFString field called 'isA' containing the names of
  1444. the types of which it is a superset. For example, a new type of Material called
  1445. "ExtendedMaterial" that adds index of refraction as a material property can be
  1446. written as:
  1447.  
  1448. ExtendedMaterial {
  1449.   fields [ MFString isA, MFFloat indexOfRefraction,
  1450.            MFColor ambientColor, MFColor diffuseColor,
  1451.            MFColor specularColor, MFColor emissiveColor,
  1452.            MFFloat shininess, MFFloat transparency ]
  1453.   isA [ "Material" ]
  1454.   indexOfRefraction .34
  1455.   diffuseColor .8 .54 1
  1456.  
  1457.  
  1458. Multiple is-a relationships may be specified in order of preference;
  1459. implementations are expected to use the first for which there is an
  1460. implementation.
  1461.  
  1462.    An Example
  1463.  
  1464. This is a longer example of a VRML scene. It contains a simple model of a
  1465. track-light consisting of primitive shapes, plus three walls (built out of
  1466. polygons) and a reference to a shape defined elsewhere, both of which are
  1467. illuminated by a spotlight. The shape acts as a hyperlink to some HTML text.
  1468.  
  1469. #VRML V1.0 ascii
  1470.  
  1471. Separator {
  1472.     Separator {       # Simple track-light geometry:
  1473.         Translation { translation 0 4 0 }
  1474.         Separator {
  1475.             Material { emissiveColor 0.1 0.3 0.3 }
  1476.             Cube {
  1477.                 width   0.1
  1478.                 height  0.1
  1479.                 depth   4
  1480.             }
  1481.         }
  1482.         Rotation { rotation 0 1 0  1.57079 }
  1483.         Separator {
  1484.             Material { emissiveColor 0.3 0.1 0.3 }
  1485.             Cylinder {
  1486.                 radius  0.1
  1487.                 height  .2
  1488.             }
  1489.         }
  1490.         Rotation { rotation -1 0 0  1.57079 }
  1491.         Separator {
  1492.             Material { emissiveColor 0.3 0.3 0.1 }
  1493.             Rotation { rotation 1 0 0  1.57079 }
  1494.             Translation { translation 0 -.2 0 }
  1495.             Cone {
  1496.                 height  .4
  1497.                 bottomRadius .2
  1498.             }
  1499.             Translation { translation 0 .4 0 }
  1500.             Cylinder {
  1501.                 radius  0.02
  1502.                 height  .4
  1503.             }
  1504.         }
  1505.     }
  1506.     SpotLight {      # Light from above
  1507.         location 0 4 0
  1508.         direction 0 -1 0
  1509.         intensity       0.9
  1510.         cutOffAngle     0.7
  1511.     }
  1512.     Separator {      # Wall geometry; just three flat polygons
  1513.         Coordinate3 {
  1514.             point [
  1515.                    -2 0 -2, -2 0 2, 2 0 2, 2 0 -2,
  1516.                    -2 4 -2, -2 4 2, 2 4 2, 2 4 -2]
  1517.         }
  1518.         IndexedFaceSet {
  1519.             coordIndex [ 0, 1, 2, 3, -1,
  1520.                         0, 4, 5, 1, -1,
  1521.                         0, 3, 7, 4, -1
  1522.                         ]
  1523.         }
  1524.     }
  1525.     WWWAnchor {   # A hyperlinked cow:
  1526.         name "http://www.foo.edu/CowProject/AboutCows.html"
  1527.  
  1528.         Separator {
  1529.             Translation { translation 0 1 0 }
  1530.             WWWInline {   # Reference another object
  1531.                 name "http://www.foo.edu/3DObjects/cow.wrl"
  1532.             }
  1533.         }
  1534.     }
  1535.  
  1536.  
  1537. -------------------------------------------------------------------------------
  1538.  
  1539.    Browser Considerations
  1540.  
  1541. This section describes the file naming and MIME conventions to be used in
  1542. building VRML browsers and configuring WWW browsers to work with them.
  1543.  
  1544.    File Extensions
  1545.  
  1546. The file extension for VMRL files is .wrl (for world).
  1547.  
  1548.    MIME
  1549.  
  1550. The MIME type for VRML files is defined as follows:
  1551.  
  1552. x-world/x-vrml
  1553.  
  1554. The MIME major type for 3D world descriptions is x-world. The MIME minor type
  1555. for VRML documents is x-vrml. Other 3D world descriptions, such as oogl for The
  1556. Geometry Center's Object-Oriented Geometry Language, or iv, for SGI's Open
  1557. Inventor ASCII format, can be supported by using different MIME minor types.
  1558.  
  1559. [--] 26-MAY-95
  1560.