A method of detector description transformation to Unity and its application in BESIII

Detector description is an indispensable part in HEP offline software, which provides the detector geometry and status information for different applications, including simulation, reconstruction, calibration, event display and physics analysis. The popular HEP infrastructure software, such as Geant4 Geant4 or ROOT ROOT, has their own specific detector construction system. If the software developers define the detector geometry in these software respectivelyindependently, there could be potential inconsistency between them. To solve this problem, some framework provides software-independent detector description, such as GDML and DD4hep, for detector related applications in HEP offline software.

GDML GDML is a detector description language based on XML (eXtensible Markup Language) XML. It describes detector information through a set of tags and attributes in plain text format to provide persistent detector description for an experiment. Several HEP experiments, including BESIII BESIII_geo; ROOT_Geant4, PHENIX PHENIX, LHCb lhcb; lhcb_eventdisplay; lhcb_outreach and JUNO JUNO, have used GDML to describe and optimize the detector geometry in conceptual design and offline software development  rec_qian; rec_event; Rec_impro.

DD4hep dd4hep is a software framework for providing a complete solution for full detector description, including geometry, materials, visualization, readout, alignment, and calibration, for the full experiment life cycle. It offers a consistent description through a single source of detector information for simulation, reconstruction, analysis, etc. DD4hep aims at the applications in the next generation HEP experiments, such as CEPC CEPC, ILC ILC, FCC FCC and STCF STCF.

One important application of detector description is to visualize it so that the users can have a distinct view to better understand the HEP detectors. It is extremely important at the stage of detector conceptual design and detector commissioning. In combination with the event visualization, the event display provides a powerful tool to demonstrate the detector response to the particles, which plays an essential role in offline software development and physics analysis.

However, as part of the traditional industry design, Computer Aided Design (CAD) CAD has been dominant in several stages of an a HEP experiment, including detector design, construction and commissioning. There have always been difficulties in sharing the 3D modeling information between CAD and HEP offline software, since they belong to two quite different fields, industrial design and high energy physicsHEP experiment, respectively.

In HEP experiments, physicists used to the physicists usually develop the detector description and event visualization tool in HEP offline software. In the offline frameworksoftware, the developers can make full use of the detector geometry service and event data model to retrieve the corresponding information. The event display tools are usually based on the popular HEP software Geant4 or ROOT, whose visualization functions are friendly to HEP users and are naturally convenient for visualization software development. For example, the BESIII event display software is based on the infrastructure visualization function of ROOT. With the upgrade of ROOT and its EVE package ROOT_EVE, the development of event display tool becomes more convenient. Several recent HEP experiments, such as ALICE ALICE, CMS CMS, JUNO JUNO and Mu2e Mu2e, have developed the event display software based on ROOT EVE.

However, due to the limited support and the open-source feature visualization support of ROOT, its visualization display effects are not satisfactory to meet the diverse requirements of physicists. Most of ROOT applications are also limited to the Linux platform only. For better visualization and interactivity, several event display tools have been developed based on external visualization software. For instance, Atlantis Atlantis; Atlantis_event and VP1 VP1 are the two general-purpose event display tools in ATLAS. CMS has also developed several visualization systems, such as Fireworks Fireworks and SketchUp SketchUpCMS.

Unity is a professional video and game production engine in industry , which and supports more than 20 platforms. It is particularly popular for iOS and Android mobile app development, and has recently been used in HEP for scientific research and outreach. The Cross-platform Atlas Multimedia Educational Lab for Interactive Analysis (CAMELIA)  CAMELIA; CAMELIA_web is an event display software based on Unity for ATLAS. Fig. 1 shows the visualization of the ATLAS detector and a proton-proton collision event in CAMELIA. Another event display tool based on Unity, the Event Live Animation with unIty for Neutrino Analysis (ELAINA) ELAINA has also been developed in JUNO, as shown in Fig. 2.

The visualization software based on Unity has the following advantages:

• •

  Fancy visualization effects. The Unity engine, as a professional 3D software, provides more detailed description of the objects and more fancy visualization effects, which makes it much more powerful than the traditional event display based on ROOT.

• •

  Cross-platform supports. Thanks to the multi-platform supports of Unity, after the development by building models and functions in Unity, a project can be directly exported and deployed in different operating systems, including Windows, Linux, macOS, iOS, Android and network browsers. This feature makes the same visualization project available for all the users on different platform platforms to enjoy. It not only reduces the workload in project development, but also make is makes it easier for maintenance.

• •

  Extensibility. Unity allows the project to be extended and further developed into VR VR or Augment Reality (AR) AR project, such as BelleII VR BelleIIVR, which provides a quite different way for detector design, offline software development and physics analysis. It will also be very helpful to advertise the scientific projects to the public, especially the physics behind the large-scale scientific apparatus, and makes it a powerful tool in education and outreach, such as the Total Event Visualiser (TEV) of the CERN Media Lab TEV. The supports for various VR or AR devices have been integrated in Unity and will be continuously supported with the upgrade of Unity, so that the visualization project developers can focus on the software project itself, instead of different hardware supports.

Benefits Benefiting from the prominent features of Unity, it has huge potential and boosts promising prospects in the development of visualization software. Not only can it be used for scientific research in particle and nuclear physics, but also has wide applications application potential in nuclear techniques for industry.

In HEP offline software, to avoid the inconsistency of detector description in data processing, it is essential that the framework can provide a single source of detector description for all applications, such as simulation, reconstruction, calibration, event display and data analysis. . This idea is usually realized by developing automatic geometry transformation interfaces between different software. For an existing detector description with GDML, the detector construction in Geant4 and ROOT for a specific experiment can be automatically completed with the GDML-Geant4 and GDML-ROOT interfaces BESIII_geo; ROOT_Geant4, respectively. In this way, the detector geometry consistency among the Geant4 based simulation, the ROOT based reconstruction, event display and data analysis are automatically guaranteed.

A similar idea can also be implemented in the 3D detector modeling of Unity. Due to the complexity of HEP detectors and the fact that HEP The HEP experiments usually already have a detailed detector description , for example, in GDML format , it will save a lot of human work in development and maintenance if a method of automatic detector transformation from GDMLto Unity is available. As mentioned in Sect. 2.3, Unity provides fancy visualization effects and multiple extensions for further development. If this novel method in some format like GDML. If a novel method of GDML-Unity conversion can be realized and since it is a universal technique, all the current and future HEP experiments can benefit from it by easily easy development of applications for detector visualization, event display and outreach.

In the industry market, there are tens of popular 3D file formats, however, none of them is commonly supported in both of the HEP software and Unity. So we need to find a data flow path that starts from GDML and ends in Unity with a minimum steps of conversion.

FreeCAD FreeCAD is a general-purpose parametric 3D computer-aided design and modeling software. It is free and open-source, available for users to extend the functionality. Since FreeCAD supports the import of geometry in Constructive Solid Geometry (CSG) format CSG, an interface between GDML and FreeCAD is available has been developed by Keith Sloan et al. GDML-FreeCAD to import the GDML format detector description GDML-FreeCAD. On the other hand, FreeCAD allows to export the modeling in several kinds of popular 3D formats, including STEP STEP, BREP BREP, VRML VRML, etc.

In all of these formats, STEP is chosen for further geometry transformation. Although STEP is still not a format that can be directly read in by Unity, it can be transformed into the FBX Filmbox (FBX) format FBX with the Pixyz Studio software pixyz. Pixyz Studio is a CAD data preparation and optimization software, which supports more than 35 3D file formats. It provides tessellation algorithms, enabling the transformation of CAD data from industry-leading solutions into lightweight, optimized meshes, in which FBX is one of the 3D mesh formats that Unity supports. It is noteworthy that Pixyz has joined Unity so that Unity can provide plugin to import and transform heavy and complex 3D CAD data, such as the HEP detectors, into optimized meshes for real-time 3D engines more conveniently.

The full chain of the data flow is shown in Fig. 3. The original HEP detector description in GDML format usually composes consists of the following parts: the material list, the position and rotation list, the shape list, the detector component (physical node) list and the hierarchy of the whole detector tree. The GDML detector description is firstly imported into FreeCAD with the GDML-FreeCAD interface, then it is exported into the STEP format. Pixzy reads in the STEP format data and transforms it into the FBX format, which can be directly read in by Unity , and keep and keeps the detector unit association information in the meantime.

With the data flow chain described above, we provide a method to transform the GDML detector description into Unity with automated 3D detector construction. The method is realized with the GDML-CAD GDML-FreeCAD interface, FreeCAD and Pixyz software. The correctness of detector geometry conversion in each step is validated with visualization and comparison at the shape level and detector level. With the 3D detector modeling successfully constructed in Unity with automation, further application development based on Unity will be achievable.

For a specific HEP detector with GDML description, to realize a complete 3D modeling of the detector in Unity, a few more extra works are work is necessary, in addition to the automatic geometry transformation method introduced above.

FirstFirstly, in the GDML-FreeCAD interface GDML-FreeCAD, not all of the solid shapes that are currently defined in Geant4 or ROOT are fully supported. The current interface only supports about 10 kinds of shapes, most of them are which are mostly the basic CSG shapes, such as Box, Cone, Cylinder, Ellipsoid, ElliTube, Polygon, Sphere, Torus, Trap, Tube, etc. There are more than 30 kinds of specific shapes that are provided in Geant4 but not commonly used. For a specific HEP detector description with GDML format, if some special shapes are used but not available in the interface, users may request to develop the corresponding shape transformation in the GDML-FreeCAD interface, so that the full detector transformation can be supported.

For example, Arb8 is a kind of arbitrary trapezoid defined with 8 vertices standing on two parallel planes perpendicular to the Z axis. The Arb8 shape exists in GDML, ROOT and FreeCAD. In the GDML-FreeCAD interface, the conversion interface has been updated with the Arb8 shape support and the code example is shown in Fig. 4 for illustration. The same Arb8 shape with GDML description and its visualization in ROOT and FreeCAD is also compared in Fig. 5.

Secondly, in the description of a HEP detector, it is important to keep the association between a unique detector unit and its identifier in unique identifier in the event data model. Such association information is essential to control the visualization properties of the detector unit in further application development in Unity, such as event display. Usually, the identifier information is stored in the name of each node in GDML, so that later it . So long as the node name keeps unchanged during the whole chain of conversion, later in Unity the identifier can be extracted from the unit’s name in Unity to retrieve the mapping of a unit and its corresponding identifier in offline software, which makes it possible to control the visual effects of a geometry unit with its identifier in event data. Hence, in transformation of the detector geometry from GDML to Unity, it is critical to retain the name of each detector unit to keep the association information.

ThirdThirdly, although the basic information such as density and makeup of materials can be transformed from GDML, Unity provides more rich richer visualization properties such as material color, texture, transparency, reflection, etc., which allows the user allow the users to have the freedom to render the detector geometry with more powerful visualization effects.

With the above supplementary information provided, the 3D detector modeling has been successfully constructed in Unity, and it has been qualified for further development.

BESIII is a spectrometer operating at the Beijing Electron Positron Collider II (BEPCII). The BESIII detector records symmetric $e^{+}e^{-}$ collisions provided by the BEPCII storage ring bepcii, which operates in the center-of-mass energy range from 2.0 to 4.7 GeV BESIII_future. The cylindrical core of the BESIII detector covers 93% of the full solid angle and consists of a helium-based multi-layer drift chamber (MDC), a plastic scintillator time-of-flight system (TOF), and a CsI(Tl) electromagnetic calorimeter (EMC), which are all enclosed in a superconducting solenoidal magnet providing a 1.0 T magnetic field. The solenoid is supported by an octagonal flux-return yoke with resistive plate counter muon identification modules interleaved with steel (MUC).

The detector description in BESIII offline software is provided in GDML format. Each of the four sub-detectors, MDC, TOF, EMC and MUC, has a corresponding GDML file to describe it. A general GDML file provides description of the common materials and the other passive detector components, such as the beam-pipe and the superconducting solenoid. All applications in BESIII offline software, including simulation, reconstruction, event display, calibration and analysis, use the GDML files as the single source of detector information.

BESIII Visualization (BesVis), an event display tool based on ROOT, has been developed to visualize the detector and to analyze the physics events, as shown in Fig. 6. It has played an important role in BESIII offline software development and physics analysis since 2005.

Based on the method introduced in Sect.3, it is possible to perform a format conversion of the BESIII detectors description from GDML to Unity. The process of the detector data conversion is divided into the following steps.

FirstFirstly, the GDML description of each sub-detector is imported into FreeCAD with the GDML-CAD GDML-FreeCAD interface. Since the original interface only supports very the basic CSG shapes but BESIII has used some complicated shapes, such as Polygon, Polyhedra, Twistedtubs, IrregBox and Boolean shapes, we update the interface to allow correct conversion of all the shapes being used in BESIII the GDML detector description of BESIII.

SecondSecondly, after importing into FreeCAD, the BESIII detector data is exported in STEP format. Then the STEP files are converted to FBX files with the format conversion function provided by Pixyz Studio. As an example, visualization of the BESIII TOF sub-detector in FreeCAD and Pixyz is shown in Fig. 7.

ThirdThirdly, the FBX files can be directly imported into Unity. For the BESIII detector, there are four sub-detector FBX files (MDC, TOF, EMC and MUC) and one general FBX file to describe the beam-pipe and the superconducting solenoid. The subdetectors have been checked in Geant4 and ROOT to guarantee no space overlaps between each other, so the subdetectors can be directly combined together to form the whole BESIII detector. Finally, the 3D modeling of the BESIII detector is successfully constructed in Unity with after a set of automated steps.

Although at this stage, the BESIII detector has been automatically built in Unity, it is still not well displayed in the scene. Since GDML does not save the visualization attributes, all of the detector units are still set with the default visualization attributes in Unity. All The only thing that the users can see in the scene is a box, which is the top world volume in definition of the GDML detector description.

A set of scripts need to be developed to set color, transparency, reflectivity and texture of material for the detector units. The top world volume and the virtual mother volumes need to be set invisible , to allow the inner detector units to show up. Another advantage of the automatic conversion is that the name of each detector unit is kept during the process of transformation, so that the scripts can set the visualization attributes according to the name of each detector unit.

Fig. 8 shows the display of the four BESIII sub-detectors in Unity. The corresponding display parameters of the materials have been updated to obtain a better display effect. The display attributes in Unity are set to be consistent with those in BesVis, but with more vivid and rich richer visualization effects that ROOT does not support. A display of the full BESIII detector in Unity is shown in Fig. 9.

Event display is a convenient tool for offline software tuning and physics analysis in HEP experiments. In Sect. 2.3, the application of Unity for event display in ATLAS and JUNO has been introduced. However, for both programs, the detectors were manually constructed in Unity independently, which took a lot of the developers’ work.

With the method of automatic geometry transformation, the BESIII detector has been constructed in Unity. In comparison with the geometry construction in the BESIII offline software and its ROOT based event display, which is composed of more than 5000 lines of code, this method saves a lot of repetitive coding work in different software. To develop the event display tool based on Unity, another work is to get the event data information, and to associate the fired detector units with their identifiers, which can be decoded from the name of each detector unit.

Once the association relationship is constructed, a set of scripts can be developed in Unity to control the different visual effects for the fired and unfired detector units. Then the basic functions of event display tool have been can be realized. Fig. 10 shows a prototype of an the BESII event display tool under development in Unity and its rendering effects.

With the detector constructed in Unity, not only the offline event display but also the online monitoring software can be developed to help monitor the experiment’s operation status and the quality of the real-time data collected by the detector.

The detector units with abnormal operational status, such as the dead or hot channels, can be distinctly displayed, which will help the shift operators to diagnose the potential detector problems.

Thanks to the multi-platform supports of Unity, a monitoring project can be easily deployed to different platforms and devices. Besides the traditional Windows and Linux operating system, the monitoring project can also be built into apps on the mobile platform, such as Android and iOS, so that the users can conveniently monitor the status of an experiment from their mobile phones or pads remotely.

In the roadmap for HEP software and computing R&D for the 2020s Roadmap, the application based on VR is an important direction of development HSF. VR simulates the user’s physical presence in a virtual environment. By presenting the emitting particles and their interactions with the detector, it can provide a new method with immersive experience for the physicists to tune the offline simulation and reconstruction software, as well as performing physics analysis for the rare events, as if the users are personally in the scene of the running detector. Some creative production has started in HEP community, such as ATLASrift ATLASrift and BelleII VR BelleIIVR.

With the method of automatic detector construction in Unity, and the extensible supports of VR devices from Unity, the VR applications for nuclear or HEP experiments can be easily also be conveniently developed. Since most of the nuclear or HEP experiments are not accessible during data taking because of the safety or security requirements, our method has another advantage, allowing the general public to explore the detector with an immersive experience, watch the nuclear or HEP collisions in a realistic environment. It will be of great benefits to let the general public have a basic idea and understand what scientific research the nuclear physics and HEP community are doing.

In addition to the applications in nuclear physics or HEP experiments, the method could also have wide applications in applied nuclear science, techniques, and industry.

For example, in nuclear power plant (NPP) monitoring, this method can be used to monitor the emitting neutrons or neutrinos, then to reconstruct the distribution of the inner active fission area, so as to monitor the operation status of NPP.

In the field of nuclear medical imaging, the human body is more or less like a nuclear particle source or detector, but with dynamic geometry. Since our method of detector modeling is automatic, it can rapidly construct and visualize the human body, to allow observation of its status after interaction with nuclear particles in real time or semi real time. Other potential interdisciplinary applications include muon tomography cosmic_ray_muons; Khufu_muons; MtEtna_muons, X-ray inspection, and fusion diagnosis, etc MtEtna_muons; Khufu_muons; laoheishan_muons; juno_muon_bundle.