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?