Pith. sign in

REVIEW 3 major objections 6 minor 58 references

Detector description conversion and visualization in Unity for high energy physics experiments

T0 review · 3 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Pith's one-line read This paper claims that detector geometries written in Geant4, ROOT, GDML, or DD4hep can be automatically converted to the industry-standard FBX format and visualized in Unity, with a single correction to Geant4's Boolean-operation…

desk verdict A useful unified detector-to-FBX converter for HEP visualization, but the geometric fidelity claim is only visually supported and the 'universal' interface leans on unvalidated intermediate conversions. read the letter →

arxiv 2507.10261 v1 pith:4PAGY6M3 submitted 2025-07-14 hep-ex physics.ins-det

classification hep-exphysics.ins-det
keywords detectordescriptionFBXUnityGeant4GDMLDD4hepROOTgeometryconversion
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper claims that detector descriptions written in Geant4, ROOT, GDML, or DD4hep can be converted automatically into FBX, an industry-standard mesh format, and then imported into Unity for interactive visualization. The conversion funnels every input format into Geant4, uses Geant4's polygonization to turn CSG solids into meshes, and exports via an FBX writer. A fix to Geant4's handling of rotation and translation order in Boolean operations removes the geometric mismatches that had plagued converted shapes. Demonstrations on four real detectors—JUNO, EicC, BESIII, and CEPC—show the pipeline working for each of the four source formats. If correct, this gives HEP experiments a single-source, reusable route to modern industrial visualization, event displays, and VR/AR applications.

What carries the argument

The machinery is a Geant4-centered conversion chain. Each input format (Geant4, ROOT via GDML, GDML, DD4hep) is loaded into Geant4, where the geometry remains a CSG (constructive solid geometry) tree of solids, logical volumes, and physical volumes. The G4Polyhedron class then polygonizes each CSG solid into a mesh of triangles and quads with computed normals, mirroring the mesh-based representation FBX expects. The HSF FBXWriter maps Geant4's logical/physical-volume hierarchy onto FBX geometry, material, model, and connection nodes, producing the final .fbx file. The load-bearing correction is the reordering of rotation and translation in Geant4's Boolean operations; without it, converted shapes show geometric mismatches such as those seen in the BESIII muon counter.

What would settle it

Take a detector geometry containing many Boolean-composed solids with known volumes (for example the BESIII MUC or a benchmark set of shapes), convert it to FBX with the proposed pipeline, and compare the resulting mesh's volumes or rendered silhouettes against the CSG originals; any residual interpenetration, missing faces, or volume deviation beyond the polygonization tolerance would show that geometry is still being silently changed.

Watch

Extended reading notes

Core claim

The paper's central discovery is that a universal conversion interface can be built by routing all four detector description formats through Geant4 and then exporting to FBX. For ROOT inputs, the geometry is first exported to GDML and then read into Geant4; for DD4hep inputs, the DD4hep-to-Geant4 interface is used; GDML inputs are read directly. Inside Geant4, each CSG solid is converted to a polyhedral mesh via the G4Polyhedron class, then written out as an FBX file by the HSF FBXWriter. The authors identify a specific bug in how Geant4 applies rotation and translation during Boolean operations—an ordering issue that distorts complex shapes—and show that correcting the order restores the correct geometry in the converted mesh. The result is a one-step pipeline from any of the four HEP detector formats to a Unity-ready FBX model, with per-sub-detector identification preserved through the mapping of Geant4 logical and physical volumes to FBX nodes.

Load-bearing premise

The whole pipeline rests on the assumption that the intermediate format conversions (ROOT-to-GDML, GDML-to-Geant4, and DD4hep-to-Geant4) faithfully preserve the detector geometry, and that the single reordering fix for Geant4 Boolean operations removes all shape mismatches that occur in complex solids.

Editorial extensions

If this is right

  • Any HEP experiment with a detector description in Geant4, ROOT, GDML, or DD4hep can produce a Unity-ready FBX model automatically, with no manual re-modeling.
  • Because the source description stays unique, detector upgrades only require re-running the conversion to refresh the visualization.
  • The FBX output can be imported not only into Unity but into other industry-standard 3D tools such as Blender, Maya, or Unreal Engine.
  • Adjusting the polygonization rotation step lets users trade geometric fidelity for file size and conversion time, as shown by the performance table (e.g., EicC at about 0.2 seconds, CEPC at 378 seconds).
  • The pipeline supports future visualization functions like event display, virtual reality, and augmented reality built on top of the imported detector model.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same Geant4-to-FBX chain could be applied to other CSG-based geometry toolkits beyond the four tested (for example GeoModel), since the input side only needs a working import into Geant4.
  • The mapping of detector sub-assemblies to FBX nodes could be used to attach hit information or simulation data to specific sub-detectors, enabling event displays where detector geometry and physics data live in the same scene graph.
  • A quantitative fidelity check (for instance, comparing mesh volumes or rendered silhouettes against the original CSG geometry) would strengthen confidence that the rotation-order fix covers all Boolean cases, not only the BESIII MUC example shown.
  • Because the conversion is unidirectional, the workflow favors design-stage iteration; a future bidirectional format would be needed if detector geometries were to be edited in industrial tools and exported back into simulation.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper presents a universal interface that converts detector descriptions in four HEP formats (Geant4, ROOT, GDML, and DD4hep) into FBX meshes for visualization in Unity. The method funnels all formats through Geant4, uses G4Polyhedron to tessellate CSG solids, and employs an updated HSF FBXWriter to export the geometry. Demonstrations are given for JUNO (Geant4), EicC (ROOT), BESIII (GDML), and CEPC (DD4hep), together with a performance table listing conversion time, polygon count, and file size. The paper also reports a bug fix in Geant4 Boolean operations involving the order of rotations and translations, illustrated by before/after images of the BESIII muon counter.

Significance. The paper addresses a practical interoperability gap between HEP detector description formats and industrial 3D visualization platforms. Its main strengths are the automated, unified pipeline; the use of existing, community-maintained conversion interfaces; open-source code availability on GitHub; and concrete demonstrations on four real experiments. If the geometric fidelity of the conversion chain is quantitatively established, the tool would be a useful and reusable contribution for detector design review, outreach, event display, VR, and AR. The current evidence, however, is largely qualitative, consisting of rendered images and performance numbers, so the central universality and fidelity claims are not yet fully demonstrated.

major comments (3)
  1. [Section 3.2 and Figure 4] The only geometric-fidelity evidence is a visual before/after pair of the BESIII MUC. To support the claim that the FBX mesh faithfully represents the original CSG geometry, the paper should include a quantitative validation: for representative solids and full detector volumes, compare the FBX tessellation against the analytic CSG geometry using metrics such as volume, surface area, bounding-box containment, or Hausdorff distance between the tessellated surface and the exact surface. It should also specify which Boolean solids and which rotation/translation combinations are covered by the correction, preferably with a unit test or a list of test cases.
  2. [Section 3.2 and Figure 2] The pipeline for ROOT, GDML, and DD4hep inputs relies on intermediate converters (ROOT-to-GDML, GDML-to-Geant4, DD4hep-to-Geant4), but no validation is reported for these steps. A load-bearing question is whether volume counts, placements, materials, and hierarchy are preserved through each conversion. The paper should provide a check at each stage, for example comparing logical-volume counts and bounding boxes before and after conversion, or cross-checking a few known volumes against their expected positions and dimensions, so that a silently wrong intermediate conversion cannot produce a plausible but incorrect FBX mesh.
  3. [Section 3.2 and Section 4.5, Table 1] The tessellation precision is controlled by a user-adjustable rotation step, yet no error bound or fidelity metric is reported for the polygonal approximation, and Table 1 lists only polygon counts and file sizes. The paper should quantify how mesh error scales with the rotation step for representative curved solids, and should state a default tolerance that justifies the 'geometric consistency' wording used in the text.
minor comments (6)
  1. [Section 3.2] There is a typo in 'detaily shown in Figure 3'; it should read 'shown in detail in Figure 3'.
  2. [Section 4.3] The phrase 'an executable program combing the GDML-Geant4 interface' should read 'an executable program combining the GDML-Geant4 interface'.
  3. [Table 1] The table heading has a spacing issue: 'T able 1The time consumption' should be 'Table 1: The time consumption'.
  4. [Figure 4 caption] The caption attributes the bug to the 'GDML-Geant4 parser' while the text in Section 3.2 attributes it to 'Geant4 Boolean operations'; these descriptions should be reconciled so the reader knows exactly which component was fixed.
  5. [Reference [54]] The title of reference [54] uses 'Filmbox' instead of the standard 'FBX'; please make the naming consistent.
  6. [Figures 6 and 7] Figure 6(b) places a human model on the right and Figure 7 places one on the left, but the captions are not consistent about which side is shown; please check the captions for accuracy.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper reports a software conversion pipeline with external input formats and independently defined output, not a derivation whose result is equivalent to its inputs.

full rationale

This is a software-tool paper, not a derivation chain. The claimed result is that detector descriptions in Geant4, ROOT, GDML, and DD4hep can be automatically converted to FBX via an existing Geant4 bridge and G4Polyhedron tessellation. The inputs (detector geometry files) and outputs (FBX meshes) are independently defined representations, and the conversion is executed by code, not fitted or tuned to a target answer. The only code-level correction described in Section 3.2 is a fix to rotation/translation ordering in Geant4 Boolean operations, which is a reported bug fix rather than a parameter adjustment calibrated to force agreement. The adjustable rotation step is an explicit tessellation-resolution parameter acknowledged by the authors, and the performance figures in Table 1 are measured outputs, not predictions constrained by inputs. Citations to previous conversion interfaces, including the authors' own prior work, are used as tools whose external definitions and implementations exist independently of this paper's claims; none is invoked as a uniqueness theorem or as the sole justification for the central claim. The absence of a quantitative mesh-vs-CSG fidelity check and the reliance on one visual before/after example are correctness and validation concerns, not circularity. The converter's output could in principle disagree with the input geometry, so the claim is not equivalent by construction to its assumptions.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

The converter introduces no new physical objects. The main latent assumptions are the fidelity of the existing geometry interfaces, the correctness of the Boolean operation fix, and the acceptability of mesh tessellation. The rotation step is a tunable resolution knob, not a fitted constant.

free parameters (1)
  • rotation step for polyhedron generation = user-configurable (default not specified)
    Controls the polygon edge count for circular approximations during Geant4-to-polyhedron tessellation. It balances fidelity against conversion time and file size, and is set by hand rather than fitted to data (Section 3.2).
assumptions (4)
  • domain assumption The existing format bridges (ROOT to GDML, GDML to Geant4, DD4hep to Geant4) preserve geometry faithfully.
    The pipeline forces all four input formats through Geant4 before FBX export, relying on the correctness of these external interfaces (Section 3.2, Fig. 2).
  • domain assumption G4Polyhedron polygonization accurately represents the CSG solids for visualization.
    The geometric fidelity of the FBX output depends on Geant4's tessellation of solids into facets and normals (Section 3.2, Fig. 3).
  • ad hoc to paper The corrected order of rotations and translations in Geant4 Boolean operations fully fixes the shape mismatch.
    The paper identifies a bug in Geant4's handling of transformation order and implements a fix, but validates it only on the BESIII MUC geometry, not on the other detectors or as a formal proof (Section 3.2, Fig. 4).
  • domain assumption FBX mesh representation is an acceptable visual proxy for detector geometry.
    The whole method equates a polygon-mesh model with the original CSG description for visualization purposes, which is standard but not exact (Section 2.2).

how reviews work

0 comments
Cite this review

Pith. "Pith review of Detector description conversion and visualization in Unity for high energy physics experiments." pith.science (2026). https://pith.science/paper/4PAGY6M3

@misc{pith2026250710261,
  author       = {Pith},
  title        = {Pith review of: Detector description conversion and visualization in Unity for high energy physics experiments},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4PAGY6M3}},
  note         = {Machine review of arXiv:2507.10261}
}
read the original abstract

While visualization plays a crucial role in high-energy physics (HEP) experiments, the existing detector description formats including Geant4, ROOT, GDML, and DD4hep face compatibility limitations with modern visualization platforms. This paper presents a universal interface that automatically converts these four kinds of detector descriptions into FBX, an industry standard 3D model format which can be seamlessly integrated into advanced visualization platforms like Unity. This method bridges the gap between HEP instrumental display frameworks and industrial-grade visualization ecosystems, enabling HEP experiments to harness rapid technological advancements. Furthermore, it lays the groundwork for the future development of additional HEP visualization applications, such as event display, virtual reality, and augmented reality.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

58 extracted references · 40 canonical work pages

  1. [1]

    : Visualization for physics analy- sis improvement and applications in BESIII

    Li, Z.-J., Yuan, M.-K., Song, Y.-X., et al. : Visualization for physics analy- sis improvement and applications in BESIII. Front. Phys. 19(6), 64201 (2024) https://doi.org/10.1007/s11467-024-1422-7

  2. [2]

    : A Roadmap for HEP Software and Computing R&D for the 2020s

    Albrecht, J., et al. : A Roadmap for HEP Software and Computing R&D for the 2020s. Comput. Softw. Big. Sci. 3, 7 (2019) https://doi.org/10.1007/ s41781-018-0018-8

  3. [3]

    : Geant4 - a simulation toolkit

    Agostinelli, S., et al. : Geant4 - a simulation toolkit. Nucl. Instrum. Meth. A 506(3), 250–303 (2003) https://doi.org/10.1016/S0168-9002(03)01368-8

  4. [4]

    Brun, R., Gheata, A., Gheata, M.: The ROOT geometry package. Nucl. Instrum. Meth. A 502(2), 676–680 (2003) https://doi.org/10.1016/S0168-9002(03)00541-2

  5. [5]

    IEEE Trans

    Chytracek, R., Mccormick, J., Pokorski, W., Santin, G.: Geometry description markup language for physics simulation and analysis applications. IEEE Trans. Nucl. Sci. 53(5), 2892–2896 (2006) https://doi.org/10.1109/TNS.2006.881062

  6. [6]

    Frank, M., Gaede, F., Grefe, C., Mato, P.: DD4hep: A detector description toolkit for high energy physics experiments. J. Phys. Conf. Ser. 513(2), 022010 (2014) https://doi.org/10.1088/1742-6596/513/2/022010

  7. [7]

    Boudreau, J., Tsulaia, V.: The GeoModel Toolkit for Detector Description (2005) https://doi.org/10.5170/CERN-2005-002.353

  8. [8]

    https://www.autodesk.com/products/fbx/overview

    FBX webpage. https://www.autodesk.com/products/fbx/overview

Show all 58 references
  1. [9]

    https://www.autodesk.com.cn/

    Autodesk webpage. https://www.autodesk.com.cn/

  2. [10]

    IEEE Potent

    Zheng, J.M., Chan, K.W., Gibson, I.: Virtual reality. IEEE Potent. 17(2), 20–23 (1998) https://doi.org/10.1109/45.666641

  3. [11]

    (ed.) Augmented Reality: An Overview, pp

    Carmigniani, J., Furht, B.: In: Furht, B. (ed.) Augmented Reality: An Overview, pp. 3–46 (2011). https://doi.org/10.1007/978-1-4614-0064-6 1

  4. [12]

    https://unity.com/ 19

    Unity webpage. https://unity.com/ 19

  5. [13]

    Goldstone, W.: Unity Game Development Essentials, (2009)

  6. [14]

    : JUNO physics and detector

    Abusleme, A., et al. : JUNO physics and detector. Prog. Part. Nucl. Phys. 123, 103927 (2022) https://doi.org/10.1016/j.ppnp.2021.103927

  7. [15]

    Anderle, D.P., et al.: Electron-ion collider in China. Front. Phys. (Beijing) 16(6), 64701 (2021) https://doi.org/10.1007/s11467-021-1062-0

  8. [16]

    : Design and construction of the BESIII detector

    Ablikim, M., et al. : Design and construction of the BESIII detector. Nucl. Instrum. Meth. A 614(3), 345–399 (2010) https://doi.org/10.1016/j.nima.2009. 12.050

  9. [17]

    arXiv (2018)

    The CEPC Study Group: CEPC Conceptual Design Report: Volume 2 - Physics & Detector. arXiv (2018). https://doi.org/10.48550/ARXIV.1811.10545 . https://arxiv.org/abs/1811.10545

  10. [18]

    Journal of Instrumentation 3(08), 08003–08003 (2008) https://doi.org/ 10.1088/1748-0221/3/08/s08003

    The ATLAS Collaboration: The ATLAS experiment at the CERN large hadron collider. Journal of Instrumentation 3(08), 08003–08003 (2008) https://doi.org/ 10.1088/1748-0221/3/08/s08003

  11. [19]

    Journal of Instrumentation 3(08), 08004–08004 (2008) https://doi.org/10.1088/1748-0221/ 3/08/s08004

    The CMS Collaboration: The CMS experiment at the CERN LHC. Journal of Instrumentation 3(08), 08004–08004 (2008) https://doi.org/10.1088/1748-0221/ 3/08/s08004

  12. [20]

    New Journal of Physics 9(9), 335–335 (2007) https://doi.org/10.1088/1367-2630/9/9/335

    Evans, L.: The large hadron collider. New Journal of Physics 9(9), 335–335 (2007) https://doi.org/10.1088/1367-2630/9/9/335

  13. [21]

    https://www.opengl.org/

    OpenGL webpage. https://www.opengl.org/

  14. [22]

    IEEE MultiMedia 5(3), 84–93 (1998) https://doi.org/10.1109/93.713310

    Carey, R.: The virtual reality modeling language explained. IEEE MultiMedia 5(3), 84–93 (1998) https://doi.org/10.1109/93.713310

  15. [23]

    https://vrmasterleague.com/

    VRML webpage. https://vrmasterleague.com/

  16. [24]

    Taubin, G., Horn, W.P., Lazarus, F., Rossignac, J.: Geometry coding and vrml. Proc. IEEE 86(6), 1228–1243 (1998) https://doi.org/10.1109/5.687837

  17. [25]

    https://arxiv.org/abs/cs/0306059

    Perl, J., Giannitrapani, R., Frailis, M.: The Use of HepRep in GLAST (2003). https://arxiv.org/abs/cs/0306059

  18. [26]

    Brun, R., Rademakers, F.: ROOT - An object oriented data analysis frame- work. Nucl. Instrum. Meth. A 389(1), 81–86 (1997) https://doi.org/10.1016/ S0168-9002(97)00048-X . New Computing Techniques in Physics Research V

  19. [27]

    : GDML based geometry management system for offline software in JUNO

    Li, K., You, Z., Zhang, Y., et al. : GDML based geometry management system for offline software in JUNO. Nucl. Instrum. Meth. A 908, 43–48 (2018) https: //doi.org/10.1016/j.nima.2018.08.008 20

  20. [28]

    : A ROOT-based detector geometry and event visualization sys- tem for JUNO-TAO

    Liao, M., et al. : A ROOT-based detector geometry and event visualization sys- tem for JUNO-TAO. Nucl. Sci. Tech. 36(3), 39 (2025) https://doi.org/10.1007/ s41365-024-01604-0 2406.16431

  21. [29]

    Liang, Y.-T., et al.: A uniform geometry description for simulation, reconstruction and visualization in the BESIII experiment. Nucl. Instrum. Meth. A 603(3), 325–327 (2009) https://doi.org/10.1016/j.nima.2009.02.036

  22. [30]

    arXiv (2018)

    Bellis, M., et al.: HEP Software Foundation Community White Paper Working Group — Visualization. arXiv (2018). https://doi.org/10.48550/ARXIV.1811. 10309 . https://arxiv.org/abs/1811.10309

  23. [31]

    arXiv (2013)

    Behnke, T., et al.: The International Linear Collider Technical Design Report - Volume 1: Executive Summary. arXiv (2013). https://doi.org/10.48550/ARXIV. 1306.6327 . https://arxiv.org/abs/1306.6327

  24. [32]

    (eds.): Physics and Detec- tors at CLIC: CLIC Conceptual Design Report (2012) https://doi.org/10.5170/ CERN-2012-003 arXiv:1202.5940 [physics.ins-det]

    Linssen, L., Miyamoto, A., Stanitzki, M., Weerts, H. (eds.): Physics and Detec- tors at CLIC: CLIC Conceptual Design Report (2012) https://doi.org/10.5170/ CERN-2012-003 arXiv:1202.5940 [physics.ins-det]

  25. [33]

    The FCC Collaboration: FCC Physics Opportunities: Future Circular Collider Conceptual Design Report Volume 1. Eur. Phys. J. C 79(6) (2019) https://doi. org/10.1140/epjc/s10052-019-6904-3

  26. [34]

    In: Proceedings of the 9th International Particle Accelerator Conference (IPAC’18), pp

    Luo, Q., Xu, D.R.: Progress on preliminary conceptual study of hiepa, a super tau-charm factory in china. In: Proceedings of the 9th International Particle Accelerator Conference (IPAC’18), pp. 422–424 (2018). https://doi.org/10.18429/ JACoW-IPAC2018-MOPML013

  27. [35]

    SIGGRAPH Comput

    Laidlaw, D.H., Trumbore, W.B., Hughes, J.F.: Constructive Solid Geometry for Polyhedral Objects. SIGGRAPH Comput. Graph. 20(4), 161–170 (1986) https: //doi.org/10.1145/15886.15904

  28. [36]

    National Center for Supercomputing Applications 1205, 22 (2008)

    McHenry, K., Bajcsy, P.: An overview of 3d data content, file formats and viewers. National Center for Supercomputing Applications 1205, 22 (2008)

  29. [37]

    Harper, J.: Mastering Autodesk 3ds Max 2013, (2012)

  30. [38]

    https://books.google.com.sg/books?id=Ur cDgAAQBAJ

    Caudron, R., Nicq, P.A., Valenza, E.: Blender 3D: Designing Objects, (2016). https://books.google.com.sg/books?id=Ur cDgAAQBAJ

  31. [39]

    Tickoo-CADCIM Series, (2018)

    Tickoo, P.S.: Autodesk Maya 2019: A Comprehensive Guide, 11th Edi- tion. Tickoo-CADCIM Series, (2018). https://books.google.com.sg/books?id= 0lvyDwAAQBAJ

  32. [40]

    From technologies to solutions, (2009)

    Goldstone, W.: Unity Game Development Essentials. From technologies to solutions, (2009). https://books.google.com.sg/books?id=WfA WzVW9IK0C 21

  33. [41]

    https://www.unrealengine.com

    The Unreal Engine: Unreal Engine. https://www.unrealengine.com

  34. [42]

    https://doi.org/10.11578/dc.20210416.15

    Pequenao, J.: ATLAS Multimedia Educational Lab for Interactive Analysis. https://doi.org/10.11578/dc.20210416.15

  35. [43]

    EPJ Web Conf

    Riccardo Maria, B., Adam Bourdarios, C., Hovdesven, M., Vukotic, I.: Virtual Reality and game engines for interactive data visualization and event displays in HEP, an example from the ATLAS experiment. EPJ Web Conf. 214, 02013 (2019) https://doi.org/10.1051/epjconf/201921402013

  36. [44]

    Huang, K., Li, Z., Qian, Z., al.: Method for detector description transformation to unity and application in besiii. Nucl. Sci. Tech. 33(142) (2022) https://doi. org/10.1007/s41365-022-01133-8

  37. [45]

    IEEE Comput

    Duer, Z., Piilonen, L., Glasson, G.: Belle2VR: A Virtual-Reality Visualization of Subatomic Particle Physics in the Belle II Experiment. IEEE Comput. Graph. Appl. 38(3), 33–43 (2018) https://doi.org/10.1109/MCG.2018.032421652

  38. [46]

    : A method of detector and event visualization with unity in JUNO

    Zhu, J., You, Z., Zhang, Y., et al. : A method of detector and event visualization with unity in JUNO. Journal of Instrumentation 14(01), 01007 (2019) https: //doi.org/10.1088/1748-0221/14/01/T01007

  39. [47]

    Zhang, S., Li, J.-S., Su, Y.-J., Zhang, Y.-M., Li, Z.-Y., You, Z.-Y.: A method for sharing dynamic geometry information in studies on liquid-based detectors. Nucl. Sci. Tech. 32(2), 1–11 (2021) https://doi.org/10.1007/s41365-021-00852-8

  40. [48]

    : A method for detector description exchange among ROOT GEANT4 and GEANT3

    You, Z.-Y., et al. : A method for detector description exchange among ROOT GEANT4 and GEANT3. Chin. Phys. C 32(7), 572–575 (2008) https://doi.org/ 10.1088/1674-1137/32/7/012

  41. [49]

    Petriˇ c, M., Frank, M., Gaede, F., Lu, S., Nikiforou, N., Sailer, A.: Detector simu- lations with dd4hep. J. Phys. Conf. Ser. 898(4), 042015 (2017) https://doi.org/ 10.1088/1742-6596/898/4/042015

  42. [50]

    : Simulation software of the JUNO experiment

    Lin, T., et al. : Simulation software of the JUNO experiment. Eur. Phys. J. C 83(5), 382 (2023) https://doi.org/10.1140/epjc/s10052-023-11514-x arXiv:2212.10741 [hep-ex]. [Erratum: Eur.Phys.J.C 83, 660 (2023)]

  43. [51]

    Qian, Z., Belavin, V., Bokov, V., et al.: Vertex and energy reconstruction in JUNO with machine learning methods. Nucl. Instrum. Meth. A 1010, 165527 (2021) https://doi.org/10.1016/j.nima.2021.165527

  44. [52]

    Li, Z.-Y., Zhang, Y.-M., Cao, G.-F., et al.: Event vertex and time reconstruction in large-volume liquid scintillator detectors. Nucl. Sci. Tech. 32(5), 49 (2021) https://doi.org/10.1007/s41365-021-00885-z

  45. [53]

    Li, Z.-Y., Qian, Z., He, J.-H., et al.: Improvement of machine learning-based vertex 22 reconstruction for large liquid scintillator detectors with multiple types of PMTs. Nucl. Sci. Tech. 33(7), 93 (2022) https://doi.org/10.1007/s41365-022-01078-y

  46. [54]

    Yuan, Z., Song, T., Zeng, Y., Huang, K., Zhang, Y., You, Z.: Method for detector description conversion from DD4hep to Filmbox. Nucl. Sci. Tech. 35, 146 (2024) https://doi.org/10.1007/s41365-024-01506-1

  47. [55]

    Iusupova, A., Nemnyugin, S.: Geometry import into virtual reality visualization engine for HEP experiments at BM@N. Nucl. Instrum. Meth. A 1067, 169619 (2024) https://doi.org/10.1016/j.nima.2024.169619

  48. [56]

    https://github.com/HSF/Visualization (2017)

    HSF Visualization. https://github.com/HSF/Visualization (2017)

  49. [57]

    https://github.com/gttcz/FBXWriter.git (2025)

    FBXWriter. https://github.com/gttcz/FBXWriter.git (2025)

  50. [58]

    : Status and prospects of the JUNO experiment

    Ranucci, G., et al. : Status and prospects of the JUNO experiment. Jour- nal of Physics: Conference Series 888, 012022 (2017) https://doi.org/10.1088/ 1742-6596/888/1/012022 23

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.