Why loadRootGeometry relies on loadJSONGeometry?

[DraTeots]

Working on reading DD4Hep geometry figured that essentially the core of the function is:

await this.loadJSONGeometry(
      build(obj, { dflt_colors: true }).toJSON(),
      name,
      menuNodeName,
      scale,
      doubleSided,
      initiallyVisible,
    );

Where build(obj, { dflt_colors: true }) is a fundamental function from TGeoPainter.mjs of JSRoot, which returns three.js Object3D. The Object3D in turn could be loaded directly through processGeometry of the ImportManager without hassle of converting to Json and importing through Json loader.

Is it just historical or are there other reasons for that?

The context why I would like to discuss this. I would like to have a bit more control over the geometry after it has been added to Three.js tree. But a lot of data is being stripped during the conversion and navigating and working with geometry children become cumbersome.

Jsroot build method strips some information jsroot 303, still it has some initial information: jsroot 304. But after going through toJSon - loadJSONGeometry the nodes information is stripped off completely. Even meshes are nameless (or maybe I miss something?). Moreover, the same name that was provided to loadJSONGeometry is used as Meshes name. Is that on purpose to easier grab all meshes that relate to that imported part?

P.S. I am trying to figure out how it works and what are the design ideas to be helpful.

[EdwardMoyse]

Hi @DraTeots - sorry for the late reply! I'm afraid I don't know this code super well.

Perhaps @emiliocortina @9inpachi @kjvbrt might know more?

[GaneshPatil7517]

Hi @DraTeots, this is a great question I traced through the full pipeline while working on the codebase and can share what I found.
cc @EdwardMoyse

Why the JSON round-trip exists:

The pipeline is: build(obj, { dflt_colors: true }) → .toJSON() → ObjectLoader.parse() → processGeometry(). This looks redundant since build() already returns a perfectly good Object3D, but the JSON step serves a few purposes:

1. Material replacement - Phoenix doesn't use the materials JSRoot creates. processGeometry() traverses every mesh, extracts just the color hex value, disposes the original material, and replaces it with a MeshPhongMaterial configured with Phoenix's clipping planes, flat shading, and opacity support. The JSON round-trip gives a clean deserialized object to work with rather than mutating JSRoot's live scene graph.

2. Unified entry point - loadJSONGeometry() is the shared path for all geometry formats (OBJ, GLTF, JSON files, and ROOT). Going through it means every geometry gets the same processGeometry() treatment, menu registration via ui.addGeometry(), and loading manager tracking. Bypassing it to use processGeometry() directly on the Object3D from build() would skip the UI and loading manager integration.

3. Serializability - JSON geometry can be cached, transferred, or stored independently of JSRoot.

On the stripped node information:
You're right that mesh names get overwritten. In processGeometry(), every child mesh gets child.name = child.userData.name = name where name is the top-level geometry name (e.g., "DIRCexperiments"). This is intentional for Phoenix's UI menu system - all meshes under one loadRootGeometry() call are grouped under a single visibility toggle. But it does mean the original per-node hierarchy names from the ROOT TGeo tree are lost.

If the goal is to preserve the TGeo hierarchy and allow per-node visibility control, the direct processGeometry() on the build() output approach you're suggesting would make sense - but it would also need changes to how meshes are registered in the UI menu (currently one toggle per geometry group, not per TGeo node).

This could be a useful enhancement - exposing the TGeo node tree in the Phoenix menu instead of flattening it. Would that be useful for your DD4Hep work?