Design of LibVob

The goal of the LibVob toolkit is to allow interpolation between independently programmed views as well as drawing 'cross-cutting' connections between objects in different places of the view hierarchy. (For example, a connection between objects in two different windows would be 'cross-cutting' as it connects two different places in the hierarchy.)

This distinguishes the Vob system from normal scene graphs: instead of one global scene graph, there are keyframe scene graphs. After each discrete user action (like a key press or mouse click), a new scene graph is generated by the user-specified view. Then, the previous keyframe is animated into the new keyframe to allow the user to keep track of all changes. The animation is governed by keys associated with the visible objects; an object in the first scene graph is animated to an object in the second scene graph if both have the same key. The keys are taken from the same underlying model (for example, they could be cells in a spreadsheet) and enable two independently developed views to be interpolated to each other (for example, two different ways to render spreadsheet data in a graph).

Continuous user actions (e.g. zooming/panning with the mouse) are treated more conventionally by editing the parameters of the current keyframe scene graph.

Example using an early version of libvob

To clarify, let's have an example using the first version of the Vob design. This version was considerably more limited than the current version but may be easier for grasping the essential concepts. In the early version, the structure of a keyframe was simply

Two keyframes were matched by directly matching Vobs with the same key.

For instance,

XXX Example: two vobscenes, two interpolated vobs and some non-interpolated; show "match" relations

In this case, the vob A is animated to the vob B ...

The modern design: Separation of concerns

While the above model already demonstrated the basic idea of vobs, it was too limited for most uses. Various extensions were tried until the current one was found.

Notable new points are

Vobs may be reused between vobscenes. This greatly helps performance on systems (e.g. Kaffe) where garbage collection has not yet been optimized enough.
Interpolation is handled by creating temporary Transforms, the Vobs no longer need to worry about anything except drawing themselves to a given coordinate system.
Transforms can be more general since they are not fixed to the Vobs:

Transforms can depend on other transforms (the transchild - transformparent relationship above). This is another generalization of scene graphs which are usually just trees. For example, XXX nadir
Key matching is also hierarchical, but the hierarchy is separate from the transform hierarchy. XXX example

The Coordinate systems form two intertwined structures: a DAG of transform parents and a tree of match parents. See the VobScene javadoc for details.

Interpolation

An important reason for the Vob construction is interpolation: it is possible to smoothly animate between Vobscenes generated by independent views. The interpolation is based on the keys of the coordinate systems. The two steps are:

Match, starting from the root coordinate system (0), coordinate systems whose parents have been matched and which share the same key.
For all coordinate systems for which a match was found, form an interpolating coordinate system and use that for rendering. It is optional whether non-interpolating coordinate systems will be rendered or not (experience shows that it's good to start rendering them at some small time before the animation ends).

Sometimes it is desirable to change the interpolation behaviour for some coordinate systems. An example is a "main" coordinate system surrounded by buoys, and interpolation between a buoy and the main coordinate system. It is not desirable to adjust the keys but to rather have the main coordinate system have a static key and change the interpolation behaviour of the buoys.

The Java implementation

In the Java implementation CoordinateSystems are represented by integer indices to various arrays due to efficiency reasons. If we were using a stronger language such as C++ where making the CoordinateSystem its own class in a template wouldn't cost us, we certainly would do so.

The class diagram of VobScene and related classes is shown below. The "pseudoclass" stereotype refers to the above array implementation of the coordsys "class"es.

The diagram is slightly convoluted (feel free to improve the layout); the central class is a VobScene, which is a facade for the whole system of vobs and coordinate systems. It contains three objects which implement the VobMap, VobCoorder and VobMatcher interfaces. These manage various relationships of the Transform.

The construction of a VobScene by a view goes as follows:

There are two modes of calling: either through the VobScene as a shorthand for the most common cases, or directly through to the VobCoorder and VobMap members.

Rendering a VobScene can happen in two ways, depending on whether OpenGL or AWT is being used. OpenGL is described in GLRenderables.