Gaponenko, I A

CERN Document Server

The SND Interactive 3D Event ViewerI.V. Gaponenko BINP, Novosibirsk, RussiaAbstractThis work describes the interactive 3D event viewer. The viewer aims to display the dataacquired from SND (Spherical Neutral Detector) [1]. It reads and displays the experimentaldata objects specified in the COCHA [2] package format. The viewer is based on the OpenInventor object-oriented toolkit [3]. Local interactivity, provided by Open Inventor, allows auser to change the view of the displayed event rotating and zooming it. Additional featuresgive the user a possibility to review information about various parts of the detector systemsand the displayed event. The displayed event can be saved either in the VRML or OpenInventor format file. The viewer is part of the SND 3D event display.Keywords: SND, Open Inventor; event display; VRML.1 IntroductionThe interactive 3D event viewer is based on a three-dimensional graphics model. It uses real three-dimensional geometric description of the detector and events acquired from it. The metric right-handed coordinate system is used to define the geometry and represent it as the scene graph, that iseventually drawn on the screen. All angles are specified in radians. To construct the detector scenegraph, which is a complicated one, the Open Inventor file format is used to read some parts of thedetector description from a file and some from a string in memory. The other parts are defined by theprogram. The Open Inventor examiner viewer is used to render the scene graph. The viewer allowsone to interactively change the view of the scene graph by click-dragging the mouse buttons in thewindow or using the various controls along the window border (e.g., zoom). The three-dimensionalscene is transformed automatically before being drawn onto a two-dimensional screen to show aparticular view of the scene graph. In other words, the viewer provides all features, that are calledlocal interactivity.The viewer has been written to investigate the 3D Open Inventor [3] based approach for implementingthe event display. This investigation is based on the real experiment and the real data is visualised.Since the most difficult part in this task is the description of the detector geometry, the SND geometryhas been chosen as the relatively simple one.Since the 3D visualisation demands large amount of the hardware resources (CPU, memory, etc.),one of the aspects to investigate has been the interactive response of the viewer. The idea has beennot only to run the viewer on special SGI workstations, but also on the ordinary X-terminals withoutGLX extension. The investigations show that there are many useful features in the Open Inventortoolkit, which allow us to increase the performance of the viewer. One of such features is a possibilityto specify various levels of detail for the same object. The SoLevelOfDetail node usage is discussedbeneath. The viewer performance has been tested on various computers to define the requirementsof the hardware needed for this purpose. The various aspects of the approach are discussed and theresults of this investigation are presented in this article. If the results seem to be satisfactory, theapproach might be used for detectors with more complex geometry.2 The Detector Overview and Events SignatureThe experiments with SND have been carried out at the collider VEPP-2M in Novosibirsk since1995. At present, before the beginning of the DANE era, VEPP-2M is the only collider in the worldoperating in the energy range of , !, and  vector mesons. SND is a general purpose nonmagnetic E-mail: I.V.Gaponenko@inp.nsk.sudetector. It consists of the tracking system, three spherical layers of NaI(Tl) crystals, and an outersystem of streamer tubes and plastic scintillation counters (Fig. 1). The NaI(Tl) calorimeter consistsof 1632 individual crystals of 3.6 tons total weight. The calorimeter thickness in the radial direction is35 cm 13.5X0. The angular size of each crystal is 90. The solid angle coverage of the calorimeteris 90% of 4. For trigger needs the calorimeter crystals are logically organized into ”towers”. Atower consists of counters located within180 interval in the same polar and azimuthal directions in allthree layers. The number of counters in a tower is 12 at large angles and 6 in the regions, close to thebeam. In addition to signals from individual counters each tower produces a total energy depositionanalog signal and two trigger signals. The tracking system consists of two cylindrical drift chambers.Both chambers are divided into 20 jet-type cells in azimuthal plane. Each cell contains five sensitivewires. The longitudinal coordinate is measured by the charge division method with an accuracy of3mm. In addition, cathode strip read-out for inner and outer layers provides the improvement of thelatter value to 0.5mm. The muon/veto system consists of plastic scintillator counters and streamertubes.345126109713128110 20 40 60 80 100 cmFigure 1: The SND Detector Overview: 1 - collider beam pipe; 2 - drift chambers; 3 - coincidence counter; 4- fiber lightguides; 5 - photomultipliers; 6 - NaI(Tl) crystals; 7 - phototriods; 8 - iron absorber; 9 - muon tubes;10 - 1cm iron plate; 11 - muon counters; 12 - magnetic lenses; 13 - bending magnets.The physics program for SND experiment includes radiative decays, OZI and G-parity suppresseddecays, electromagnetic decays, e+e  annihilation into hadrons, test of QED, search for rare KSand  decays and C-even reactions. Typically there are no more then seven or ten particles in eachevent.3 Requirements for a Visualisation SystemA visualisation system, or event display, should meet the following requirements. It should be: interactive, so that the displayed event can be zoomed and rotated easily; flexible (modular design):– to integrate it in the data acquisition system;– to easily add new functionality in the future, when it’s necessary;– to integrate it with the data processing system; suitable for debugging the reconstruction and selection algorithms; suitable for testing the detector systems; able to provide all the information about the displayed event and the detector systems,although some information might be hidden, and displayed only by the user request.These are probably the most important, but incomplete, requirements for the detector visualisationsystem. From amongst these requirements, the most important one is the task of the debugging ofreconstruction algorithms and event selection procedures. Obviously, integration of the visualisationsystem with the reconstruction and analysis parts provides faster debugging facilities. That is whythe system should be flexible. The visualisation system should also easily allow the user to scan thedetector data event by event, displaying vertices, tracks, and so on. The visualisation system shouldalso be used to extract some interesting or rare events in a file with portable format to provide somefacilities to publish the experiment results. That is why the visualisation system should have theoutput facilities.One of the important parts of the system is its ability to visualise the detector systems, which are notoperational, and provide additional information about them, in order to check the detector systems.This is particularly essential for detectors with more complex geometry.4 Why Open Inventor?Firstly, both the detector and the event must be split into logical parts (objects), whose behavior issimilar in particular cases. Physical entities of the detector (crystals, wires, etc.) are considered asobjects also. This is so obvious, that there is no need to be discussed here. The approach of splittingthe detector into the logical parts fully corresponds to the object-oriented model. That is one ofthe reasons why visualisation should be done with the object-oriented tools, such as Open Inventor.Being very intuitive, this approach gives us flexibility to change the properties of the objects and easesthe addition of new objects. Object-oriented methodology is based on the physical and mechanicalworld we live in. Conclusion 1: It is object-oriented.Secondly, one of the hardest task is transformation of the 3D object to the 2D display. Even ifthe definition of the objects is three-dimentional, which is very convenient in itself, the renderingof these objects should be done also by the toolkit, so that we do not need to implement complextransformation algorithms. Conclusion 2: It provides 3D object description and automatic transformation to the2D screen.Thirdly, the interactive manipulations, such as rotation, zoom, etc., allow one to change the view ofthe rendered objects. The interactive selections, picking, etc. provided by Open Inventor, enablesus to include all information and to display it only when required. Conclusion 3: It is interactive.Finally, based on the requirements of a visualisation system, it has been necessary to find the mostconvenient solution. The 3D graphics approach for event visualisation seems the most natural forthis task. The Open Inventor toolkit provides all we need in this situation. Open Inventor is anobject-oriented 3D toolkit offering a comprehensive solution to interactive graphics programmingproblems. It defines the standard file format for exchanging 3D data among applications. Moreover,it serves as the basis for the VRML (Virtual Reality Modelling Language). Inventor objects includedatabase primitives, including shape, property, group, and engine objects; interactive manipulators,such as handle box and trackball; and components, such as the material editor, directional lighteditor, and examiner viewer. All information about the 3D objects - their shape, size, colouring,surface texture, location in 3D space - is stored in a scene database. This information can be used ina variety of ways. Changing the objects in the scene, adding to the scene, and interacting with theobjects is a simple process, because such changes are the part of Inventor’s interface, and becausethey are anticipated by Inventor’s basic design. The objects in the scene can be picked, highlighted,and manipulated as discrete entities. This programming model is intuitive, and hence, convenient.5 The Visualisation System Structure5.1 Nodes of the Detector Scene GraphFigure 2: A Part of the Scene Graph for the SND DetectorOpen Inventor is a fairly large and very general system. To implement the viewer only several featuresof it has been used. The most difficult part of the visualisation system is the detector geometrydefinition. Open Inventor facilitates the process, by supporting the specification of the detectorgeometry via an Open Inventor format file and a string in memory. This is an example of the definitionvia the Open Inventor ASCII file:#Inventor V2.0 ascii#Top level = singe node gathered into SeparatorSeparator {#Coordinate3 node defines the eight points of a NaI(Tl) crystal.Coordinate3 {point [0 0 0, #First point, index 01 0 0, #Second point, index 1...0 1 1 #Eighth point, index 7]}#Define the front of the crystalIndexedFaceSet {coordIndex[ 4, 5, 6, 7 ] #Four points in front}#Define the other sides of the crystal...}Open Inventor defines a set of objects useful for doing 3D graphics - nodes. The node is the basicbuilding block used to create a 3D scene database in Open Inventor. The nodes defined in thedetector are crystals, wires, and so on. Nodes are arranged in the hierarchical structure - scenegraphs. Scene graphs are more then just a collection of nodes: the scene graph defines an orderingfor the nodes. Nodes earlier in the scene graph can affect nodes that appear later in the scene. Forexample, Rotation or Material affect nodes after in the scene. The group nodes are separator,level-of-details, and switch. The separator group nodes of the detector are the drift chambers, thecalorimeter, the muon system. The separator nodes limit the effects of properties. It allows parts ofthe scene graph to be functionally isolated from other parts. A node can belong to more then onegroup. For example, a crystal belongs to a calorimeter and a tower (Fig. 2).The elements of the detector correspond to the nodes of the scene graph. Each element of the detectoris defined as a separate node: each crystal, each wire of the drift chambers, etc. is presented in thescene graph as a shape node. The nodes are joined in groups. Some of these groups are definedphysically, for example, wires of a drift chamber belong to one group. Some of the groups are definedlogically, for example, crystals of the calorimeter that belong to a tower.Groups in the scene graph are: drift chambers that join the wires, towers that package some crystals(see above), the calorimeter that join all the crystals, etc. The group nodes are containers that collectnodes into the detector scene graph. The nodes are named to refer to them elsewhere. That is veryconvenient, since the crystals in the detector are named also. Each crystal has a unique number,which defines its position relative to the other crystals.5.2 Data FlowThe data acquired from the SND detector by its DAQ system are stored in the tape archives (Fig. 3)as raw events. At the next stage of processing these data are read and processed by reconstructionFigure 3: Simplified Data Flow Chartand event selection programs using the calibration information and then are written back to the tapearchives as reconstructed events. The formats of these files are quite similar with the difference thatreconstructed events carry additional information coming from reconstruction procedure, such asparticles, vertices, and tracks (Fig. 4).Figure 4: Raw/Reconstructed EventsThe typical length of the event record is about 1Kbyte. Each record has a number of informationbanks - one per detector subsystem, plus the reconstruction output mentioned above. The eventconverter is written to read experimental data from the archive file to create the Open Inventordatabase.5.3 The Viewer: What can it do?Figure 5: The 3D Interactive Event ViewerThe visualisation system consists of two windows (Fig. 5). One of them is the examiner viewer.It allows a user to rotate and zoom the displayed event. Another is a control panel that providesevent control facilities: the user can display additional information about the event and the detectorsystems, or save the scene graph in a file. There are two formats for output files supported in currentversion: VRML and Open Inventor (binary or ASCII). Various controls in the second window allowthe user to remove or make transparent some displayed parts of the detector or to get additionalinformation about the event.6 Current StatusIn the current implementation of the viewer the distributed client-server scheme has been chosen(Fig. 6). This choice has been motivated by the available hardware and software. This approachallows us to use any X-terminal with or without the GLX extension, because the MESA shared library,which emulates OpenGL, is installed on the host computer. However, there are drawbacks in thisscheme. One of them is high network traffic, which can rise by up to tens of percent if the MESAlibrary is used. The viewer has been tested on the SGI Server CHALLENGE-L. As a benchmark therotation of the detector depending on the rendered area size and the number of rendered nodes hasbeen chosen. The results are presented in Table 1. The time is measured with an accuracy of 1s.The result in the third case is almost the same as in the second case, because the SoLevelOfDetailnode is used.7 ConclusionThe results of the investigation show that Open Inventor fully matches the task of event visualisation.However, new nodes aimed at a particular situation (for example, SoNaIcrystal shape node, thatFigure 6: The Distributed Client-Server SchemeWhat is Displayed Rotation Time (s)Render Area Size1024x800 600x400 300x200Drift Chambers and Event 6 5 2Calorimeter and Event 7 6 3Calorimeter, Drift Chambers, and Event 7 6 3Event and Active Elements of the Detector 4 3 1Table I: Performance of the viewer.would properly present the shape of calorimeter crystals) are necessary. Creating these new objectsand methods requires tthe extension of Open Inventor by subclassing.The issue seems to be obvious. The more complex the geometry to be rendered the more powerfula workstation is needed. However, the performance of the viewer is quite satisfactory, if the visiblepart of the scene graph is restricted and a possibility to add invisible parts of the detector and eventsis left to the user. It should be carefully analysed in each particular case well before implementingthe Open Inventor based event display.AcknowledgementsI wish to thank M.S. Dubrovin and I.A. Gaponenko for valuable remarks and multiple discussions.References1 M.N. Achasov et al., Status of the experiments with SND detector at e+e- colliderVEPP-2M in Novosibirsk, Preprint BudkerINP 96-47 (1996).2 V.N. Ivanchenko, COCHA - the Data Structure Management Package, PreprintBudkerINP 94-25 (1994).3 The Inventor Mentor, Addison-Wesley Publishing Company.4 The Inventor Toolmaker, Addison-Wesley Publishing Company.5 The Open Inventor C++ Reference Manual, Addison-Wesley Publishing Company.6 The OpenGL Programming Guide, Addison-Wesley Publishing Company.

The SND interactive 3D event viewer

Abstract

Similar works

Full text

Available Versions

CERN Document Server