[X3D-Public] X3D spec errors about NURBS component

[Michalis Kamburelis]

Hi,

While implementing NURBS in my view3dscene, I noticed a couple of
specification errors for this component
(http://www.web3d.org/x3d/specifications/ISO-IEC-19775-1.2-X3D-AbstractSpecification/Part01/components/nurbs.html).
Here they are. They are mostly small errors, except issue 1. ("Normals
orientation" below). Comments (especially about issue 1.) are welcome.

If no objections, I understand that the correct place to submit these is
on http://www.web3d.org/x3d/specifications/spec_feedback/ (or is there
any better place? Mantis is member-only, as far as I can see?).

1. Normals orientation for NURBS surfaces is not given anywhere. This
means two problems:

  1.1.: Specification doesn't say from which side the surface is visible
when solid=TRUE is used. Should be fixed similar to how Extrusion
specification explicitly gives order or rendering quads. Proposal: add
to the X3DNurbsSurfaceGeometryNode paragraph:

  "When solid=TRUE is used, the surface should be visible only from the
side that appears ccw (counter-clockwise) on the screen, assuming a
surface's quads would be rendered in this order:

  point(u  , v  );
  point(u-1, v  );
  point(u-1, v-1);
  point(u  , v-1);

  Where u is the parameter generating successive points along the u
dimension, and v is the parameter generating successive points along the
v dimension.
  "

  This is compatible with existing implementations: at least white_dune,
octaga player, and my own.

  1.2: Also, specification doesn't say from which side the normal
generated by NurbsSurfaceInterpolator.normal_changed points to. This
could be fixed by adding

  "Normals generated by normal_changed event should point from the ccw
(counter-clockwise) side of the surface, assuming the order of surface
quads is as given in the X3DNurbsSurfaceGeometryNode section."

2. Near the end of "27.2.3 Common geometry fields and correctness":

  These two phrases contradict each other (the "-1"):
  "The number of knots shall be equal to the number of control points
plus the order of the curve."
  "the exact number required (numcontrolPoint + order − 1)"

  Should be fixed by removing "-1" from the 2nd part, that is it should
be "the exact number required (numcontrolPoint + order)"

3. In "27.3.2 X3DNurbsSurfaceGeometryNode":

  There are 2 sentences refering to the non-existing "closed" field:
  "A closed surface shall be specified by repeating the limiting control
points and setting the closed field to TRUE. If the closed field is set
to FALSE, the implementation shall not be required to smoothly blend the
edges of the surface in that dimension into a continuous surface."

  Above 2 sentences should be removed, as the way of closing the surface
is explained correctly in the very next sentences: ("A closed surface in
either the u-dimension or the v-dimension shall be specified by
repeating the limiting control points for that dimension and setting the
respective uClosed or vClosed field to TRUE....)

4. In "27.4.9 NurbsSet":

  The spec of geometry, addGeometry, removeGeometry fields/events says
that "NurbsSurface" nodes are allowed there. But NurbsSurface doesn't
exist in X3D... (I guess this is a leftover from VRML 97 spec.)

  Should be fixed, replacing "NurbsSurface" with
X3DNurbsSurfaceGeometryNode.

  Or, alternatively, could be fixed by replacing "NurbsSurface" with
more general X3DParametricGeometryNode. This would be more flexible for
VRML authors (as it includes also NurbsCurve), but will require change
to NurbsSet text: text talks about "groups a set of Nurbs surface
nodes", should be changed to "groups a set of Nurbs geometry nodes".

5. In "27.4.10 NurbsSurfaceInterpolator":

  Text says
  "Sending a set_fraction input computes a 3D position on the surface
for the given u and v coordinates, from which the position in the
surface shall be then sent by value_changed."

  but there's no value_changed output event. There are only
position_changed and normal_changed output events. Fortunately, the
intention of position_changed and normal_changed is obvious.

  Could be fixed like
  "Sending a set_fraction input computes a 3D position and normal on the
surface for the given u and v coordinates. The computed position on the
surface shall be sent by position_changed, and the computer normal shall
be sent by normal_changed."

6. In "27.4.4 NurbsCurve":

  The non-existing type "SFBoolean" is mentioned, should be fixed to
"SFBool".

Michalis