Design of LibVob

Design of the C Design of LibVob C Design of LibVob C Design of the C Design of LibVob C Design of LibVob C design_navigation

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

UML: vobs_overall_1

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.

Vob Transform Design of the C Vob Transform Design of the C vobs_overall_2

Notable new points are

Transform Transform vobs_overall_transforms

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


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:

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.

VobScene VobMap VobCoorder VobMatcher Vob Transform VobScene VobMap VobCoorder VobMatcher Vob Transform vobscene_overall

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

VobScene VobMap VobMatcher VobCoorder View VobScene VobMap VobMatcher VobCoorder View vobsceneseq

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.