Some VRML/X3D TODO items, with respect to VRML/X3D specs:

- Saving to VRML known problems:
  - When saving external prototype, we save all fields, always, not only
    those specified in original file. In effect, this means that even fields
    that were not specified in original file (so should have default value
    specified by proto) will be specified in new file, with default value 0.

- demo_models adjust to EXTERNPROTO/PROTOs more

- finish checking NIST tests

- KambiTriangulation should be fixed, to go to Appearance.triangulation?

------------------------------------------------------------------------------
For scripting we will also have to implement a tricky feature, that is currently completely ignored because you cannot access it without scripts:

Scripts can "read" their own eventOuts. VRML 97 spec explicitly says this:
"EventOuts defined in the Script node may also be read; the returned value is the last value sent to that eventOut."

This is also the reason for X3D spec about interpolators:
"If an X3DInterpolatorNode value_changed outputOnly field is read before it receives any inputs, keyValue[0] is returned if keyValue is not empty. If keyValue is empty (i.e., [ ]), the initial value for the respective field type is returned (EXAMPLE  (0, 0, 0) for SFVec3f); see 5 Field type reference for initial event values."
(VRML 97 spec has exactly equivalent wording.)

This is also the reason why chapter about fields in VRML 97 talks about
"The initial value of an ... eventOut is ...."
and similar X3D spec talks about "default field values".

A simple implementation can be imagined easily:
- Just create TVRMLEvent property
    LastValue: TVRMLField;
  Never nil.

- Initially, value of LastValue is the "initial value" as per VRML spec. We could make CreateUndefined specification explicit that "CreateUndefined sets this initial value", this is already true in most cases anyway (as default values are like 0, 0.0 etc.).

- Each TVRMLEvent.Send call just copies Value to LastValue. This seems trivial, but actually has some corner cases:
  - Copying events with large values, like typical TMFVec3f value, seems like a waste of memory and time. Parameter like OwnsValue may be useful for TVRMLEvent.Send, if @true then it can just keep the reference, no need to copy actual value (for example, interpolator like CoordinateInterpolator create new TVRMLField instances anyway; currently they are simply freed; could be just passed to TVRMLEvent, and then TVRMLEvent would just keep the reference).
    But still in some cases OwnsValue = false (like when exposedField's eventOut is fired, this is currently very efficient as just field's reference is passed) copy will have to be made, so we waste memory, and we waste time on copying it around. Possibly the script will never use this feature --- but we will have to keep track of LastValue anyway, because we never know.
    Hm, but this only for output fields, and that's why things like coords etc. do not have output events? So maybe it's not really a problem?
  - Events with SFNode / MFNode types will keep references to nodes this way --- this can easily create loop references, as the routes are arbitrary, so a node may e.g. receive an SFNode event with Value set to Self. By keeping Self in LastValue, we create circular reference.

----------------------------------------------------------------------------
- Redundant routing is ignored. If a VRML file repeats a routing path, the second and subsequent identical routes are ignored. This also applies for routes created dynamically via a scripting language supported by the browser.
  Currently, we don't honour above. Multiple routes will cause multiplication of sending event.
------------------------------------------------------------------------------

X3D:
X3D TMFImage field type (hm, not used for now by *any* node in X3D spec)

------------------------------------------------------------------------------
addChildren/removeChildren test (cannot test now, as nothing can generate
SFNode/MFNode out events now)

invalid VRML file can produce mem leaks and hang the engine using addChildren
(e.g. add self as it's own children). See
TNodeX3DGroupingNode.EventAddChildrenReceive implementation.

test implemented events:
- IndexedLineSet:set_colorIndex, set_coordIndex
- IndexedTriangleFanSet,  IndexedTriangleSet, IndexedTriangleStripSet: set_index
- Extrusion:  set_crossSection, set_orientation, set_scale, set_spine
- IndexedFaceSet: set_colorIndex, set_coordIndex, set_normalIndex, set_texCoordIndex
------------------------------------------------------------------------------
The way of rendering Background and TextureBackground by TBackground
is bad. It's not intergrated with rest of rendering, so it cannot
render arbitrary VRML textures, it depends on static TImage instances
at creation time. Also it cannot use VRML renderer cache (which would
at least speed up TBackgroundGL recreation, although this recreation
should also be less often needed).
Also, it's static after creation. Any change to
transformation causes costly recalculation of display list.

This prevents clean TextureBackground implementation (that would support
MovieTexture to animate sky).
------------------------------------------------------------------------------
LoadSensor - not so trivial, delaying for the future.

Also auto-turn off boundingbox calculation? this also can hurt us now...
Seems to not be needed now, delaying for the future.

Anchor finishing touches:
- Anchor.paramater handle?
- NewViewpointName for anchor should be searched with run-time name scope of Anchor (for NewRootNode = nil) (in what scope should it be searched for NewRootNode <> @nil? NewRootNode name scope (omits protos, inlines etc.), or just whole NewRootNode?)
- when switching to new node, new NavigationInfo should be bound:
  headlight from new navigation should be updated.
  (actually, this is not specific to Anchor.)
