Standard Nodes

Contents:

1. Try our Castle Model Viewer!

This is a summary of X3D components supported by Castle Game Engine and Castle Model Viewer.

To test it all, download our demo models and open them with our free Castle Model Viewer.

2. X3D and VRML 2.0

2.1. Components supported

The X3D standard is divided into a number of "components". (Warning: Do not confuse the term "components" here with the Pascal standard TComponent class. These are unrelated.)

The table below sums up our support for each X3D component. This is a concise summary of how we implement X3D and VRML specifications. See the page for each component for details about supported nodes.

Component (click for details)	Supported level
Core	2 (all)
Time	2 (all)
Networking	4 (all) (except LoadSensor)
Grouping	3 (all)
Rendering	5 (all)
Shape	2
Geometry3D	4 (all)
Geometry2D	1
Text	1 (all)
Sound	1 (all)
Lighting	3 (all)
Texturing	4 (all)
Interpolation	3
Pointing device sensor	1 (all)
Key device sensor	2 (all)
Environmental sensor	2
Navigation	3 (all)
Environmental effects	4 (all)
Geospatial	(We only parse geospatial X3D nodes)
H-Anim	1 (all)
NURBS	1
DIS
Scripting	1 (all) (although no ECMAScript / Java, only CastleScript / compiled protocols)
Event utilities	1 (all)
Programmable shaders	1 (all) (GLSL language)
CAD geometry	2 (all)
Texturing3D	2 (all)
Cube map environmental texturing	3 (all)
Layering
Layout
Rigid body physics
Picking sensor
Followers
Particle systems

We practically support Interchange and Interactive profiles, and we miss only small bits (Networking level 3, Geometry2D level 1) from Immersive. But bear in mind some limitations:

• Although we have scripting, but we do not support yet the most popular X3D scripting language: ECMAScript.
• Although we have networking support, but for now it is a little user-unfriendly, that's why you have to explicitly enable it by Preferences -> Download Resources From Network

2.2. General notes

All nodes from all components of X3D 3.3 specification are included in the engine. The same goes for all the nodes from VRML 2.0 specification (it does have some nodes later removed in X3D). This doesn't mean that they are meaningfully handled, but they are at least parsed correctly (and converting from X3D XML to classic VRML preserves them correctly).

All field types, including new X3D double-precision and matrices, are supported, with the exception of MFImage. MFImage should be implemented as soon as I see some usage of this, for now no X3D specification nodes actually use this.

We support fully both XML and classic encodings.

Prototypes (both external and not) are 100% done and working :) External prototypes recognize URN of standard VRML 97 nodes, i.e. urn:web3d:vrml97:node:Xxx and standard X3D nodes (urn:web3d:x3d:node:Xxx), see also our extensions URN on VRML/X3D extensions.

Events, routes mechanism is implemented since 2008-08-11 :)

No limits: VRML 97 and X3D specifications define various limits that must be satisfied by conforming browsers. For example, only 500 children per Group need to be supported, only SFString with 30,000 characters has to be supported etc. Our engine generally doesn't have these limits (unless explicitly mentioned below). So any number of children in Group node is supported, SFString may be of any length etc. VRML/X3D authors are limited only by the amount of memory available on user system, performance of OpenGL implementation etc.

3. VRML 1.0

We consider VRML 1.0 implementation as practically complete.

Some tiny bits of VRML 1.0 remain not implemented. Implementing them is just too much work for too little gain (you should rather upgrade your models to VRML 2.0 or X3D).

Not implemented VRML 1.0 features:

• AsciiText.width is ignored.

• Clicking on WWWAnchor doesn't work (use VRML >= 2.0 Anchor instead, implementing old VRML 1.0 anchor is not worth the trouble and would unnecessarily obfuscate the code).

Notes about other VRML 1.0 features limitations/internal workings:

• OrthographicCamera.height and PerspectiveCamera.heightAngle fields work like X3D OrthoViewpoint.fieldOfView and Viewpoint.fieldOfView. This means that they specify the angle/height along the smaller browser window size — which is usualy the height, but may be width if you resize the window to be taller and thinner.

• AsciiText node's triangles and vertexes are not counted when writing triangles and vertexes counts of the scene. This is actually somewhat Ok, as later VRML specs say explicitly that Text nodes do not participate in collision detection (so they do not have triangles/vertexes for collision detection, only for rendering).

• We're always rendering the nearest (first) child of VRML 1.0 LOD node. Therefore we're potentially losing some optimization if the scene has reasonably designed LOD nodes.

  Reason: this is caused by possible "leaking" of properties in VRML 1.0. Change of LODs choice could potentially change the look of the whole scene (that is, different LOD children may cause the other nodes, following LOD node, to have different meaning). That's why implementing LOD node correctly and fast is very very hard in VRML 1.0. So much that it's not worth the trouble.

  For the same reason, changing VRML 1.0 Switch.whichChoice is not optimized and works slow. Although you will probably not notice this, since there's no event mechanism in pure VRML 1.0.

  Note that VRML >= 2.0 LOD node is working fast and switches between children, according to spec. Also Switch.whichChoice changing is optimized and instantly fast in VRML >= 2.0. So just upgrade to VRML 2.0 (aka 97) or X3D if you need these features.

• Camera focalDistance is ignored. This is allowed by specification. And honestly VRML 1.0 specification is so ambiguous about this feature (browser should adjust flying speed to reach that point in a reasonable amount of time, perhaps the browser can use this as a hint...) that I see no reliable way to handle focalDistance.

  Fortunately, VRML 2.0 replaced this with NavigationInfo.speed feature, with clear meaning (basically, it's just a distance per second), so please use this instead. (For my engine, you can use NavigationInfo node even in VRML 1.0 models.)

• Extensibility features (isA and fields) are not handled fully, although you probably will not notice. For built-in nodes, isA and fields are correctly parsed but ignored. For unknown nodes, they are simply omitted up to the matching closing parenthesis.

  This means that the only case when you will notice something doesn't work is when you use non-standard VRML node but point to a standard node with isA declaration. Then my engine will ignore isA declaration, while it should use it to interpret your node and (at least partially, when possible) handle it.

  Finishing of handling this VRML 1.0 feature has rather low priority, since this mechanism was completely dropped in later VRML versions. VRML 2.0 and X3D replaced this by fantastic prototypes mechanism, which is basically an extra-powerful and elegant way of doing what VRML 1.0 tried to do with isA and fields feature (and VRML/X3D prototypes are already handled 100% by our engine).

• MFString field with strings not enclosed in double quotes will not be parsed correctly. Moreover, parsing SFStrings not enclosed in double quotes is implemented rather as a "quick & dirty hack" than as a nice solution. Really, it's a weird "feature" of VRML 1.0 (fortunately eliminated in VRML 97) to allow strings not enclosed in double quotes. And I know about only one program that did use it (exporter to VRML 1.0 in Blender versions <= 2.4x) and this program used it only in an SFString field (Texture2.filename). So I doubt I will ever fix this to MFString — I would consider it a waste of time, since it's really a VRML-1.0-specific totally useless and uncommon syntax feature.

• VRML 1.0 specification suggests that to list viewpoints in the menu (like our "Jump to viewpoint") you should place miltiple camera nodes under a Switch.

  We will not implement it — too much complication (need to look for viewpoints in VRML 1.0 in inactive graph parts). VRML >= 2 simply allows many viewpoints in active graph parts, you should use this.

Note that some unclear parts of VRML 1.0 specification are handled according to VRML 97 specification. Also, our ray-tracer uses lighting model defined for VRML 97 (since VRML 1.0 didn't define any lighting model precisely).