Comments and Responses on CD ISO/IEC 14772-1

Austria Comments and Responses

General Comment(s)

Object orientation:

The concept of subtyping with inheritance ...

  • Response: Too late - too large a change - many ramifications.
  • Technical Comments

    last par. ("Background ..."):

    Having fogged scene with unfogged background is a strange and worrying view. ....

  • Response: This was done intentionally for two reasons. First, since the Bkg is INFINITELY far away from the viewer, BKGs will be completely opaqued by the Fog (thus, Fog does not affect it and the author is free to decide how much fogging to perform on the Bkg). Second, the Bkg is a significant rendering load and needs to run fast - Fog would slow down the rendering.
  • NavigationInfo, 3rd par. on this page ("The type ...):

    The meanings of the mentioned navigation types should be described in some more detail.

  • Response: These were intentionally left at a high level. Browsers are free to interpret these in many ways. The spec does not attempt tp standardize user interface. The semantics seem clear enough as is.
  • SpotLight, defaults:

    A larger default value for beamWidth than for cutOffAngle is not in line with the described model.

    1. The current defaults were chosen since they represent the values of highest performance. These values mean that the implementation need not compute the degradations for the penumbra. A comment to this effect will be added to the document. Dick: We have not put "why" in the spec anywhere else - I don't think that we should here either...rc

    Pp.121, ViewPoint:

    The distinction between the 'user´s view' and the ViewPoint is unclear. How is the user's view animated if not through animation of the viewpoint? And what is the effect if jump is FALSE? And how is viewing direction and tilt actually defined (you can't define both with only one vector)?

    1. Response: Chapter 4 has a much better introduction and explanation of the viewing model, 4.10 Navigation.

    And shouldn't the default for orientation be "0 0 -1 0" to be in line with the 3rd par. on p.122 ("The position ...")?

    1. The values contained in the node description are correct. However, the text will be clarified to describe the application of the orientation field to the default orientation. It already is clear. No change necessary.

    Cone and Cylinder

    The geometry nodes Cone and Cylinder are considered as solid (so, a view from inside is undefined), but parts of their surface need not exist!

    1. The wording will be clarified to specify that only outside surfaces need to be rendered. Dick: it already sez this (last two sentences).


    Japan Comments and Responses

    Technical Comments

    AudioClip, p.65

    1. There should be a description on the range of the sample (Note that there is a description of start time as sample 0 at time 0, but there is no description of end time). Is the end time either startTime+duration-1 or startTime +duration?
      1. Response: startTime +duration (this is obvious...rc)

    ColorInterpolator, pp.72-73

    It should be noted that when one interpolates two H (Hues) values that are PI degree apart, we have two choices to get the intermediate hue value, which affects the result drastically. For example, if we interpolate H = 0.0 (red) and H = (cyan) in the middle point, the hue value may be either H = /2 (middle of yellow and green) or H = 3 * /2 (middle of blue and magenta).

    1. There is no "best" behaviour so users of the interpolators should use keys that are less than . In the case of color interpolators, the choice to be used for hue will be to always go in the positive direction. The document will be clarified. Dick: I don't think this is necessary...rc

    2. Using basic linear interp:
      Hue(.5) = ((Hue(1)-Hue(0)/t1-t0) * (t-t0)) + Hue(0)
              = ((Pi-0) / (1-0)) * (0.5-0.) + 0 = Pi/2
      
      

    CylinderSensor, pp.76-77

    A brief explanation is expected for the default value of diskAngle being 0.262.

    Response: This value was found empirically. The spec does not provide justification for any default values and thus should not here.

    ElevationGrid, pp.78-79

    1. It is highly recommended to attach an illustration of a typical elevation grid example.
      1. The comment is accepted. This is way too much work - I say "no-can-do".
    2. The term row major order , used in the first bullet item list on page 78, is not clear. It should be replaced by an explicit expression of either :order in which the last subscript varies fastest" or "order in which the first subscript varies fastest".
      1. The equation below (next paragraph in the spec) illustrates the ordering perfectly. I removed the row-order reference...rc
    3. The default value 0 for xDimension and zDimension are contradictory to the sentence ``Both xDimension and zDimension must be > 1." The right description would be ">= 1". Also, "where 0<i<xDimension and 0<j<zDimension" should be "where 0<=i<xDimension and 0<=j<zDimension". With these modifications, default values should be 1, and the default grid will be 1 1 mesh. Similarly, "" should be `` ".
      1. The values for xDimension and zDimension are in the range 0. If the value of either xDimension or zDimension are 0 or 1, nothing is rendered. The formula will be corrected. ...Done.
    4. There should be a description of normalPerVertex field as well as colorPerVertex field.
      1. The comment is accepted. Done.

    Extrusion, pp.79-80

    1. It is highly recommended to attach an illustration of a typical extrusion example. Otherwise, it is hard to grasp the description on pages 79-81.
      1. This is way too much work - I say "no-can-do".

    2. An appropriate extrusion example is expected in Appendix B. Examples.
      1. This is way too much work - I say "no-can-do".

    FontStyle, pp.82-86

    1. It should be clarified whether the default size 1.0 represents 1.0 meter as with the size parameters of 3D geometry nodes. (See a similar comment for Text node.)
      1. The document will be clarified to show that size 1.0 represents 1 unit in the local coordinate system. If this is the world coordinate system, by convention 1 unit represents 1.0 meters. This clarhas not been made since all units are assumed standard VRML units as described in Ch 4. If we add a note here, we need to do it at every geometry node (and I don't think that this is necessary).
    2. On page 85, it says, "each color-coded cross-hair indicates where the X and Y axes should be in relation to the text". With color display or printing, we can distinguish different color-coded cross-hairs. However, in a black-and-white paper, we cannot distinguish them.
      1. Done.

    MovieTexture, pp.95-96

    1. On page 96, the term "frame" is used without any definition. As it turned out, the definition of "frame" is in 4.5.2 Discrete and Continuous Changes on page 39. A suitable pointer to this section is expected before or after the first occurrence of the term "frame."
      1. Done.
    2. There should be a description as to the index rule of "frame". It seems that the frame index starts with 0, but what is the index of "the last frame"?
      1. This questions makes no sense. The index of the last frame is the index of the last frame...period. We don't define this. We have consciously defined this in terms of movie time, not movie frame (since the spec does not intend to guess this).

    Script, pp.106-107

    1. On page 106, the sentence "Browsers are required to adhere to the language bindings of languages specified in annexes of the specification ." should be replaced by "Browsers are required to adhere to the Browser Script Interface specified in 4.7.10 ."
      1. Done.
    2. On page 106, the sentence "See the section 'Concepts - URLS and URNs' for details on the url field." should be replaced by first making the sentence start with a new paragraph and then putting "For the url field, see the section 4.1.5 Scripting Language Protocols".
      1. Done.

    Transform, pp.120-121

    1. There should be a description of the behavior of scaling when zero value is specified in scale field (e.g. scale = (0,0,0)).
      1. We have disallowed scale = 0.0.

    Viewpoint, pp.121-123

    1. On page 123, there is a description about "aspect ratio." However, aspect ratio is not included in the fields of Viewpoint node.
      1. Response: It has been clarified to read "browser aspect ratio."

    Prototypes and Alternate Representation, pp.150-151

    1. On page 151, "field SFFloat ambientIntensity 0 0 0" is not a valid declaration. Note that there are three occurrences of ambientIntensity on page 151. In order to be consistent with the example in VRML 1.0 format, it should be "field SFColor ambientColor 0 0 0." Other two occurrences should be modified similarly.
      1. Done.
    2. On page 151, in EXTERNPROTO example, a pair of double quotes is missing before and after the URLs.
      1. Done.

    Elevator, pp.161-162

    1. The sentence "I'll leave call buttons for outside the elevator, elevator doors and floor selector buttons as an exercise for the reader!" should be deleted.
      1. Re-written.
    2. An appropriate Java program corresponding to "Elevator.java" should be attached.
      1. Deleted (not sure by who or why...?....rc).

    Appendix C. Java Scripting Reference, pp.163-190

    1. A description of "Mapping between Java types and VRML types" as in "Mapping between JavaScript types and VRML types" on page 196 is expected.
      1. The information is covered already in B.5 Accessing fields and events/B.5.1 Accessing Fields, EventIns and EventOuts of the Script.
    2. On page 168 (in C4.1 Accessing Fields, EventIns and EventOuts of the Script), it says, "Script class has several methods to do that: getField(), getEventIn(), getEventOut(), and getExposedField()." However, getExposedField() method is not included in Script class.
      1. The comment is accepted. This was an error - getExposedField is not allowed in the Script class.
    3. On page 173, the purpose of listing the conversion table between VRML type and Java type for Browser Class is not clear. It should be deleted. Instead, the data type should be the same for both VRML and Java. For example, an MFNode field in VRML should be linked to an MFNode method (e.g. createVrmlFromString) in Java, instead of Node[].
      1. This is a major functional change and too late to consider.
    4. Correct the following errors in the examples on pages 175-176 (createVrmlFromURL and addRoute Methods). The original examples is not consistent with the specification. Specifically, there is no method for MFString getValue() without parameters. On page 175, just above "import vrml.*;", "Example.class" should be "Example.java." The same is true of "addRoute" example. On page 176, "createVRMLFromURL" should be "createVrmlFromURL."
      1. Fixed.
    5. In principle, it is recommended that getFoo() methods listed in section C.8 Class Definitions should return a specific data type other than void. Note that there are many getFoo() methods that return void.
      1. Too late for functional changes.

    Appendix D. JavaScript Scripting Reference, pp.191-198

    On page 183, Example in D.3.2 should be elaborated and moved to D.6 Example.

    1. The example in D.3.2 has been removed.

    U. K. Comments and Responses

    VRML EDITORIAL ISSUES

    Major Global Problems

    (4) Using italics for both field names and new terms leads to confusion. New terms could be underlined instead or, if they are included in the definitions, italicising may be unnecessary. The use of italics in the document is not always consistent even with the definition above.

    Response: The context of the sentence makes this clear. No change.

    Detailed Editorial Comments

    0. INTRODUCTION

    (5) Completeness - how does this relate to verifiability of implementations? Is this an aim?

    Response: No idea what they mean by this...rc

    5. NODE REFERENCE

    Background

    (136) As the sky sphere is infinitely large and the panorama is mapped on to an infinitely large cube, why is it front of the sky?
    Response: This is the rendering order. The text has been clarified.

    (137) It is stated that the six images of the panorama are EACH mapped on to the faces of the cube. Surely, one image is mapped on to each face? If the entire image goes on each face, the order of placing them must be defined.
    Response: The text has been clarified.

    (139) As PNG is not an international standard, can it be mandated that it is supported? Perhaps PNG should be specified as part of VRML.
    Response: It is mandated. We will not include PNG in the VRML spec.

    (139.1) Support for GIF is ìrecommendedî. This type of recommendation should be collected in one place.
    Response: ?

    (139.2) The order of parameters looks strange, why not put ground and sky parameters as consecutive fields?
    Response: The order in the spec is always: eventIn, field, exposedField, and eventOut. Within each group the order is alphabetical.

    Billboard

    (140) Using small floating point numbers to represent special cases is not to be recommended. Surely a separate field for defining screen-alignment would be preferable.
    Response: I assume that they are referring to 0.0. We do this all over the place and it does not seem to be a problem yet. The change would break functionality (even though it is a good idea).

    Collision

    (150.1) Various pieces of implementation dependent information need moving to Section 7.

    1. The comment is accepted. ????? What to do...rc ???

    Color

    (152.1) Need to tighten up the description ìshould ideallyî. It is not an appropriate wording. Is there any control over precedence?
    Response: The comment is accepted.

    ColorInterpolator

    (153) HSV should be defined and the relationship to RGB.
    Response: A reference was added to clarify.

    Cylinder

    (153.1) The top should be Y= height/2, bottom Y=-height/2
    Response: The comment is accepted.

    (153.2) Unit texture square should be centred at (0,+-height/2)
    Response: Huh? It is centered at (0,-h/2,0) (i.e., at the base of the cone).

    (153.3) Clarification is required as to the "solidity" of an object and what its consequences are. The specification states that the Cylinder node is always considered solid and has outward faces only. Does this imply that none of its surfaces have a defined rendering from the back. If this is true then a further implication is that the transparency property is not meaningful for Cylinders. This looks like an unintended interaction. Maybe a clearer solution would be to give Cylinder nodes a "solid" field in a similar manner to the Extrusion node, to inform the browser that it can assume thatch the faces do not require rendering from the back (ie. back face culling is permitted). This issue is valid for the other geometry nodes (Sphere, Box etc)
    Response: Yes, Cylinders are treated as one-sided.

    (153.4) In the definition of the cylinder the word solid is used. This implies that a cylinder does have a defined interior and is not just constructed from a set of faces. In this situation is it valid that the word solid should be used? For example, if an opaque cone is positioned inside a transparent cylinder, what is the effect? We assume you see the cone, but this seems to contradict the notion that the cylinder is solid.
    Response: The comment is accepted.

    Directional Light

    (154.1) What is per-object lighting for? Does it allow you, for example, to light different rooms of a house with independent, non-interfering lighting systems? What would happen if you opened a door between rooms?
    Response: The ref was removed.

    FontStyle

    (159.4) Should not use colour coding in an ISO std that is printed in B&W.
    Response: The comment is accepted.

    Group

    (159.6) Group is redundant. Why keep it? Examples that do not use transformations still seem to use the Transform node.

    Response: Performance. The test for identity can be costly for high-performance scenes.

    IndexedFaceSet

    (165) Should not the effect of color field being NULL be described?
    Response: The comment is accepted.

    (165.2) Should there be clarification in the specification with regard to the splitting of polygons into triangles for shading purposes or at least an acknowledgement that this may be a problem.
    Response: No, we do not specify how to render geometry. Yes, may be confusing to some users, but this info does not belong in the spec. (We try to avoid details on things that are not required or specified.)

    (165.3) Must an IndexedFaceSet have flat polygons? Must it be non-self-intersecting? Must each polygon have at least three vertices? Must all of its vertices be distinct? Clarification is needed on these points.
    Response: Results are undefined in all 4 cases. The spec has been clarified.

    Inline

    (167.1) It would help to have example of how start of file would look.. Presumably: children [....] ?
    Response: No. The text says: "Each specified URL shall refer to a valid VRML file that contains a list of children nodes at the top level as described in ... The results are undefined if the URL refers to a file that is not VRML or if the file contains non-children nodes at the top level." This seems clear. The file is a valid VRML, nothing special.

    (167.2) What happens when an event causes the URL to change?
    Response: If the url field changes, the file is obviously re-loaded. If the file itself changes, it is undefined. This has been clarified.

    OrientationInterpolator

    (192.1) A diagram showing the shortest path on the unit sphere between two orientations (with different axes of rotation) would be useful.
    Response: Nice by not necessary. The text is very precise.

    Sound

    (205.1) Paragraph 'The ideal implementation.....' - rephrase in terms of allowable differences and point to from an Allowable Differences Annex.
    Response: Moved to 7.

    (205.2) Can the model generate stereo sound? Can account be taken of observer geometry (e.g. using Head Related Transfer Function approximations)?
    Response: Yes, stereo is possible. The VRML spec does not include observer geometry at this time.

    TimeSensor

    (208.1) The description of TimeSensors in Section 4.9.7 and Section 5 leaves an unsure feeling of what events will be generated when, by a TimeSensor containing any given set of field values and to which any given sequence of events is sent. ............
    Response: See Gavin and the latest revision of 4.

    Visibility Sensor

    (214) There is confusion regarding the line in the text, 'Instanced (DEF/USE) visibility sensors use the union of all the boxes defined by their instances to check for enter and exit - an instanced visibility sensor will detect enter, motion, and exit for all instances of the box and send output events appropriately.' Enter and exit appear to be the wrong terms in this context. There seems to be confusion regarding the independence of instances. Compare the above text with the statement regarding independence given in 4.9.6.
    Response: The doc has been clarified.


    U. S. Comments and Responses

    The United States votes NO with the following comments....

    Response: Traitors!!!     :-)

    Technical Comments:

    1. ...
    2. ...
    3. Clause 5, Background node: It is not clear whether the URL's are allowed to point to moving images. For example, it might be convenient to allow the sky URL to point to an MPEG-2 movie which shows moving clouds playing back in a loop.
      1. Response: It is clear. Only PNG and JPEG image types are required. Implementations are free to support extended image types as well, but this is never explicitly stated anywhere in the spec.
    4. ...
    5. ...
    6. Clause 5, Extrusion node: It is not clear whether the joints of the extrusion are continuous or discontinuous. In other words, is the cross-section curve of each joint based on the result of processing the previous spine section extrusion and its cross-section curve or on the original cross-section curve. A picture of this geometry (such as provided for the cone node) would greatly increase clarity.
      1. Response: This section is being re-written. There is no time to do a figure and it would be very difficult indeed (I know from experience)...rc
    7. ...
    8. ...
    9. Clause 5, MovieTexture node: It is implied but not specifically stated that movie formats other than MPEG-1 can be supported. The wording should be made more clear that browsers shall support MPEG-1 (both of the two described formats) but may support additional formats such as MPEG-2 or Motion JPEG.
      1. Response: No. There are thousands of ways that browsers can EXTEND implemenations of VRML. We cannot possibly name them all. What about streaming movies? etc...rc

    Editorial Comments:

    1. ...
    2. Clause 5: There should be a description of the symbology used in this clause to describe each node. If there is one elsewhere in the document, it should be reference at the beginning of this clause (perhaps in the "Introduction" as described in the preceding comment). For example, if one starts reading in Clause 5 (a frequent occurrence since this is a reference clause), it is not clear when field names are shown in bold weight and when they are shown in normal weight (see the ElevationGrid and Extrusion nodes).
      1. Response: Gavin is supposed to add a section to Cl 4.
    3. ...
    4. ...
    5. ...
    6. ...
    7. ...
    8. ...
    9. ...
    10. ...
    11. ...
    12. ...
    13. Clause 5, Box node: There should be a reference to more information on applying textures. The paragraph dealing with how textures are applied is insufficient if one is unfamiliar with textures and how they are specified.
      1. Response: A reference will be added. I don't see what is needed here...rc
    14. Cl
    15. Cl
    16. Cl
    17. Cl
    18. Cl
    19. Cl
    20. Cl
    21. Cl
    22. Cl
    23. Cl
    24. Clause 5: All geometry nodes should have a picture of an example of the represented geometry. For example, there is no such picture for the elevation grid or extrusion nodes.
      1. Response: The comment is accepted. Too much work....rc
    25. Cl
    26. Cl
    27. Cl
    28. Cl
    29. Cl
    30. Cl
    31. Clause 5, FontStyle node, alignment figures: These are really nice figures. However, when printed to a monochrome printer, do the shades generated for the different colors allow the meanings of the plus symbols to be distinguished?
      1. Response: Fixed.
    32. ...
    33. ...
    34. ...
    35. ...
    36. ...
    37. ...
    38. ...
    39. ...
    40. ...
    41. ...
    42. ...
    43. ...
    44. ...
    45. Clause 5, LOD node, 2nd para: The last two sentences should be replaced by a sentence which indicates that the "interpretation of the distances is as follows" followed by a series of mathematical expressions which indicate which range to use.
      1. Response: Done.
    46. ...
    47. ...
    48. ...
    49. ...
    50. Clause 5, Sound node: The text provided for this node needs rewriting. It is not clear what the exact capabilities of the sound node nor which functionality is required and which is optional. After very careful study, it seems as though the functionality of the Sound node is appropriate (which is why this is not a technical issue) but it is so difficult to determine what is and is not allowed that it is not clear how one would use this node. Only the specification part of this node description should be left in this clause. The remainder should be moved to a minimum support requirement subclause for sound in clause 7.
      1. Response: A figure has been added. I re-wrote it and conformance stuff has been moved to 7.
    51. Clause 5, Sound node, penultimate para: There is an inconsistent mixture of terms in this paragraph: locate vs. localize vs. spatialize. One term should be selected and used throughout. Since the intent is to make the sound appear to be eminating from a geometric picture location, locate seems the most appropriate of those listed but has an implication in common English usage of "to find". Instead, it might be better to talk about sound source placement within a picture.
      1. Response: Done.
    52. Clause 5, Sound node: A diagram illustrating the sound field should be added.
      1. Response: Done.
    53. Clause 5, SphereSensor node, 1st para: There should be a consistent way of referring to nodes in the document. Previously, references to nodes were to "xxx node". In this paragraph, the word "node" has been dropped in several cases and the use of articles has been omitted. The document should be made consistent.
      1. Response: I changed it where I found it.
    54. Clause 5, Switch node (and elsewhere): The concept of traversal needs to be defined somewhere.
      1. Gavin? Concepts?
    55. Clause 5, TextureCoordinate node, 2nd equation: This specification presumes knowledge of the C programming language. This knowledge should not be presumed since this specification is likely to be read by content providers as well as tool and browser developers. The relationship hear should be restated either using standard mathematical expressions or in some other fashion which does not need knowledge of a specific programming language.
      1. Response: Done.
    56. Clause 5, TextureTransform node, last equation: The terms "TT" and "TC" are not defined. The correctness of the equation should be reviewed. The following equation is suggested:
      [x' y' z'] = T C R S -C [x y z] (where P is a vector)
      1. Response: Done. But, the eqns were wrong and have been corrected.
    57. Clause 5, Transform node, 5th para: The matrix TC is not defined although it is used in the equation which follows. The SR matrix should be called O. The following replacement equation is suggested:
      [x' y' z']' = T C R O S -O -C [x y z]
      1. Response: Done.
    58. Subclause 6.10: There is a standard for specifying time and basing it on the date specified. A reference to this standard should be placed in clause 2 with a link to clause 2 in this clause.
      1. Response: I do not know what standard you are referring to. You need to provide a reference. rc
    59. Annex B, Transforms and leaves example: Where is the red cone? It does not appear in the picture.
      1. Response: This example is gone.
    60. Annex B, DirectionalLight example: A picture illustrating the effect should be included.
      1. Response: No time..rc
    61. Annex B, TimeSensor examples" The introductory text and each example should be given a 3rd level subclause heading.
      1. Response: Done.
    62. SubSubclause C.4.1, 2nd para: The getExposedField method is missing from the bullet list.
      1. Response: This was an error and has been fixed.
    63. Annex F: There should be some explanatory text at the beginning of the index explaining why some entries are italicized and others are not.
      1. Italics removed.