Gzz Frontend: Vob subsystem

Vobs are the basis of Gzz's graphics system. As discussed elsewhere(XXX) they enable keyframe interpolation between unrelated views by associating keys from the structure with the elements of the scene.

The following diagram shows the logical structure of the Vob system; we'll go into the implementation details later.

vobs_overall

As seen in the diagram, the Coordinate systems form two intertwined structures: a DAG of transform parents and a tree of match parents. See the VobScene javadoc for details.

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

vobscene_overall

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

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.

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.