Frames and Leafs

This document is part of a collection of VRML2.0 history at
1st December 95, 9pm
Mitra <> Gavin Bell 

Review status

Note to other reviewers. Please send additions, to me, or changes. I'll cut and paste them into the document with your name attached.

Main changes since previous version(s)

Outstanding Major Open Issues

Separators and Groups NOT

This is a proposal to replace Separators and Groups with a system that meets these goals:


This proposal removes Separators and Groups, and replaces them with Frames and Leafs. A scene graph consists of a hierarchy of frames, with Leafs at the leaf nodes. State which accumulates down the hierarchy (basically only transforms is kept at the Frame level). Properties and Geometry are kept at the Leaf level.

We have the following concepts:

Open issue
While the Leaf may have multiple Geometry nodes specified - e.g. an IndexedFaceSet and Coordinate's and Normals and a Cube, it may only have one each of the Properties nodes.

It should be easy to write a Perl, or QvLib program that transforms VRML1.0 to this new scheme.

Where do nodes go

Nodes fit into several categories:
  1. Transforms that are incorporated into Frame, and no longer valid
  2. Properties that may occur at most once in an Leaf

  3. Open
  4. Geometries that may occur multiple times as children of an Leaf
  5. Open: While we are all agreed on these being the "Geometry" nodes, see Overview for arguments as to how they should appear syntactically.
  6. Nodes that may occur multiple times as children of a Frame
  7. Open
  8. Nodes that may occur anywhere
  9. Nodes that are no longer valid
  10. Nodes that act as a Frame, i.e. they are children of Frames, and may contain Frames or Leafs
  11. Nodes that may occur at most once
  12. Open

Interesting issues

Open DEF & USE and Reuse of textures, materials etc

Open Animating Textures

Open Defaults

An Leaf with an no properties, is identical to an Leaf with every property set to its default. e.g:
Leaf { }
Leaf { Material {} Texture2 {}


What can be prototyped in this scheme.

Open Attaching behaviors

Note: This issue depends on the outcome of behavior proposals, and deciding it shouldn't be required before moving this proposal forward.


What can be switched? Switches are equivalent to Frames, i.e. they can switch between Leafs or Frames which are their children, but cannot switch between Properties. Since changing a switch requires a behavior anyway, then that behavior can as easily either set the relevant property directly, or switch between two Leafs.

Open WWWInline


Sensors, and/or EventHandlers, should be attached to children of Frames or Leafs, with the semantic being that they are sensing all the children of the Frame. They should not have children. The goal of this, is that it allows multiple event handlers to be attached to a single peice of the scene graph, and also allows removal or addition of Sensors without changing the hierarchy of the scene graph.


Open Interpolators

Open Adding New Properties