This component defines nodes for rendering and animating along smooth NURBS curves and surfaces.
See also X3D specification of the NURBS component.
For demos and tests of these features,
nurbs subdirectory inside our VRML/X3D demo models.
Full support for
NurbsPatchSurface (API reference),
NurbsCurve (API reference),
NurbsPositionInterpolator (API reference),
NurbsSurfaceInterpolator (API reference),
NurbsOrientationInterpolator (API reference).
Any >= 2 value of order is allowed (X3D spec requires only 2,3,4 support).
Also basic VRML 97 NURBS nodes (defined in VRML 97 Amendment 1 specification) are handled:
VRML 97 versions are similar, but not 100% the same as their X3D counterparts.
Only X3D surfaces have
xClosed fields. We treat TRUE value there as "possibly closed", that is — if field indicates closed, we still check if limiting points match (X3D spec suggests we should do this, as far as I understand). This means X3D models may be loaded faster — if xClosed = FALSE, we do not even check if limiting points match.
Only VRML 97 surfaces have
VRML 97 versions specify
coord as direct
MFVec3f field, while X3D versions specify
Coordinate or similar node).
NurbsPositionInterpolator has different field names (keyValue, keyWeight, following interpolator conventions) than X3D
NurbsPositionInterpolator (controlPoint, weight, following nurbs conventions).
NurbsPositionInterpolator has different default value for order (4) than X3D version (3). Beware of this when converting from VRML 97 to X3D.
In VRML 97,
weight data is
MFFloat, single-precision. In X3D, it's
Note that in VRML and X3D, NURBS control points are expressed in
homogeneous coordinates. That is, the control point is actually
a 4D vector
(x, y, z, weight), which means that it's actual 3D position
(x/weight, y/weight, z/weight).
P(u) = (sum of basis * control point * weight) / (sum of basis * weight)
VRML/X3D uses a simpler equation:
P(u) = (sum of basis * control point) / (sum of basis * weight)
That is, "X3D control point" (as specified in VRML/X3D file) is assumed to be already multiplied by weight.
If you want to intuitively pull the curve toward the control point, you should
In other words, if you just want to increase the weight 2 times, then the corresponding control point should also be multiplied * 2, to make things behave intuitive.
In particular, when writing an exporter from normal 3D modeling programs, like Blender, note that you have to multiply Blender control points * Blender weights to get correct X3D control points. When you use White Dune, a NURBS 3D modeler especially suited for working with VRML/X3D, this non-intuitive behavior is somewhat hidden (the curve "handles" you see in White Dune are actually "X3D control points / divided by weight").
Our behavior is compatible with other X3D browsers/editors (at least White Dune, Octaga, InstantPlayer, BitManagement).
Copyright Michalis Kamburelis and other Castle Game Engine developers.
Thank you to Paweł Wojciechowicz from Cat-astrophe Games for various graphics.
This documentation is also open-source and you can even redistribute it on open-source terms.