This is a summary of X3D components supported by Castle Game Engine and view3dscene. Remember that it's completely free and easy to download view3dscene, our VRML/X3D browser, and just try it all in action. Download also our demo 3D models to open them with view3dscene.
Once you tried view3dscene or our game engine, this page may serve as a detailed map (with lots of technical details and links to even more technical details), about what and how is implemented.
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.
(click for details)
|Networking||4 (all) (except |
|Pointing device sensor||1 (all)|
|Key device sensor||2 (all)|
|Environmental effects||4 (all)|
|Geospatial||(We only parse geospatial X3D nodes)|
|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)|
|Cube map environmental texturing||3 (all)|
|Rigid body physics|
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:
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.
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.
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:
PerspectiveCamera.heightAngle fields work like
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
node. Therefore we're potentially losing some optimization if the scene
has reasonably designed
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
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.
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
Fortunately, VRML 2.0 replaced this with
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 (
fields) are not handled
fully, although you probably will not notice. For built-in nodes,
fields are correctly parsed but ignored.
For unknown nodes, they are simply omitted up to the matching
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
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
(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).
Copyright Michalis Kamburelis and Castle Game Engine Contributors.