The goal of this project was to evaluate the visualization component of ROOT and to estimate how much work it would take to improve it from its current state. By visualization, we mean in this case the visualization of the detectors and events in the detector, not the visualization of plots and histograms. In particular, we would like to evaluate the capability to merge Open Inventor (OIV) and the Hepvis library in the manner that they are used currently on existing projects. We have been able to make good use of OIV to create hierarchical scenes, create/delete/modify objects, and provide extensible viewers. It would be nice to have such capability in the ROOT analysis environment.

It seems that the existing graphics is fairly tightly coupled to the other components of the program. For example, the user is allowed to edit attributes of the scene from the cint command line or from menus on the graphics window. In addition, the data management (database) code contains calls to the visualization code.

CINT/ROOT and OIV both have X event loops. There will be some incompatibility between these (they will naturally clash)

There is some inconsistency between the command line control of the scene and the pushbutton control (see GUI evaluation).

I think that there are three different levels of upgrade that could take place

1. Leave the graphics part alone. It is fine as it is, fits in nicely with the rest of the program, and I believe that the users will get used to it. There are certain features that are missing, or that could be improved by using OIV or other advanced visualization packages (e. g. picking, adding widgets) but these are probably not as important for analyzing histograms as for visualizing detectors and other solid volumes.
2. To leave the existing code alone, and have Open Inventor graphics "drive" the program. Thus the user would provide his own main program and use an Open Inventor event loop, linking to the ROOT I/O subsystem (RIO) code to manage his own data access. This is probably a very inefficient solution for Physics Analysis. It will result in a program that makes use of the best parts of the different systems, but maintenance and code control will necessarily have to be done separately, by the individual users, making for more ongoing work. If ROOT develops very rapidly, as it appears it will, synchronizing many different graphics systems will be more work than it is worth. I do think that this solution is viable for event displays and other applications where 3-D graphics are important.
3. It would probably be possible re-engineer the program so as to decouple the visualization from the database control. One of the PASFRG and PASSUMA requirements was the capability to replace components of the candidate programs with external packages. By decoupling the data management from the visualization, we will be providing this capability. This is the philosophy used in Geant4 and users of that program have the capability to select different graphics systems at run time. Thus, for example, the VRML graphics could be added without great change to the main program.

1. As pointed out by Rene and Fons, this tool is meant to do HEP analysis. The graphics are fine for that purpose. What I saw of the displays during the demo was certainly functional, an improvement on PAW, and the user could probably adapt relatively easily. For example, the ROOT scene is constructed in an intuitive manner (similar to the way an Open Inventor scene is assembled). The user sets up the scene hierarchically using ROOT objects canvas (a scene or workspace), pad (one picture), and object (things like line, box, axis, etc.). All of these classes inherit from the tobject base class. The user creates a scene in the interactive ROOT session by first instantiating a canvas, then attaching one or more pads to the canvas. Once the pads have been instantiated, objects can be placed inside to make up the picture. The objects are placed in the current pad, which by default is the last one instantiated, but can be changed using the cdPad command. The objects are then accessible from the command line or using the mouse, using the developers' own version of picking and callbacks. They can be deleted, removed from the scene, or their attributes changed using these commands. In all, the system provides pretty good functionality.

CDF has indicated that they seldom have the need for intricate 3D graphics, that they can get their analysis done using 2D graphics. I believe, however, that good 3D will be very useful for event displays. So if we adopt this option, we may want to think about breaking off event displays into separate developments to make use of OIV, Hepvis, and other 3D tools with the ROOT I/O.

2. Recommendation 2 may be made to work by providing an Open Inventor shell for the ROOT IO module. The ROOT graphics could just be bypassed and the user would essentially be in an Open Inventor session. The tricky part here would be providing the right links between the Open Inventor scene and scene management code and the cint command line. In addition, the user will probably need to maintain her own makefiles and other support files as presumably the things necessary to build the OIV code would not be distributed. This could possibly be maintained in the Vis repository that currently contains HEPVis. This is probably the least useful/productive solution. The result would be very specialized and rather hard to maintain, and its usefulness in the analysis environment would be nebulous. I don't believe the components needed to provide this type of functionality should be included with the ROOT package. We should have expertise and examples on hand to assist in implementing this solution for event displays and other 3-D applications.
3. Recommendation 3 would be the most work initially, but would result in the best model to make use of visualization. It would require re-engineering ROOT to decouple the RIO module from the graphics. All reference to graphics things would be removed from the IO module, and access to the IO level from the OIV/Hepvis would take place using a SoRIOAction() method. This would provide a huge amount of flexibility to the users and collaborators who want to add their own graphics "top level". I also believe this would make for a more extensible and maintainable program. Rene and Fons have stated that they don't think such work is necessary. They are more interested in providing an analysis framework than component - oriented software.

Cost of Accomplishing the Tasks - $ and FTEs: Note: These are estimates and may not be very accurate

1. Almost none. Features could be added to the current graphics system as needed but this would be more or less part of the natural ROOT development.
2. Very hard to judge. Probably a .5 effort from CD and one-two other interested parties for 3-4 months would suffice. Some examples exist of using OIV with ROOT I/O, and we could consult as necessary.
3. Probably 6 months of concentrated effort by ROOT team and those interested in visualization** (One person from CD working half time, reps from CDF and D0)

I would recommend adopting option 1 for ROOT graphics (letting it develop naturally, not doing a great deal of work to integrate high-level graphics), and pursuing option 2 as the need arises for more intricate graphics applications. While a re-engineering would provide for a more extensible system, the effort would probably not be worth the gain for ROOT uses.