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