[back to main page]

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.

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.

Contents:

  1. X3D status
    1. Components supported (summary)
    2. Details about supported nodes
    3. Clarifications to X3D multi-texturing specification
      1. Precise and corrected MultiTexture.mode specification (aka "how do we handle it")
      2. MultiTexture.source extensions
      3. Problems with existing X3D MultiTexture.mode specification
    4. DDS (DirectDraw Surface) support details
  2. VRML 2.0 status
  3. VRML 1.0 status
  4. Tests passed
    1. NIST VRML test suite results

1. X3D status

All nodes from all components of X3D edition 2 specification are included in the engine. 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.

1.1. Components supported (summary)

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 table may actually be considered a concise summary of our "VRML / X3D implementation status".

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 Supported level
Core 2 (all)
Time 2 (all) (practically)
Networking 1 (+ all level 2 features except http: protocol)
Grouping 3 (all)
Rendering 3 (practically)
Shape 1
Geometry3D 4 (all)
Geometry2D
Text 1 (all) (practically)
Sound
Lighting 3 (all) (practically)
Texturing 3 (all) (practically: some bits of level 2 nodes are missing)
Interpolation 3 (practically)
Pointing device sensor (TouchSensor supported, but that's it for now)
Key device sensor 1
Environmental sensor 1
Navigation 1 (+ most, but not all, features up to level 3)
Environmental effects 2
Geospatial
H-Anim 1 (all) (practically)
NURBS
DIS
Scripting 1 (all) (practically; although no ECMAScript / Java, only KambiScript / compiled protocols)
Event utilities 1 (all)
Shader 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. Details about supported nodes

Besides all VRML 97 features (see lower on this page for VRML 2.0 status), X3D things implemented now are:

1.3. Clarifications to X3D multi-texturing specification

1.3.1. Precise and corrected MultiTexture.mode specification (aka "how do we handle it")

To allow different texture modes for RGB and for alpha channel, you should just write two mode names inside one string, and separate them by a comma or slash (additional whitespace around is allowed). For example, mode [ "MODULATE / REPLACE" ] means that on the 1st texture unit, RGB is modulated and alpha is replaced. Contrast this with mode [ "MODULATE" "REPLACE" ], that means to modulate (both RGB and alpha) on the 1st texture unit, and then to replace (both RGB and alpha) on the 2nd texture unit.

This way we keep the interpretation that "one string on the mode field always describes full behavior of exactly one texture unit". Of course, some modes are not available for alpha channel (these are the OpenGL constraints).

Table below describes precise behavior and disallowed situations for all mode names. Treat this as a corrected and precise version of the similar table in X3D spec of MultiTexture (see text down for details where and why it's corrected, short version: specification is simply poor and inconsistent). In table below,

  1. Arg1 is the current texture unit,
  2. Arg2 is determined by the source field. By default, it's the result of previous texture stage, or (for the 1st stage) it's interpolated material*lighting.
Mode name Behavior when used alone
(like "REPLACE")
Behavior when used for only RGB channel
(like "REPLACE / ...")
Behavior when used for only alpha channel
(like "... / REPLACE")
MODULATE Output.RGBA := Arg1.RGBA * Arg2.RGBA Output.RGB := Arg1.RGB * Arg2.RGB Output.A := Arg1.A * Arg2.A
MODULATE2X Output.RGBA := Arg1.RGBA * Arg2.RGBA * 2 Output.RGB := Arg1.RGB * Arg2.RGB * 2 Output.A := Arg1.A * Arg2.A * 2
MODULATE4X Output.RGBA := Arg1.RGBA * Arg2.RGBA * 4 Output.RGB := Arg1.RGB * Arg2.RGB * 4 Output.A := Arg1.A * Arg2.A * 4
REPLACE or SELECTARG1 Output.RGBA := Arg1.RGBA Output.RGB := Arg1.RGB Output.A := Arg1.A
SELECTARG2 Output.RGBA := Arg2.RGBA Output.RGB := Arg2.RGB Output.A := Arg2.A
ADD Output.RGBA := Arg1.RGBA + Arg2.RGBA Output.RGB := Arg1.RGB + Arg2.RGB Output.A := Arg1.A + Arg2.A
ADDSIGNED Output.RGBA := Arg1.RGBA + Arg2.RGBA - 0.5 Output.RGB := Arg1.RGB + Arg2.RGB - 0.5 Output.A := Arg1.A + Arg2.A - 0.5
ADDSIGNED2X Output.RGBA := (Arg1.RGBA + Arg2.RGBA - 0.5) * 2 Output.RGB := (Arg1.RGB + Arg2.RGB - 0.5) * 2 Output.A := (Arg1.A + Arg2.A - 0.5) * 2
SUBTRACT Output.RGBA := Arg1.RGBA - Arg2.RGBA Output.RGB := Arg1.RGB - Arg2.RGB Output.A := Arg1.A - Arg2.A
OFF Texture stage is simply turned off. Not allowed.
DOTPRODUCT3 NewArg1.RGB := (Arg1.RGB - 0.5) * 2;
NewArg2.RGB := (Arg2.RGB - 0.5) * 2;
Output.RGBA := dot(NewArg1.RGB, NewArg2.RGB)
... (calculate NewArg* same as on the left)...
Output.RGB := dot(NewArg1.RGB, NewArg2.RGB)
Not allowed.
BLENDDIFFUSEALPHA Output.RGBA :=
  Arg1 * PRIMARY_COLOR.Alpha +
  Arg2 * (1 - PRIMARY_COLOR.Alpha)
Not allowed.
BLENDTEXTUREALPHA Output.RGBA :=
  Arg1 * Arg1.A +
  Arg2 * (1 - Arg1.A)
Not allowed.
BLENDFACTORALPHA Output.RGBA :=
  Arg1 * MULTI_TEXTURE_CONSTANT.Alpha +
  Arg2 * (1 - MULTI_TEXTURE_CONSTANT.Alpha)
Not allowed.
BLENDCURRENTALPHA Output.RGBA :=
  Arg1 * PREVIOUS_STAGE.Alpha +
  Arg2 * (1 - PREVIOUS_STAGE.Alpha)
Not allowed.

1.3.2. MultiTexture.source extensions

In the same spirit, you can specify separate sources for RGB and alpha channels, just separate them by comma or slash within a single string. For example, source string "DIFFUSE / FACTOR" says to take diffuse color as a source for Arg2.RGB and constant factor (MultiTexture.alpha field) for Arg2.Alpha.

Note that the empty string is also a source name (it means to take color from previous texture stage). So source string like "/ FACTOR" is also Ok (takes RGB from previous stage, and alpha from constant factor), and "FACTOR /" is Ok (takes RGB from constant factor MultiTexture.color, and alpha from previous stage).

An example: suppose you have two textures that you want to subtract on RGB (tex2 - tex1) channel, and you want to set resulting alpha channel to 1.0 (regardless of any texture value). This will work:

MultiTexture {
  texture [
    ImageTexture { url "tex1.png" }
    ImageTexture { url "tex2.png" }
  ]
  mode [ "REPLACE" "SUBTRACT / SELECTARG2" ]
  source [ "" " / FACTOR" ]
  alpha 1.0
}

# Calculations on texture unit 1:
#   Stage1Output.RGBA := Tex1.RGBA;
# Calculations on texture unit 2:
#   Output.RGB := Tex2.RGB - Stage1Output.RGB;
#   Output.A := Arg2.A := 1.0;

1.3.3. Problems with existing X3D MultiTexture.mode specification

Unfortunately, X3D specification is awfully ambiguous when talking about multi-texturing modes. Below is my list of spotted problems, and an explanation how we handle it in our engine (for a short summary, modes table in section above should also be informative). I tried to make my implementation following common-sense, hopefully it will be somewhat compatible to other implementations and at the same time comfortable to users.

Please report if any other VRML/X3D browser treats it differently, although it doesn't necessarily mean that I will fix to be compatible (I know that Octaga seems to revert the order of textures, for starters, which seems to contradict the spec... No wonder people get this messed up, since specification is so poor at this point.)

(And if you have any power over the spec, please fix issues mentioned below in the next version. It seems I'm not the only one confused by specs. I posted on forum asking for input about this, without any answer so far.)

  1. The mode field may contain an additional blending mode for the alpha channel. — this is the most troublesome part of the specification. It contradicts most of the remaining specification for MultiTexture node — other parts clearly suggest that exactly one mode string corresponds to one texture unit, for example 1. it's mentioned explicitly that if the mode.length is less than texture.length, remaining modes should be assumed as "modulate" 2. many modes are clearly used over both RGB and Alpha channels, and they specify results for both RGB and Alpha channels.

    This means that the meaning of mode=["MODULATE","REPLACE"] is not clear.

    What did the authors meant by the word may in the sentence "may contain an additional blending mode"? Expecting two mode strings for one texture unit clearly contradicts the spec, expecting only 1 mode means that no mode specific for alpha channel is available. Doing some smart detection when to expect the next mode to be for alpha channel seems very risky — since the specification says absolutely nothing about it. Should I expect separate mode for alpha channel only when the texture in current unit has some alpha channel? This isn't as sensible on the 2nd look, since operating on alpha channel in multi-texturing makes sense even if current texture unit doesn't provide any (after all, alpha may come from previous unit, or constant).

    Not to mention that some modes are clearly not possible for alpha channel.

    Our interpretation: One string inside the mode field always describes behavior for both RGB and alpha channel. So one string inside mode field always corresponds to one texture unit, Ok?.

    To allow different modes for RGB and alpha channel, you should just write two mode names inside one string, and separate them by a comma or slash. Like "MODULATE / REPLACE". See the modes table in previous section for a list of all possible values.

  2. In Table 18.3 - Multitexture modes, "REPLACE" mode is specified as "Arg2", which makes no sense. Arg2 comes by default from previous unit (or material color), this is implicated by the sentence "The source field determines the colour source for the second argument". So mode "REPLACE" interpreted as "Arg2" would then 1. completely ignore current texture unit 2. contradict the normal meaning of "REPLACE", which is explicitly mentioned in specification at paragraph before this table ("REPLACE for unlit appearance"). An example with alpha (although ambiguous on it's own, more about this in previous point) clearly shows that "REPLACE" takes from 1st argument.

    Our interpretation: "REPLACE" copies the "Arg1" (that is, current texture unit values). IOW, it's equivalent to "SELECTARG1". To make it absolutely clear, it would also help if the spec would clearly say something along the lines "Arg1 is the current texture unit, Arg2 is what is determined by the source field (by default, it's previous tex unit (or mat color for 1st unit))".

  3. The meaning of "ADDSIGNED" and "ADDSIGNED2X" is unsure. Spec doesn't give the exact equation, and from the wording description it's not clear whether the -0.5 bias is applied to the sum, or each component.

    Note that no interpretation results in the output range of values in -0.5 ... 0.5, so it's not clear what is the "effective" range they talk about in "ADDSIGNED" spec.

    Our interpretation: I interpret it as "-0.5 bias is added to the sum", this follows OpenGL GL_ADD_SIGNED constant, so I guess this was the intention of the spec.

  4. Although some modes say explicitly what happens with alpha channel, some do not. This is especially visible with "subtract" mode, that will subtract alphas making resulting alpha = 0 for the most common situation when both textures have alpha = 1.

    Our interpretation: I interpret this all as operating on all RGBA channels the same way. Comparing with Octaga, results for "subtract" seem equal this way: with default alphas = 1, result gets alpha = 0.

    If you don't like this behavior, you can specify separate mode names for RGB and alpha channel, separating them by a slash. For example, "SUBTRACT / MODULATE" will subtract RGB but modulate alpha.

  5. It's not specified what channels are inverted by function="COMPLEMENT" value. Only RGB seems most sensible (that's what would seem usually useful), but it's not written explicitly.

    Our interpretation: I plan to treat it as "only RGB", that is not invert alpha channel. Although for now "function" field is not handled.

  6. Oh, by the way: the paragraphs for MultiTextureTransform (texture coordinates for channel 0 are replicated...) and MultiTextureCoordinate (identity matrices are assumed...) should be swapped in the spec :)

  7. Another note: MODULATEINVCOLOR_ADDALPHA mentions that another mode, somehow forgotten, should exist: MODULATECOLOR_ADDALPHA (that doesn't invert the color).

1.4. DDS (DirectDraw Surface) support details

DirectDraw Surface (DDS) image format is supported. A number of technical details about DDS implementation are below, but in short: we try to support all formats and all options of DDS in a standard way.

Implementation history:

Cube maps in DDS are supposed to be oriented as usual for DDS:

  1. Which means that they match Direct X "positive/negative x/y/z". For OpenGL rendering we swap positive/negative Y faces (because Direct X has left-handed coordinate system, see here for drawing of DirectX cube map images orientation and compare with OpenGL cube map orientation).

  2. It's also a different orientation then the one of X3D ComposedCubeMap specification (left/right, bottom/top, front/back, with bottom/top on Y axis; X3D orientation needs rotating left,right,front,back images by 180 degrees for OpenGL orientation).

Images in DDS are supposed to be written from top to bottom row, as is the standard in DDS. (One particular tool, AMD CubeMapGen, allows to invert rows of the DDS images to match OpenGL bottom-to-top ordering; don't use this — we expect rows ordered as is standard in DDS, top-to-bottom.) Internally, our engine just inverts the rows for OpenGL (yes, this is doable also for S3TC compressed images.)

Pixel formats supported:

  1. Absolutely all uncompressed non-float pixel formats are supported.

    Details:

    The formats that are currently loaded optimally are ABGR8, BGR8, AL8, L8. They translate to RGBA8, RGB8 etc. OpenGL formats (reversed order, as DDS color masks are little-endian). Popular ARGB8 and RGB8 are also loaded very fast.

    Grayscale (luminance) images are allowed. AL8 and L8 are optimized. Note that grayscale images aren't officially allowed by DDS docs, but at least GIMP-DDS plugin can write it (just sets all R, G and B masks equal, and doesn't set any of DDPF_RGB, DDPF_FOURCC, DDPF_PALETTEINDEXED8).

    Also only-alpha images are allowed (another undocumented DDS feature, GIMP-DDS can write it, for now they will result in grayscale(white) with alpha image).

  2. Compressed texture formats handled: DXT1, DXT3, DXT5 are supported. Texture with DXT1 is always treated like a texture with simple (yes/no) alpha channel (so it will be rendered with alpha testing) and DXT3 / DXT5 are always treated like a texture with full range alpha channel (so they will be rendered with blending).

    Both normal (2D) textures and cube maps may be compressed. (There is no compression possible for 3D textures — neighter DDS format allows it, nor do common graphic cards.)

  3. Float textures are for now not supported, so our DDS reader also doesn't support them.

If DDS file includes mipmaps, and mipmaps are required for texture minification filter, we will use DDS mipmaps (instead of generating mipmaps automatically). Works for all 2D, 3D, cubemap DDS files.

2. VRML 2.0 status

All nodes from VRML 2.0 specification are correctly parsed. The list below lists nodes that are actually handled, i.e. they do things that they are supposed to do according to "Node reference" chapter of VRML spec.

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.

Nodes listed below are fully (except when noted with TODO) supported :

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: Some general features not implemented yet are listed below. They all are parsed correctly and consciously (which means that the parser doesn't simply "omit them to matching parenthesis" or some other dirty trick like that). But they don't have any effect on the scene. These are:

3. VRML 1.0 status

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

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

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

4. Tests passed

4.1. NIST VRML test suite results

NIST VRML Test Suite results are below.

Each test was classified as "pass" only if it passed fully. Which is a good objective measure, but also means that many tests failed because unrelated features are not implemented. For example, don't be discouraged by many failures in PROTO category. Prototypes were 100% working in all tests, and I consider their implementation as practically finished. But unrelated things like missing Script support for ECMAScript prevented the tests in PROTO category from passing completely.

Cases are marked above as "success" (+) only if they succeed completely. The style of table below was modeled after similar page OpenVRML Conformance Test Results.

Node Group Node Test Number Result Notes
Appearance Appearance 1 +
2 +
3 +
4 +
5 +
6 +
7 +
8 +
9 +
10 + You have to set RGB Textures Color Mode -> GL_REPLACE to get 100% correct result.
11 +
12 +
FontStyle 1 +
2 +
3 + Note that the test looks strange because the X axis line starts at X = -200. This is an error in the test file.
4 +
5 +
6 - For horizontal text test passes, but vertical text is not implemented yet.
7 - Handling ECMAScript not implemented yet.
ImageTexture 1 +
2 +
3 +
4 +
5 +
6 +
7 +
8 +
9 +
10 +
11 +
12 +
13 - The texture top is not aligned precisely with text top.
14 +
15 +
16 +
17 +
18 +
19 +
20 - Like case 13: The texture top is not aligned precisely with text top.
21 +
22 +
23 +
24 +
25 +
26 +
27 +
28 +
29 +
30 +
31 +
32 +
33 +
34 +
Material 1 +
2 +
3 +
4 +
5 +
6 +
7 + You have to set RGB Textures Color Mode -> GL_REPLACE to get 100% correct result.
8 +
9 +
10 +
11 +
12 +
13 +
14 +
15 +
16 +
17 +
18 +
19 +
20 +
21 +
22 +
23 +
24 +
25 +
26 +
27 +
28 +
29 +
MovieTexture 1 +
2 -Audio from MovieTexture is not played yet
3 -
4 +
5 +
6 +
7 +
8 +
9 +
10 +
11 +
12 +
13 +
14 +
15 +
16 +The movie text.mpg is still (5 identical frames, according to ffmpeg, gstreamer and xine)
17 +
18 +
19 +
PixelTexture 1 +
2 +
3 +
4 +
5 +
6 +
7 +
8 +
9 +
10 +
11 +
12 -Texture top is not aligned precisely with Text top
13 +
14 +
15 +
16 +
17 +
TextureTransform 1 +
2 +
3 +
4 +
5 +
6 +
7 +
8 +
9 +
10 +
11 +
12 +
13 +Results look a little different, but matching precisely Xj3D and OpenVRML results.
14 +
15 +
16 +
17 +
18 +
19 +
20 +
21 +
22 +
23 +
24 +
25 +
26 +
27 +
28 +
29 +
30 +
31 +
32 +
33 +
34 +
35 +
36 +
37 +
38 +
39 +
40 +
41 +
42 +
43 +
44 +
45 +
46 +
47 +Results look slightly incorrect, but matching precisely Xj3D and OpenVRML results. I think this is a shortcoming of my GPU (ATI Mobility Radeon X1600), precisely transforming small textures may make small errors?
48 +
...here I skipped some tests, to be checked later...
Geometry Box 1 + This links to Text test, that passes (but has nothing to do with Box)
2 +
3 +
4 +
5 +
6 +
Cone 1 + This links to Text test, that passes (but has nothing to do with Cone)
2 +Again, tests linking to unrelated testcases for Box node (that pass)
3 +
4 +
5 +
6 +
7 +
8 +Unrelated Box test... (that passes)
Cylinder 1 + Unrelated Text test again...
2 +Unrelated tests for Box again...
3 +
4 +
5 +
6 +
7 +
8 +Unrelated Cone test...
9 +Unrelated Box test...
ElevationGrid 1 + Note that by default ElevationGrid is not smoothed (creaseAngle = 0), this is following the spec.
2 +
3 +
4 +
5 +
6 +
7 +
8 +
9 + The reference image of the test is bad. The result should be more obvious (whole rows of quads have the same normal), and it is — with our engine.
10 +
11 + Although we use two-sided lighting.
12 - Although we do generate smooth normals, they are not used since colorPerVertex forces us to use smooth shading.
13 +
14 +
Extrusion 1 +
2 + Reference images show the incorrect non-uniform scaling of the caps. We handle it right.
3 +
4 +
5 +
6 +
7 +
8 +
9 +
10 +
11 +
12 +
13 +
14 - While generally looks Ok, it seems that our triangulating algorithm can't handle this particular shape perfectly.
15 +
16 - This links to ElevationGrid creaseAngle test, that fails... Has nothing to do with Extrusion actually. (And we do handle creaseAngle on Extrusion correctly!)
17 +
IndexedFaceSet 1 +
2 +
3 +
4 +
5 +
6 +
7 +
8 +
9 +
10 +
11 +
12 +You have to set RGB Textures Color Mode -> GL_REPLACE to get 100% correct result.
13 +
14 +
15 +
16 +
17 +
18 +
19 +
20 +
21 +
IndexedLineSet 1 +
2 +
3 +
4 + (These tests have nothing to do with IndexedLineSet, they are for IndexedFaceSet.)
5 +
6 +
7 + (These tests have nothing to do with IndexedLineSet, they are for IndexedFaceSet.)
8 +
9 +
10 +
PointSet 1 +
2 +
3 +
4 +
5 +
Shape 1 +
2 +
3 +
4 +
5 +
Sphere 1 + Unrelated Text tests...
2 +Unrelated Box tests...
3 +
4 +
5 +
6 +
Text 1 +
2 +
3 +
4 +
5 -Text.length is not supported yet
6 -
7 -
8 -Text.maxExtent is not supported yet
9 -
10 +
11 +
12 -Texture mapping is a little incorrect, text is too small
...here I skipped some tests, to be checked later...
Misc EXTERNPROTO 1 +
2 +
3 +
4 +
5 +
6 +
7 +
8 - Currently, base URL for EXTERNPROTO is from the file where EXTERNPROTO is written, not from the file where it's instantiated.
9 - ECMAScript is not supported yet. Also, the DEF declaration inside a script causes known problem with cycles in VRML graph.
10 -
11 - Scripts are not supported yet.
12 -
13 +
14 +
15 +
16 +
17 +
18 +
PROTO 1 +
2 +
3 +
4 +
5 +
6 + (It links to unrelated Text test that works?)
7A + Result is Ok, but we do not handle SphereSensor, Sound, AudioClip nodes (yet).
7B - Static result seems Ok, but we do not handle VisibilitySensor (yet). Also Billboard is crude, although this is not noticeable here.
7C - Static result seems Ok, but we do not handle VisibilitySensor and Collision.collideTime is not generated (yet).
7D +
7E +
7F + Result is Ok, although actually we do not handle PlaneSensor (yet).
7G +
7H + Result is Ok, although actually we do not handle ECMAScript (yet).
7I +
7J +
7K +
8 - Although the tested features work Ok, there is a problem (unrelated to protos) with activating TouchSensor when SphereSensor is also enabled. We should activate them both simultaneously, currently only one (SphereSensor in this case, since it's first) is activated.
9 - Tested features work perfectly. But VisibilitySensor is not handled (yet), so animation doesn't start (you can replace it by e.g. ProximitySensor with large sizes, and animation will work).
10 +
11 +
12 +
13 +
14 +
15 +
16 +
17 +
18 +
19 +
20 +
... here I again skipped some tests ...
Special_Groups LOD 1 +
2 +Note that switching between Viewpoints in these tests has very strange VRML code. Namely there are interpolators with two equal keys (so they don't actually make any change, and this is correctly optimized in the engine). Moreover, they are connected to time sensors with 2 seconds cycle. This causes strange effects when clicking fast on various touch sensors, as many interpolators conquer to change the same Transform.position values. I'll emphasize: we handle it correctly, and optimize correctly, we have to evaluate simultaneous changes to the same field from various routes... The test is just strange, without any purpose.
3 +
4 +
5 +
6 +
Switch 1 + This is actually an Anchor bound-500 test, that passes. (Possibly, wget messed up my local copy of NIST tests... Online server with NIST tests is broken, so I can't check).
2 +
3 +
4 +
5 +
6 +
That's enough for now... I don't have time to check all the tests. If someone wants to do the work and do the remaining tests (and document results just like above), please contact us by vrmlengine-main mailing list.