Some Proposals for Updating the VRML Specification

This list has been revised to reflect the updated VRML specification, which contains clarifications from the original version. Only those changes that do not appear in the draft 1.1 specification are listed below.

Please send any comments on these proposed changes to the www-vrml mailing list (www-vrml@wired.com).

These are grouped into a number of different categories.

Errors

1. The description for the LOD node still says "Each value in the ranges array should be less than the previous value", which of course is wrong. It should read "greater than".

2. The paragraph on "Issues for low-end rendering systems" at the end of the SpotLight description is good, but it should also appear after the DirectionalLight node. It should also be added after the PointLight node, and removed from the PointSet node where it makes no sense.

3. The section describing instancing using USE appears to have been deleted. Since there are still references to USE elsewhere in the spec, I assume this was not deliberate...?

4. The description of the Text node refers to "extent", but the actual node syntax still shows "width".

Changes

1. Switch nodes should be treated as Separators.

New Nodes

1. A "billboard" or "sprite" node, whose orientation is always locked to that of the camera.

New or Changed Fields

1. The "on", "intensity" and "color" fields for lights should be "input" fields.

2. All the fields of the Environment node should be "input" fields.

3. Add a transparencyColor field to the Texture2 node, for those file formats (such as JPEG) that do not provide an alpha channel. Alternatively, require the use of PNG instead of JPEG when an alpha channel is needed.

4. Add a primitiveVisibility field to the ShapeHints node. The value would be one of INSIDE, OUTSIDE, or BOTH; the INSIDE setting would cause primitives (Sphere, Cone, Cylinder, Cube) to be visible from the inside only, OUTSIDE (the default) would make them visible from the outside only, and BOTH would make them visible from both the inside and the outside. (See also the proposed clarification regarding negative radius values for Cone, Sphere and Cylinder).

5. Change the map field of the WWWAnchor node to be an SFBitmask, with values of POINT, ORIENTATION and TEXTURE. POINT causes the camera's (object-space) location to be sent, ORIENTATION causes its (object-space) orientation to be sent, and TEXTURE causes its texture map coordinates to be sent. Regardless of the order in which the values are specified, they're always sent with the POINT first (if specified), the ORIENTATION next (if specified) and the TEXTURE coordinates last (if specified). The value NONE would also be accepted, in which case none of the extra information is sent.

6. Add a "tesselation" field to the ShapeHints node, giving the number of faces to use for tesselating a Sphere, Cone or Cylinder.

7. Add a "quality" field to the Texture2 node. It would be an SFEnum, with values of PERSPECTIVE and LINEAR, to indicate whether true, perspective-correct texture mapping is required or whether faster bi-linear can be used.

8. The IndexedFaceSet should have a textureIndex field that would allow textures to be associated with each face, rather than requiring multiple face sets for objects with multiple textures.

Clarifications

1. Deprecate the use of GIF due to licensing restrictions.

2. The interpretation of the textureCoordIndex field needs to be spelled out, and PER_VERTEX_INDEXED bindings in general. The specification is still unclear on this point.

3. Negative radius values for Cones, Cylinders and Spheres should turn them inside-out. This, combined with shapeType UNKNOWN_SHAPE_TYPE, will produce primitives that are visible from both the inside and the outside. Alternatively, new fields could be added to the ShapeHints node to indicate whether subsequent primitives should be visible from the outside, the inside, or both; this is probably a better (and clearer) way of doing it, since it avoids questions like "what if a cone has a negative radius and a negative height?". It also lets us turn cubes inside-out.

4. It should be stated that relative URLs should be handled as described in RFC 1808.

5. In the description of WWWAnchor, it should be made clear that the "deepest" anchor wins.

6. It is strongly suggested that DEF'd names be kept unique.

7. It should be made clear that definintions for new nodes (done with "isA" and "fields") are file scoped; they only need to be specified the first time.

8. The exact meaning of the width field of the AsciiText node is unclear.

9. The proper uses of the focalDistance field should be spelled out. The following wording has been proposed by Alan Walford for the 1.0 clarifications document:

   focalDistance is the distance from the Camera to a point in space along the vector defined by the view direction given by the Camera's angles and position. This point in space is where the "viewer" is focused attention. This value is a hint only and may be used by a browser to define the speed of travel for flying or walking.

   For example, a focalDistance of 5 means the object of primary concern is 5 meters from the camera and the browser should adjust flying speed to reach that point in a reasonable amount of time. If the distance was 50 meters then perhaps the browser can use this as a hint to travel 10 times faster.

   focalDistance is not to be confused with focal length used to describe a lens in optics.

   The heightAngle of a PerspectiveCamera can be used to simulate a particular lens and camera. To calculate a heightAngle use the following formula: "heightAngle = 2.0 * arctan( (verticalFormat/2) / focalLength )".

10. Drop support for unquoted strings, or clarify the rules regarding commas and closing brackets and embedded quotes). [proposed by steffel@blacksun.com]

11. Consider changing to ANSI-C standard for multi-line SFStrings. [proposed by steffel@blacksun.com] (It's not clear that this adds any additional functionality).

12. Specify whether SFStrings containing linefeeds should lead to multiple lines of text in an AsciiText node. [proposed by steffel@blacksun.com]

13. Required that one class of SFBitmask should have no more than 32 values (so that they fit inside a 32-bit LONG value). [proposed by steffel@blacksun.com]

14. Make it clear that users can define their own mnemonics for SFEnum in user defined types. [proposed by steffel@blacksun.com].

General

1. Support for animated texture maps. This could be done by allowing the file to be of type MPEG, or by allowing the filename field in the Texture2 node to be an MFString (to specify multiple frames for a very short animation).

2. Support the use of degrees instead of radians throughout, by recognizing a 'd' or 'D' suffix. For example, "0 1 0 45D".

QUE Home Page
For technical support for our books and software contact support@mcp.com
© 1996, Que Corporation