Kambi VRML game engine
← Users Developers →
 
Intro and News
 
view3dscene
 
The Castle
 
All Programs
 
Forum
 
Engine
 
VRML/X3D
 
Other
 

VRML / X3D implementation status

This page collects information about implementation status of VRML constructs, with respect to VRML 1.0, 2.0 (aka VRML 97) and 3.0 (aka X3D) specifications. It also collects some details about handling of some nodes. If you want to know what is supported besides the things required by VRML specifications, you should read the other page about VRML extensions implemented.

Contents:

1. X3D and VRML 2.0 status

1.1. Components supported

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 supported.

Component
(click for details)
Supported level
Core 2 (all)
Time 2 (all) (practically)
Networking 1 (+ all level 2 features except http: protocol)
Grouping 3 (all)
Rendering 5 (all)
Shape 1
Geometry3D 4 (all)
Geometry2D
Text 1 (all) (practically)
Sound (link to vrmlengine.sf.net) 1 (all) (practically)
Lighting 3 (all) (practically)
Texturing 3 (all) (practically: some bits of level 2 nodes are missing)
Interpolation 3 (practically)
Pointing device sensor 1 (all)
Key device sensor 2 (all)
Environmental sensor 1
Navigation 3 (all)
Environmental effects 2
Geospatial As an exception, geospatial VRML 97 nodes may not even be correctly parsed by our engine. They are parsed according to X3D (there were some incompatible changes in X3D).
H-Anim 1 (all) (practically)
NURBS 1 (practically: curves, surfaces, interpolators)
DIS
Scripting 1 (all) (practically; although no ECMAScript / Java, only KambiScript / compiled protocols)
Event utilities 1 (all)
Programmable shaders 1 (all) (basically; GLSL language)
CAD geometry 1
Texturing3D 2 (all)
Cube map environmental texturing 3 (all)
Layering
Layout
Rigid body physics
Picking sensor
Followers
Particle systems

1.2. General notes

All nodes from all components of X3D edition 2 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 Kambi VRML extensions.

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

TODO for all nodes with url fields: for now all URLs are interpreted as local file names (absolute or relative). So if a VRML file is available on WWW, you should first download it (any WWW browser can of course download it and automatically open view3dscene for you), remembering to download also any texture/background files used. (Conceptually, this lack should be mentioned in Networking component details, but it's so important that I mention it here.)

No limits: VRML 97 and X3D specifications define various limits that must be satisfied by VRML browsers to call themselves "conforming" to VRML specification. For example, only 500 children per Group have to be supported, only SFString with 30,000 characters have to be supported etc. My units generally don'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 authors are limited only by the amount of memory available on user system, performance of OpenGL implementation etc.

2. VRML 1.0 status

I consider VRML 1.0 status as "almost complete". All nodes and features are handled, with the exception of:

  • Handling URLs in fields WWWInline.name and Texture2.filename. As for now, only local file names are allowed there.
  • AsciiText.width is ignored.
  • Value of height / heightAngle fields of camera nodes are ignored.

VRML 1.0 features that will probably never be implemented, as they are replaced with much better mechanisms in newer VRML versions:

  • 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).

  • 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).

  • I'm always rendering the nearest (first) child of VRML 1.0 LOD node. Therefore I'm 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 also ignored, but 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 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 utilizes it (Blender) and this program uses it only in 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.

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).