This is a summary of X3D components supported by
Castle Game Engine and
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 table below sums up our X3D component support.
Since the whole X3D standard is divided into components (and it includes
also all VRML 2.0 features), this is a concise summary of
our "VRML / X3D implementation status". Each component has also
separate page with details about support (both VRML 97 and X3D features).
A word "practically" below means that the component is not absolutely
100% supported on given level, but most important
parts (99% of usage) of given level are covered.
We practically support Interchange and Interactive
profiles, and 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 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
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 :)
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.
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:
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
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