My X3D errata

X3D libraries

The libraries to work with X3D dataset

Welcome to My X3D errata page

The following are the few problems that I have found in the X3D documents. It is only my perception that these are problems. This does not in away imply that these are really problems in the reference.

You can find the original reference here: Web3D Consortium — X3D Specifications

I have a local copy which includes these corrections here: X3D Specifications. There is absolutly nothing official about my corrections.

Alexis Wilke

Really just a suggestion: I would mention the plus (+) sign in front of the ∞ sign in ranges such as [1,+∞).

NurbsCurve mentions a field type of SFBoolean instead of SFBool for closed.

It looks to me that all the objects derive from X3DNode and each time an object has a field pointing to another node is uses the type SFNode. Yet, X3DNode does not derive from SFNode.

The name of the X3DPrototypeInstance field is misspelled (i.e. metdata instead of metadata).

In link with this node, the link from the Nodes Index is broken (it shows as #h-X3DPrototypeInstance instead of #X3DPrototypeInstance.)

The first example in the ElevationGrid references a class node style when it is not a class (i.e. <pre class="node">).

The last level in table 13.2 Geometry3D component support levels referenced level 2 when decribing level 4. It should be level 3.

The keyValue of the IntergerSequencer references a valid range of -1|[1,∞). It looks like this range has been copied to the range of the following node IntegerTrigger and the -1 was not removed. Though it is mathematically correct, it is not necessary. The range should be (-∞,∞).

Also, these ranges are not always consistent: at times you use the word or and at times you use the vertical bar (|). It is of course equivalent.

The definition of the X3DScriptNode node derives from X3DURLObject instead of X3DUrlObject (case of URL.)

The default value of skyColor in the definition of X3DBackgroundNode should be an array (i.e. [0 0 0] instead of 0 0 0).

Note the DTD mentions the ROUTE and field but no default containerField. In other words, you most certainly have to hard code it. In libx3d, I made the default containerField of ROUTE be children and of field be fields.

The Box node description mentions textures. A Shape can get only one appearance and an appearance can only get one texture. Thus, any shape, be it a box, a cylinder, a cone... can only get one texture. For this reason, the first sentence of the paragraph right below the yellow cube should be changed to say When a texture is applied to a box, it is drawn once on each face. Note that a multi-texture, in the end, is still just one single 2D image. So the same applies to a multi-texture. (and note that it is named very well: MultiTexture <— no 's' at the end of the word!)

"Textures are applied individually to each face of the box."

The two SFVec3f detonationLocation and detonationRelativeLocation do not have a correct default value in the EspduTransform node declaration. It shows as just one 0 instead of three.

Similarly, the SFVec3f bboxCenter defines two zeroes instead of 3 in the StaticGroup node declaration.

The controlPoint and texCoord and others are defined as SFNode's but the default value is set to the empty list [] in the X3DNurbsSurfaceGeometryNode, NurbsCurve, NurbsOrientationInterpolator, NurbsPatchSurface, NurbsPositionInterpolator, NurbsSurfaceInterpolator, NurbsSweptSurface, NurbsSwungSurface and the NurbsTrimmedSurface node declarations. The default value should be NULL instead.

The opposite happened too. The texCoord field in MultiTextureCoordinate and textureTransform in MultiTextureTransform are defined as MFNode but have a default value of NULL instead of [].

The family and justify are defined as MFString and their default is not defined between brackets in the FontStyle node declaration.

The transitionType is defined as an MFString and the default is [LINEAR] instead of ["LINEAR"] in NavigationInfo.

Some MF<type> fields have a default of [NULL] which is wrong. It needs to be [] instead. These use the wrong default: color in Color, color in ColorRGBA, point in Coordinate.

Some MFNode fields have no default but a set of allowed values. This disturbes my parser, so I'm fixing those in my version of the documentation. It is not really an error. The following have a missing default: addChildren and removeChildren in Contour2D, addGeometry and removeGeometry in NurbsSet, addTrimmingContour and removeTrimmingContour in NurbsTrimmedSurface.

X3DSequencerNode is derived from X3DChildNode but should derived from X3DInterpolatorNode instead.

Also, the last word of the second paragraph should be first, not previous.

"Receipt of next event triggers next output value in keyValue array. Receipt of previous event triggers previous output value in keyValue array. These trigger events "wrap around" after reaching boundary of keyValue array; i.e., next goes to initial element after last, and previous goes to last element after previous."

In the last paragraph of the Script the word affect was used instead of effect.

"The location of the Script node in the scene graph has no affect on its operation. For example, if a parent of a Script node is a Switch node with whichChoice set to "−1" (i.e., ignore its children), the Script node continues to operate as specified (i.e., it receives and sends events)."

The last paragraph of the IndexedTriangleSet mentions a cylinder.

"The solid field determines whether the cylinder is visible when viewed from the inside. 11.2.3 Common geometry fields provides a complete description of the solid field."

The structure of the IndexedTriangleStripSet is missing the colorPerVertex field.

The first paragraph of the Polypoint2D references Polyline2D instead of Polypoint2D.

Also it references a field named points, yet in the structure it was named point. I would think that the former was what was intended for the structure.

Finally, the last paragraph mentions the solid field which doesn't apply to points.

Similarlly, the Polyline2D. ends with the same paragraph mentioning the solid field which doesn't apply to lines either.

Again, the solid field is mentioned in the Circle2D.

And again, the solid field is mentioned in the Arc2D.

The Arc2D and ArcClose2D first paragraph mention Arc and ArcClose: the 2D is missing.

The TriangleSet2D definition does not specify whether the input triangle coordinates are to be used as is or forced to a specific order (i.e. counter clock wise) so all the triangles in the set are visible by default.

In the first paragraph of the LineProperties we find a mention of the field named linewidth instead of linewidthScaleFactor.

Similarly, the first paragraph of the Switch we find a mention of the field named choice instead of whichChoice.

The third paragraph of the IndexedLineSet says that the lines are not lit. Then, in the last paragraph, it says: "Details on lighting equations as they affect IndexedLineSet nodes ..."

HAnimJoint is derived from X3DGroupingNode but could also be derived from a Transform.

HAnimHumanoid is similarly using the same transformation fields as HAnimJoint. However, it doesn't include the grouping. So maybe we would need one more abstract node for the Transform information without the grouping.

Create a new X3DTransform abstract node:
X3DTransform {
  SFVec3f    [in,out] center           0 0 0    (-∞,∞)
  SFRotation [in,out] rotation         0 0 1 0  [-1,1] or (-∞,∞)
  SFVec3f    [in,out] scale            1 1 1    (0,∞)
  SFRotation [in,out] scaleOrientation 0 0 1 0  [-1,1] or (-∞,∞)
  SFVec3f    [in,out] translation      0 0 0    (-∞,∞)
}
Make the Transform derive from X3DTransform
Transform : X3DTransform, X3DGroupingNode {
  MFNode     [in]     addChildren               [X3DChildNode]
  MFNode     [in]     removeChildren            [X3DChildNode]
  SFVec3f    [in,out] center           0 0 0    (-∞,∞)
  MFNode     [in,out] children         []       [X3DChildNode]
  SFNode     [in,out] metadata         NULL     [X3DMetadataObject]
  SFRotation [in,out] rotation         0 0 1 0  [-1,1] or (-∞,∞)
  SFVec3f    [in,out] scale            1 1 1    (0,∞)
  SFRotation [in,out] scaleOrientation 0 0 1 0  [-1,1] or (-∞,∞)
  SFVec3f    [in,out] translation      0 0 0    (-∞,∞)
  SFVec3f    []       bboxCenter       0 0 0    (-∞,∞)
  SFVec3f    []       bboxSize         -1 -1 -1 [0,∞) or -1 -1 -1
}
And then HAnimHumanoid can also derive from X3DTransform

The Script tag is defined with xml:space "preserve" in the DTD. Yet, if there is an inline script, it has to be in a <![CDATA[ ... ]]> tag. That means the xml:space specification is not necessary.

The following keyboard nodes are not declared with a <pre class="node"> (the class attribute is missing): X3DKeyDeviceSensorNode, KeySensor StringSensor, and Anchor.

As I was making sure no other nodes were afflicted by this problem, I found <pre c;ass> in the matrix computation description Tc' = ... of the TextureTransform node. Obviously, it should be class with an 'l'.

The Collision has a double X3DNode inheritance one through X3DGroupingNode and one through X3DSensorNode. This cannot be represented in ECMAScript. Also it can work, it would a pain in C++.

The TimeSensor also has a double X3DNode inheritance: one through X3DTimeDependentNode and one again through X3DSensorNode.

Here, I suggest the X3DSensorNode be changed into an abstract type. Then all the nodes which derive from it also need to be a child node, i.e. derive from X3DChildNode.
X3DSensor {
  SFBool [in,out] enabled  TRUE
  SFBool [out]    isActive
}
The following shows how (for instance) the X3DNetworkSensorNode would be changed to fit the new abstract definition.
X3DNetworkSensorNode : X3DChildNode, X3DSensor {
  SFBool [in,out] enabled  TRUE
  SFNode [in,out] metadata NULL [X3DMetadataObject]
  SFBool [out]    isActive
}
And finally, the MovieTexture also has a double X3DNode inheritance: one through X3DTexture2DNode and one again through X3DSoundSourceNode. For this one, I would suggest that the sound source become a field instead. However, from the X3D description, it certainly makes more sense to have two types of nodes instead: one would be a MovieTexture and the other a MovieSound. They both can still share some code, but this way, at least, it is possible to compile without any extraneous code to handle double inheritance. The MovieSound can be used in a Sound node. The MovieTexture can be used in an Appearance node.