[X3D-Public] X3D spec errors about NURBS component

Thu Apr 1 09:54:34 PDT 2010

Hi, Michalis --

These are worthwhile discussion points. Please submit them using the standard spec_feedback mechanism to ensure that they are formally considered.

  -- Dick

/******************************************
| Richard F. Puk, Ph.D., President
| Intelligraphics Incorporated
| 7644 Cortina Court, Carlsbad, CA  92009-8206
| Tel:  +1-760-753-9027   Cell:  +1-760-809-9027
| E-mail:  puk at igraphics.com
| Web:  http://www.igraphics.com/
\******************************************

> -----Original Message-----
> From: x3d-public-bounces at web3d.org [mailto:x3d-public-
> bounces at web3d.org] On Behalf Of Michalis Kamburelis
> Sent: Thursday, April 01, 2010 6:34 AM
> To: x3d-public PUBLIC
> Subject: [X3D-Public] X3D spec errors about NURBS component
> 
> 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
> 
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org