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
-
It is highly recommended to attach an illustration of a typical
elevation grid example.
-
The comment is accepted.
This is way too much work - I say "no-can-do".
-
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".
-
The equation below
(next paragraph in the spec) illustrates the ordering perfectly. I
removed the row-order reference...rc
-
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 `` ".
-
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.
-
There should be a description of normalPerVertex
field as well as colorPerVertex field.
-
The comment is accepted.
Done.
Extrusion, pp.79-80
-
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.
-
This is way too much work - I say
"no-can-do".
-
An appropriate extrusion example is expected in Appendix
B. Examples.
-
This is way too much work - I say
"no-can-do".
FontStyle, pp.82-86
-
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.)
-
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).
-
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.
-
Done.
MovieTexture, pp.95-96
-
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."
-
Done.
-
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"?
-
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
-
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 ."
-
Done.
-
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".
-
Done.
Transform, pp.120-121
-
There should be a description of the behavior of
scaling when zero value is specified in scale field (e.g.
scale = (0,0,0)).
-
We have disallowed scale = 0.0.
Viewpoint, pp.121-123
-
-
On page 123, there is a description about
"aspect ratio." However, aspect ratio is not included in the
fields of Viewpoint node.
-
Response: It has been clarified to read
"browser aspect ratio."
Prototypes and Alternate Representation, pp.150-151
-
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.
-
Done.
-
On page 151, in EXTERNPROTO example, a pair of
double quotes is missing before and after the URLs.
-
Done.
Elevator, pp.161-162
-
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.
-
Re-written.
-
An appropriate Java program corresponding to
"Elevator.java" should be attached.
-
Deleted (not sure by who or why...?....rc).
Appendix C. Java Scripting Reference, pp.163-190
-
A description of "Mapping between Java types and VRML types"
as in "Mapping between JavaScript types and VRML types" on
page 196 is expected.
-
The information is
covered already in B.5 Accessing
fields and events/B.5.1 Accessing Fields, EventIns and EventOuts of the
Script.
-
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.
-
The comment is accepted.
This was an error - getExposedField is not
allowed in the Script class.
-
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[].
-
This is a major functional change and too late to consider.
-
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."
-
Fixed.
-
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.
-
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.
-
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.
-
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:
-
...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
...
-
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.
-
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.
-
...
-
...
-
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.
-
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
-
...
-
...
-
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.
-
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:
-
...
-
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).
-
Response: Gavin is supposed to add a section
to Cl 4.
-
...
-
...
-
...
-
...
-
...
-
...
-
...
-
...
-
...
-
...
-
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.
-
Response: A reference will be added. I don't see what is needed here...rc
-
Cl
-
Cl
-
Cl
-
Cl
-
Cl
-
Cl
-
Cl
-
Cl
-
Cl
-
Cl
-
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.
-
Response: The comment is accepted. Too much work....rc
-
Cl
-
Cl
-
Cl
-
Cl
-
Cl
-
Cl
-
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?
-
Response: Fixed.
-
...
-
...
-
...
-
...
-
...
-
...
-
...
-
...
-
...
-
...
-
...
-
...
-
...
-
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.
-
Response: Done.
-
...
-
...
-
...
-
...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
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.
-
Response: A figure has been added. I re-wrote
it and conformance stuff has been moved to 7.
-
-
-
-
-
-
-
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.
-
Response: Done.
-
Clause 5, Sound node: A diagram illustrating the
sound field should be added.
-
Response: Done.
-
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.
-
Response: I changed it where I found it.
-
-
-
-
Clause 5, Switch node (and elsewhere): The concept
of traversal needs to be defined somewhere.
-
Gavin? Concepts?
-
-
-
-
-
-
-
-
-
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.
-
Response: Done.
-
-
-
-
-
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)
-
Response: Done. But, the eqns were wrong and
have been corrected.
-
-
-
-
-
-
-
-
-
-
-
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]
-
Response: Done.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
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.
-
Response: I do not know what standard you are
referring to. You need to provide a reference. rc
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Annex B, Transforms and leaves example: Where is the
red cone? It does not appear in the picture.
-
Response: This example is gone.
-
-
-
-
-
Annex B, DirectionalLight example: A picture
illustrating the effect should be included.
-
Response: No time..rc
-
Annex B, TimeSensor examples" The introductory
text and each example should be given a 3rd level subclause heading.
-
Response: Done.
-
-
-
-
-
-
-
-
-
-
-
-
SubSubclause C.4.1, 2nd para: The getExposedField method is missing from the
bullet list.
-
Response: This was an error and has been
fixed.
-
-
-
-
-
-
-
-
-
Annex F: There should be some explanatory text at
the beginning of the index explaining why some entries are italicized
and others are not.
-
Italics removed.