Source-linked AI summary
Method for detector description transformation to Unity and application in BESIII
Kai-Xuan Huang, Zhi-Jun Li, Zhen Qian, Jiang Zhu, Hao-Yuan Li, Yu-Mei Zhang, Sheng-Sen Sun, Zheng-Yun You
TL;DR
HEP visualization tools must address limited display quality and portability while handling complicated detector geometry consistently. This paper presents an automated GDML-to-Unity conversion method, implemented with GDML–FreeCAD, FreeCAD, and Pixyz, and validates it by constructing the BESIII detector in Unity for further visualization and monitoring applications.
Problem
HEP visualization tools must address limited display quality and portability while handling complicated detector geometry consistently.
Method
The method uses GDML–FreeCAD, FreeCAD, and Pixyz to automate 3D detector construction in Unity from GDML descriptions.
Results
The method successfully constructed and qualified BESIII 3D detector modeling in Unity for further development.
Takeaways & Limitations
The resulting Unity models can support event displays, data monitoring, VR or AR applications, and related detector-design, analysis, and outreach uses.
Abstract
from arXiv · showhide
Detector and event visualization are essential parts of the software used in high-energy physics (HEP) experiments. Modern visualization techniques and multimedia production platforms such as Unity provide impressive display effects and professional extensions for visualization in HEP experiments. In this study, a method for automatic detector description transformation is presented, which can convert the complicated HEP detector geometry from GDML in offline software to 3D modeling in Unity. The method was successfully applied in the BESIII experiment and can be further developed into applications such as event displays, data monitoring, or virtual reality. It has great potential in detector design, offline software development, physics analysis, and outreach for next-generation HEP experiments as well as applications in nuclear techniques for the industry.
I. INTRODUCTION
HEP detector visualization supports many experiment activities, but existing offline-software tools struggle with visualization quality, efficiency, and portability. The paper presents an automated GDML-to-Unity method validated with BESIII.
- Detector description and visualization support detector design, simulation, reconstruction, commissioning, monitoring, event display, analysis, outreach, and education.
- ROOT-based visualization tools benefit from offline-software integration but have limited visualization effects and poor portability beyond Linux.
- Unity offers strong visualization effects and cross-platform support, with prior applications in ATLAS, Belle II, and JUNO.
- Unity does not directly support GDML or DD4hep, forcing developers to rebuild detector models and risking extra work, maintenance problems, and inconsistency.
- The proposed method automatically imports GDML or ROOT detector geometry into Unity while preserving detector-element identifiers, and it was validated using BESIII.
II. DETECTOR GEOMETRY AND VISUALIZATION
HEP detector descriptions provide shared geometry and status information for simulation, reconstruction, visualization, and analysis. The section reviews GDML, DD4hep, offline visualization, CAD interoperability, and the limitations of ROOT-based displays.
- Detector descriptions provide geometry and status information across simulation, reconstruction, calibration, event display, and physics analysis.
- GDML is an XML-based persistent detector-description language used by several HEP experiments, including BESIII, PHENIX, LHCb, and JUNO.
- DD4hep provides geometry, materials, visualization, readout, alignment, and calibration through a consistent detector description for the experimental life cycle.
- Detector visualization helps users understand detector structures, while event displays demonstrate detector responses and support offline development and physics analysis.
- CAD and HEP offline software have difficulty sharing 3D modeling information because they belong to different technical domains.
- ROOT-based event displays are convenient for HEP developers but offer unsatisfactory display effects and are mostly limited to Linux platforms.
C. 3D modeling and visualization in Unity
Unity-based HEP visualization combines detailed 3D effects, broad deployment options, and extensibility to interactive applications. Existing tools such as CAMELIA and ELAINA demonstrate its use for ATLAS and JUNO event displays.
- Unity is a professional video and game production engine supporting more than 20 platforms and has been adopted for HEP visualization and outreach.
- CAMELIA is an ATLAS event display tool based on Unity, while ELAINA is a JUNO event display tool based on Unity.
- Unity provides detailed object descriptions and striking visualization effects compared with traditional ROOT-based event displays.
- Unity projects can be exported to Windows, Linux, macOS, iOS, Android, and web browsers, reducing development workload and facilitating maintenance.
- Unity projects can be extended to VR and AR applications for detector design, software development, physics analysis, education, and outreach.
- Unity therefore has potential beyond particle and nuclear physics, including applications in nuclear techniques for industry.
III. METHODOLOGIES
Large HEP detectors are difficult to model manually in Unity, while consistency with offline geometry is required for coherent event displays. The proposed approach automates conversion from existing detector descriptions into Unity models.
- HEP detectors may contain millions of components, making manual construction of their Unity 3D models difficult.
- Unity detector descriptions should remain consistent with offline software so tracks, hits, showers, and detector components match in event displays.
- Automatic geometry transformation can provide a single detector description across software packages and avoid inconsistencies in data processing.
- The proposed method converts existing GDML descriptions into Unity 3D models and is intended as a universal technique for visualization, event display, and outreach.
B. Detector data conversion from GDML to Unity
The paper establishes a conversion chain from GDML through FreeCAD, STEP, and FBX to Unity. This chain enables automated 3D detector construction while retaining detector-unit association information.
- STEP was selected as an intermediate format because FreeCAD exports it and Pixyz can transform it into FBX.FBX is a 3D mesh format supported by Unity.
- GDML detector descriptions are imported into FreeCAD, exported as STEP, converted to Unity-compatible FBX by Pixyz, and then read by Unity.The chain retains detector-unit association information during conversion.
- The data flow begins with GDML components including materials, positions, rotations, shapes, physical nodes, and the detector hierarchy.These elements are transformed through the intermediate formats before Unity import.
- The conversion method uses GDML–FreeCAD, FreeCAD, and Pixyz to automate 3D detector construction in Unity.Conversion correctness was validated through visualization and comparison at shape and detector levels.
C. Integrity in Unity 3D modeling
Unity modeling must preserve detector geometry, unit identifiers, and supplementary rendering information. The method supports this integrity but still requires detector-specific shape support and additional modeling information.
- A complete Unity detector model requires additional work beyond automatic geometry transformation for a specific GDML-described HEP detector.The paper identifies detector-specific geometry and visualization information as supplementary requirements.
- The GDML–FreeCAD interface supports only approximately 10 mostly basic shape types, while Geant4 provides more than 30 specific shapes.Unsupported special shapes require corresponding transformation development in the interface.
- Arb8 is an arbitrary trapezoid defined by eight vertices on two parallel planes perpendicular to the Z-axis.The interface was updated to support Arb8 conversion and its output was compared in ROOT and FreeCAD.
- Preserving detector-unit names through conversion allows Unity to recover identifiers and control unit-specific visualization properties.Identifier information is usually stored in GDML node names and used to map units to offline-software data.
- Unity can add richer rendering properties, including color, texture, transparency, and reflection, beyond GDML material density and composition.With supplementary information, the 3D detector model was successfully constructed and qualified for further development.
IV. APPLICATION IN BESIII
BESIII uses GDML as the shared detector-information source across offline applications. Its detector geometry was converted through automated processing and successfully modeled in Unity after validation and assembly.
- A. BESIII detector description and visualization: BESIII detector descriptions use separate GDML files for MDC, TOF, EMC, and MUC, plus a general file for common materials and passive components.The general file includes the beam pipe and superconducting solenoid.
- A. BESIII detector description and visualization: GDML is the single source of detector information for BESIII simulation, reconstruction, event display, calibration, and analysis.
- A. BESIII detector description and visualization: BesVis is a ROOT-based BESIII event-display tool used to visualize the detector and analyze physics events.It has supported BESIII offline software development and physics analysis since 2005.
- B. Conversion of the BESIII geometry to Unity: BESIII conversion imported GDML into FreeCAD, converted exported STEP files to FBX with Pixyz, and imported the FBX files into Unity.The process handled the four subdetectors and a general file for the beam pipe and superconducting solenoid.
- B. Conversion of the BESIII geometry to Unity: After automated processing, the BESIII subdetectors were combined into a complete Unity model following overlap verification in Geant4 and ROOT.
C. Display of the BESIII detector in Unity
The BESIII detector can be automatically constructed in Unity, but GDML visualization attributes must be added separately to make the detector display properly. Preserving detector-unit names enables scripts to assign appropriate visual properties.
- Automatic conversion constructs the BESIII detector in Unity, but default GDML visualization attributes leave only the top world volume visibly rendered.GDML does not store visualization attributes, so detector units initially use Unity defaults and inner components remain hidden.
- Scripts must set detector-unit color, transparency, reflectivity, and texture, while hiding top-level and virtual mother volumes.Maintaining detector-unit names allows scripts to assign visualization attributes by component.
- Updated Unity material parameters reproduce BesVis attributes while providing more vivid and richer effects for the four BESIII subdetectors and full detector.The four subdetectors are MDC, TOF, EMC, and MUC; the complete detector is shown separately.
V. FURTHER DEVELOPMENT OF APPLICATIONS
The automatically constructed Unity detector provides a basis for event displays and other applications, combining preserved detector associations with Unity’s visual, cross-platform, and VR/AR capabilities.
- Unity’s visual effects, multi-platform support, and VR/AR integration support event displays, detector monitoring, and immersive scientific or educational applications.The supplied passages identify event displays, detector status monitoring, and VR/AR applications as further developments.
- Figures 8 and 9 show Unity visualizations of the BESIII subdetectors and the full detector, respectively.Figure 8 covers MDC, TOF, EMC, and MUC; Figure 9 presents their inside-to-outside arrangement.
- Manual Unity detector construction previously required substantial developer work, whereas automatic geometry transformation avoids repetitive coding across software environments.The BESIII offline geometry and ROOT-based event display contain more than 5000 lines of code, while the transformation reuses detector geometry.
- Associating event data with detector identifiers lets Unity scripts distinguish fired from unfired units and implement basic event-display functions.The prototype BESIII event display is under development and demonstrates Unity rendering effects.
- A prototype BESIII event display in Unity demonstrates the rendering effects enabled by the transformed detector geometry.The prototype is described as under development.
B. Detector and data monitoring
The Unity detector can support online monitoring by linking operational data to detector units and displaying abnormal statuses across platforms. Its VR extensibility also supports immersive research, education, and public exploration.
- Unity-based monitoring can help track experiment operation and real-time data quality after detector geometry is constructed.The monitoring software can be developed alongside offline event displays.
- Distinct visualization of dead or hot channels can help shift operators diagnose potential detector problems.
- Unity monitoring projects can run on Windows, Linux, Android, and iOS, enabling remote status checks from mobile devices.
- VR can present particles and detector interactions immersively for tuning simulation, reconstruction, and analyzing rare events.The passage describes users experiencing detector scenes as if personally present.
- Automatic Unity construction combined with VR-device support can support public exploration of otherwise inaccessible nuclear and HEP experiments.The stated motivation includes safety or security restrictions during data collection.
D. Interdisciplinary applications
The automatic detector-modeling method is presented as applicable beyond HEP, including nuclear-industry monitoring and dynamic medical imaging, while supporting next-generation experiments and outreach.
- The method is proposed for applied nuclear science, techniques, and industry in addition to nuclear and HEP experiments.
- In nuclear power plants, monitoring emitted neutrons or neutrinos could reconstruct the active fission-area distribution and indicate operational status.
- Automatic modeling could rapidly construct and visualize dynamic human-body geometry for real-time or semi-real-time nuclear medical imaging.The passage also identifies muon tomography, X-ray inspection, and fusion diagnosis as potential applications.
- For next-generation HEP experiments, maintaining Unity models consistently with offline geometry remains difficult and labor-intensive for detectors with millions of components.
- The GDML-to-Unity method constructs BESIII 3D detector models with hundreds of thousands of components and has potential for future experiments, education, and outreach.