AUGE DEL KARATE DO

We have presented in the previous sections how Inventor and VTK components can be combined in various visualisations in VISSION. The two toolkits exhibit a certain resemblance, especially in

their dataflow and object-oriented architecture, as well as in the 3D rendering components provided. However, they are designed with different application domains in mind. Inventor’s goal is to provide general-purpose 3D scene modelling and animation. VTK focuses mostly on support for scientific visualisation applications. The main differences between the two toolkits are summarised as follows.

Inventor’s data model covers the description of a 3D scene. The provided elements are geomet- ric objects, transforms, and rendering and viewing properties. VTK’s data model covers more data types common in the scientific visualisation community. It consists of datasets and process objects, which represent respectively various data types and data processing operations encoun- tered in scientific visualisation.

Inventor offers high-level, specialised components for 3D viewing and direct manipulation, as well as some GUI components. In contrast, VTK provides only some basic primitives such as 3D cameras and simple point-on-surface pick functions, and no GUI components.

Inventor has a special dataflow network traversal policy in which several actions that share a global state are applied over the whole scene graph. Unconnected nodes can still influence each other by modifying the global state during the traversal, such as material or transform nodes which affect all nodes encountered after them during a traversal. The overall Inventor network traversal mechanism is quite complicated. Several action types can be applied during a traversal, and the encountered nodes can respond in several ways to these actions [116]. In contrast, VTK has a simpler dataflow mechanism in which no global state is maintained. Nodes communicate only explicitly via data connections. There is a single traversal action, which consists in calling the components’ update operation in a demand-driven fashion.

Inventor’s rendering mechanism is highly tuned for speed by using several internal scene graph transformations and caches. In contrast, VTK’s rendering components directly call the under- lying graphics library, e.g. OpenGL. VTK has a lower overall rendering pipeline throughput, especially for large scenes.

Inventor is commercial software which has to be separately purchased for every new platform. In contrast, VTK is freely available on a wide range of systems.

VISSIONintegrates both Inventor and VTK, so application designers may freely decide whether to use Inventor or VTK components for a specific task. On high-end graphics workstations that have an In- ventor installation, one could use the fast Inventor components for the 3D rendering and direct ma- nipulation, instead of the similar VTK components. On machines where Inventor is not available, one would use VTK to construct slower but functionally similar pipelines.

We shall illustrate the above by a visualisation provided in the VTK standard example set. In this example, a scalar quadric function defined on a 3D domain is visualised by means of several isosur- faces. The network (Fig. 7.13 a) starts with a moduleVTKQuadricwhich defines a quadric function of the form ! " # " $ % & ' ! ( ) * # ( ) + $ ( ) , ! # ) - # $ )  ! $ ) . , where the coefficients' / . are input by the user. Next,VTKSampleFunctionsamples the function onto a regular grid. Isosurfaces are extracted from the sampled dataset by using the marching cubes algorithm [60]. The extracted isosur- faces are next input in two different rendering pipelines. The left pipeline uses Inventor components and end with the already describedIVSoExaminerViewer. (Fig. 7.14 a). The right pipeline uses only VTK components and ends with an interactive 3D viewerVTKViewer(Fig. 7.14 b) which we have built by enhancing the basic VTK viewer with GUI controls similar to the ones provided by the In- ventor viewer. As seen in Figs. 7.13 a and 7.14, the VTK and Inventor rendering pipelines and viewers

are almost identical in structure and functionality. End users and application designers can thus con- struct and utilise visualisation applications with the rendering pipeline which best suits their current platform or availability constraints.

VTK pipeline Inventor pipeline VTKPolyDataMapper IVSoSeparator VTKPolyIVMapper a) b)

Figure 7.13: Visualisation combining Inventor and VTK. Network (a) and adapter class (b) In order to combine the VTK and Inventor pipelines, we had to write a simple data adapter class VTKPolyIVMapperof around 120 C++ lines which translates VTK’s geometric dataset into the equivalent Inventor representation. The design of this adapter is a good example of situation in which multiple inheritance is needed (Fig. 7.13 b). On one hand, the adapter inherits from the InventorIV- SoSeparatorcomponent, which makes it connectable to the Inventor scene graph, thus viewable. On the other hand, the adapter inherits from the VTK componentsVTKPolyDataMapper, which makes it take part to the VTK dataflow mechanism by reading a VTK data set. In order to merge the two toolkits,VTKPolyIVMapperdefines its own update routine which translates the VTK polygonal data set delivered by its VTKPolyDataMapperparent, translates it to an Inventor representation, and inserts this representation into itsIVSoSeparatorparent. As pointed out by Gamma et al. [37], class adapters are the mechanism of choice for connecting independently developed class hierarchies, such as the VTK and Inventor toolkits. Constructing such an adapter would however not have been possible without multiple inheritance , if we do not wish to modify any of the two involved toolkits. In our case,VISSIONnatively supports multiple inheritance, so the coupling of the VTK and Inventor toolkits was done without any problems.

Combining VTK and Inventor components inVISSIONis not limited to having alternative render- ing back-ends. One can for example steer the input of a VTK computational pipeline with the out- put of a manipulator acting on its Inventor rendering back-end, similarly to the network depicted in Fig. 7.12 a. The VTK and Inventor components may have their own data communication mechanisms and update policies among themselves and still perfectly cooperate and be freely intermixed in aVIS- SIONnetwork. For example, in the visualisation described above the Inventor components use their own built-in event-driven update mechanism and special scene graph traversal, while the VTK ones use VTK’s own demand-driven dataflow policy. The two mechanisms are merged transparently as both VTK and Inventor components interface withVISSIONvia the same metaclass layer described in Chap-

ter 3. Combining Inventor and VTK components would not have been possible without the presence of the meta-layer abstraction (e.g. directly in compiled C++) as no common component dataflow in- terface would have been available.

a) b)

Figure 7.14: Inventor (a) and VTK (b) 3D interactive viewers