{"id":"304ba9c8-3a99-49e0-b53c-0048a6a59686","arxiv_id":"2507.10261","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"A unified converter bridges four HEP detector geometry formats to FBX, enabling detector visualization in Unity.","lead":"This paper describes an automated pipeline that converts four common high-energy physics detector description formats (Geant4, ROOT, GDML, and DD4hep) into FBX, a standard 3D model format, and then displays the resulting detectors in the Unity game engine. If the approach is reliable, it gives particle physics experiments a much easier path to modern, interactive visualizations, event displays, and virtual reality tours.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The paper's central universality claim rests on the unvalidated geometric fidelity of the ROOT->GDML, DD4hep->Geant4, and GDML->Geant4 bridges and of the FBX tessellation; the only evidence is a single visual before/after of BESIII MUC, with no quantitative mesh-vs-CSG check.","rationale":"Reading the paper as a software-engineering demonstration, the tool evidently works on four real detectors and the screenshots are consistent with known detector layouts. However, the strongest claim is much broader than this demonstration. The reader's conditional verdict already captures the mismatch. I agree with the reader's identification of the weakest assumption: the corrected Boolean handling and the existing conversion bridges are trusted without quantitative evidence. The paper does not supply any precision metric, so the most load-bearing concern is not that the tool is broken but that the accuracy claim is under-supported. The proposed test would settle this by turning 'looks right' into 'measured right'. I would keep the verdict at CONDITIONAL: the concern does not warrant rejection because the tool is reproducible and the visual evidence is positive, but it does warrant a condition that the fidelity claim be quantified before the universality claim is accepted at face value.","tokens_in":12631,"tokens_out":5425,"duration_ms":64190,"concrete_test":"Use the provided GitHub code to add an end-to-end geometric regression test. Build one representative GDML file containing a union, an intersection, a subtraction (each with nontrivial rotation and translation), and a curved solid with known analytic volume. Convert it to FBX using the paper's FBXWriter, then import the FBX with an independent library (e.g., Assimp or trimesh) and compute the volume, surface area, and centroid of each sub-mesh. Compare against the exact CSG values and against the original placements. Repeat identical cases through ROOT-to-GDML and DD4hep-to-Geant4 to test those bridges. Require relative volume error below 1% (or a stated tolerance). Passing this for all four routes would support the universality claim; failing it would show the Section 3.2 fix is incomplete or the intermediate converters are lossy.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that all four detector-description routes produce a faithful FBX representation. This claim bears weight on a chain of unvalidated conversions: ROOT files are passed through the ROOT-to-GDML interface, GDML files are parsed through the GDML-to-Geant4 interface, DD4hep descriptions are constructed inside Geant4, and only then does G4Polyhedron/FBXWriter tessellate the solids. The paper asserts these interfaces are 'convenient' and 'robust' but does not verify their output. The single geometric defect discussed, the Boolean operation mismatch in Section 3.2, is fixed by an unspecified 'straightforward correction of the rotational and translational order'; no diff, unit test, or list of covered Boolean solids is given. Moreover, the FBX output is a faceted approximation of CSG geometry, with a user-adjustable rotation step, yet no error bound or fidelity metric is reported for the tessellation. The evidence consists of screenshots and one before/after visual pair (BESIII MUC). If any intermediate converter loses a volume or applies a wrong transform, the FBX mesh can look plausible while being silently wrong, and nothing in the current paper can detect that. This makes the 'universal' accuracy claim conditional rather than demonstrated.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":12909,"tokens_out":2479,"duration_ms":29298,"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":[{"comment":"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.","section":"Section 3.2 and Figure 4"},{"comment":"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.","section":"Section 3.2 and Figure 2"},{"comment":"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.","section":"Section 3.2 and Section 4.5, Table 1"}],"minor_comments":[{"comment":"There is a typo in 'detaily shown in Figure 3'; it should read 'shown in detail in Figure 3'.","section":"Section 3.2"},{"comment":"The phrase 'an executable program combing the GDML-Geant4 interface' should read 'an executable program combining the GDML-Geant4 interface'.","section":"Section 4.3"},{"comment":"The table heading has a spacing issue: 'T able 1The time consumption' should be 'Table 1: The time consumption'.","section":"Table 1"},{"comment":"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.","section":"Figure 4 caption"},{"comment":"The title of reference [54] uses 'Filmbox' instead of the standard 'FBX'; please make the naming consistent.","section":"Reference [54]"},{"comment":"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.","section":"Figures 6 and 7"}],"recommendation":"major_revision","confidential_remarks":"The paper is a useful software/engineering contribution, and the availability of the converter source code is a genuine strength. The main risk is overclaiming universality and fidelity without quantitative validation of the conversion chain. I would recommend requiring the geometric-accuracy checks described in the major comments before publication, since they are feasible within the scope of the paper and would substantially raise confidence in the tool."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a solid software-tool paper that delivers something genuinely useful — a single pipeline that takes Geant4, ROOT, GDML, or DD4hep detector descriptions and turns them into FBX for Unity, demonstrated on JUNO, EicC, BESIII, and CEPC. The demonstrations are convincing at the level of 'we can see the detector in Unity', and the performance table gives concrete numbers. The code is on GitHub. That is real work and a real contribution; I'd cite it.\n\nThe main soft spot is exactly what the stress-test note flags: the accuracy of the final mesh is never quantitatively checked. The pipeline uses ROOT->GDML, GDML->Geant4, and DD4hep->Geant4 bridges, then G4Polyhedron tessellation, and the only geometric validation we get is screenshots plus one before/after of the BESIII MUC Boolean-op bug. No diff, no unit tests for Boolean solids, no error bound for the rotation-step tessellation. The 'universal' claim is also a bit strong — you're not converting ROOT or DD4hep directly, you're going through Geant4 as a bridge, and one-way. The paper does acknowledge the one-way part, but not the fidelity gap.\n\nIs that fatal? For a tool paper, not necessarily. Visual inspection is often the actual use case, and the authors are honest that the conversion is for visualization, not simulation-grade geometry. But the language in the abstract and advantages section ('strict consistency', 'seamlessly convert', 'accurate') overreaches. A serious referee would want at least one quantitative check — e.g., comparing a few known CSG solids' volumes or surface normals against the FBX mesh, or a tolerance-based diff on a test geometry.\n\nMinor: the EicC numbers in Table 1 look odd (0.2 s, 30 polygons for a full detector) — probably a simplified test geometry, but it should be stated. The code isn't pinned to a commit, which hampers reproducibility.\n\nOverall: worth reviewing seriously, and likely publishable after the fidelity language is tempered and one quantitative validation is added. I'd send it to peer review rather than desk reject.","headline":"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.","tokens_in":13434,"tokens_out":1983,"would_cite":true,"duration_ms":22364,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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…","keywords":["detector description","FBX","Unity","Geant4","GDML","DD4hep","ROOT","geometry conversion"],"falsifier":"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.","tokens_in":12453,"feed_emoji":"🎮","tokens_out":6627,"duration_ms":63731,"temperature":0.7,"pith_summary":"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.","feed_headline":"Four HEP detector formats now convert to Unity-ready FBX","feed_subtitle":"A Geant4 bridge plus a Boolean-geometry fix brings industrial 3D tools to detector visualization.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the Geant4 toolkit that acts as the central conversion hub, including the G4Polyhedron polygonization used to turn CSG solids into meshes.","marker":"[3]"},{"why":"Defines GDML, the geometry markup language that lets ROOT and other geometries be imported into Geant4.","marker":"[5]"},{"why":"Provides DD4hep, whose Geant4 interface feeds DD4hep detector descriptions into the conversion pipeline.","marker":"[6]"},{"why":"Supplies the ROOT framework and its geometry export path to GDML for ROOT-based detector descriptions.","marker":"[26]"},{"why":"Presents the method for exchanging detector descriptions among ROOT, Geant4, and Geant3 that underlies the format bridging in this work.","marker":"[48]"},{"why":"Hosts the FBXWriter code that exports Geant4 geometry to FBX, the core export step of the pipeline.","marker":"[56]"},{"why":"Describes the earlier BESIII-specific GDML-to-Unity workflow that this universal interface generalizes.","marker":"[44]"}],"fun_headline_variants":["Four HEP detector formats now export to Unity-ready FBX","Unified pipeline: Geant4, ROOT, GDML, DD4hep to FBX for Unity","HEP detectors get Unity-ready: new converter supports four formats","Universal FBX exporter turns HEP geometries into Unity models","From Geant4 to Unity: converting all major HEP formats to FBX"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Four HEP detector formats now export to Unity-ready FBX","Unified pipeline: Geant4, ROOT, GDML, DD4hep to FBX for Unity","HEP detectors get Unity-ready: new converter supports four formats","Universal FBX exporter turns HEP geometries into Unity models","From Geant4 to Unity: converting all major HEP formats to FBX"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000318,"raw_usage":{"total_tokens":1752,"prompt_tokens":858,"completion_tokens":894,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":474,"completion_tokens_details":{"reasoning_tokens":795}},"tokens_in":474,"tokens_out":894,"duration_ms":9283,"temperature":1.0,"reasoning_tokens":795,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T17:35:27.504546+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"IEEE Trans","cited_arxiv_id":null,"evidence_quote":"Defines GDML, the geometry markup language that lets ROOT and other geometries be imported into Geant4."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the ROOT framework and its geometry export path to GDML for ROOT-based detector descriptions."},{"cited_title":": A method for detector description exchange among ROOT GEANT4 and GEANT3","cited_arxiv_id":null,"evidence_quote":"Presents the method for exchanging detector descriptions among ROOT, Geant4, and Geant3 that underlies the format bridging in this work."},{"cited_title":"https://github.com/HSF/Visualization (2017)","cited_arxiv_id":null,"evidence_quote":"Hosts the FBXWriter code that exports Geant4 geometry to FBX, the core export step of the pipeline."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Describes the earlier BESIII-specific GDML-to-Unity workflow that this universal interface generalizes."}],"review_version":1}