GAUDI User Guide

Chapter 15
Visualization Facilities

15.1  Overview

In this chapter we describe how visualization facilities are provided to the applications based on the Gaudi framework. We present how we interface the physics event data objects, detector components or statistical objects to their graphical representation. One example of an application that uses the visualization services is an event display program. With this program we display graphically the event data from files or being acquired by the data acquisition. Another example could be an interactive analysis program that combines in the same application histogramming or manipulation of statistical entities, event display, and full interactive control by the end user of the data objects and algorithms of the application.

In the current release, these visualization services are at the level of a prototype. We have implemented the mechanism of converting event and detector objects into their graphical representation and built one example application. This application can serve as a proof of concept and can also be used to help in the development of physics algorithms (e.g. pattern recognition) or in the verification of the detector geometry.

15.1.1  The data visualization model

The Gaudi architecture envisaged implementing data visualization using a similar pattern to data persistency. We do not want to implement visualization methods in each data object. In other words, we do not want to tell an object to "draw" itself. Instead we would implement converters as separate entities that are able to create specific graphical representations for each type of data object and for each graphical package that we would like to use. In that way, as for the persistency case, we decouple the definition and behaviour of the data objects from the various technologies for graphics. We could configure at run time to have 2D or 3D graphics depending on the needs of the end-user at that moment.

Figure 21 illustrates the components that need to be included in an application to make it capable of visualizing data objects. The interactive user interface is a Service which allows the end-user to interact with all the components of the application. The user could select which objects to display, which algorithms to run, what properties of which algorithm to inspect and modify, etc. This interaction can be implemented using a graphical user interface or by using a scripting language.

The User interface service is also in charge of managing one or more GUI windows where views of the graphical representations are going to be displayed.

Figure 21 Components for visualization

 

The other main component is a Conversion Service that handles the conversion of objects into their graphical representation. This service requires the help of a number of specialized converters, one for each type of data object that needs to be graphically displayed. The transient store of graphical representations is shared by the conversion service, together with the converters, and the user interface component. The form of this transient store depends on the choice of graphics package. Typically it is the user interface component that would trigger the conversion service to start the conversion of a number of objects (next event), but this service can also be triggered by any algorithm that would like to display some objects.

15.2  Using the GaudiLab services

The current implementation of the user interface service is based on the Open Scientist suit of packages. Some documentation of these packages can be found in http://www.lal.in2p3.fr/OpenScientist. The following is the list we are using for implementing the xmLabSvc.

The Lab package proposes various graphical user interface to handle an interactive session. Under UNIX we use xmSession that is a direct Motif user interface. On NT it is planned to use the native windowing system, the win32Session (not yet available in the current release).

15.2.1  Interacting with it

3D examiner viewer controls are :

15.2.2  Writing graphic converters

The role of each converter So<xxx>Cnv is to produce an Open Inventor node that represents the object. The following fragment of code shows how this is done for the geometry of a detector element.The code has been simplyfied to be more illustrative. The 3D graphical objects that are created are standard OpenInventor objects (in bold).

 

Listing 42 Fragment of SoDetectorElementCnv
29: StatusCode SoDetElemCnv::createRep(DataObject* aObject,IOpaqueAddress&*)
30: {
31:   DetectorElement* de = dynamic_cast(aObject);
32: ILVolume*    lv = de->geometry()->lvolume();
33:   SolidBox*    box = dynamic_cast(lv->solid()->coverTop());
34:
35: SoSeparator* separator = new SoSeparator;
36: SoDrawStyle* drawStyle = new SoDrawStyle;
37: SoMaterial*  material      = new SoMaterial;
38:   separator->addChild(drawStyle);
39: separator->addChild(material);
40:   // set drawing styles
41: drawStyle->style.setValue(SoDrawStyle::LINES);
42: drawStyle->linePattern.setValue(0xFFFF);
43:   material->diffuseColor.setValue(SbColor(0.,1.,0.));
44:
45: // Code related to the transformation
46:   SoTransform* trans = new SoTransform;
47:   ...
48:   separator->addChild(trans);
49:
50: SoCube* cube = new SoCube();
51: cube->width = box->xHalfLength() * 2;
52: cube->height = box->yHalfLength() * 2;
53: cube->depth = box->zHalfLength() * 2;
54:
55: separator->addChild(cube);
56:   m_pSo->addNode(separator);
57:   return StatusCode::SUCCESS;
58: }