New visualisation by reference edits alpha value of referenced VisAttr

[simonge]

Setting the values of a new VisAttr by reference to another by name, then changing some results in the alpha of the original being edited. All other original attributes remain unchanged.

e.g. The alpha of AnlGray is changed to 0.3 by the following line
<vis name="TransparentGray" alpha="0.3" ref="AnlGray" showDaughters="true" visible="true"/>

I believe the problem is in the function VisAttr::argb from Objects.cpp
alpha = o.alpha;
may be better as
alpha = o.alpha();

[simonge]

The bug appears to be more complicated than I thought at first. Trying to further understand my problem

[MarkusFrankATcernch]

This is far more complex, because VisAttrs are only partially represented in ROOT by TColor.
The rest is embedded in the inheritance structure of TGeoVolume.

This would leave you with a very difficult mechanism to properly update all dependent objects if
you would change alpha as you would like in the code snippet above.

[simonge]

What I now see is the transparency of seemingly unrelated detector components being set by a different VisAttr. This is dependant on the order the detectors were included in the xml description.

[MarkusFrankATcernch]

To me it looks like ROOT inherits the transparency from the parent volume.
This means the alpha of a n-level daughter is the product of it's own alpha with all alphas of the parent path.
This makes sense if you think of subdetector (or elements thereof) as individual modules you simply group together.
Anyhow, this would not be addressed by your suggestion.

[MarkusFrankATcernch]

@simonge What should we do with this issue?
I would propose to close it. There is simply no solution to it.
The internals of TGeo are simply not prepared to handle visualization attributes like this.
Hence there is nothing one could do here from outside.

[simonge]

Feel free to close it. I still need to follow up on where the issue is coming from, might be somewhere in ROOT rather than DD4hep. The order/whether detectors are included shouldn't really be able to effect the visualisation of other unrelated detectors.

[MarkusFrankATcernch]

The order how subdetectors are included should not affect the visualization.
According to my experience it also does not.
What matters however is the hierarchy.
Alpha values of parents (transparency) also affects the transparency of the children of these parents.

[simonge]

I have replicated this with a minimum example with in both the geant4 and ROOTJS geometry visualisation (see attached pictures)

In the example xml file linked here, just swapping around the order Tube1 and Tube2 are in the file (or swapping their colours) should demonstrate the effect. Hopefully should just be able to use it out of the box.

Link to xml

[MarkusFrankATcernch]

@simonge Thanks a lot for your help!
I will try to reproduce it with pure ROOT (no dd4hep).
Otherwise I cannot file a bug report if the problem is not in dd4hep itself.
I am afraid it will take a bit.

Just for completeness: Do you get the same result with geoDisplay ?

[MarkusFrankATcernch]

I discussed with the ROOT guys. To handle the transparency for volumes properly changes in ROOT shall be required.
This will take a while -- and once I made the MR in ROOT a new ROOT version -- I am afraid.

[MarkusFrankATcernch]

This PR root-project/root#13402 should eventually fix the problem.

[simonge]

That's great thanks.
I hadn't noticed the link with the material, changing it seems to fix the problem in the ROOTJS viewer but has no obvious change in the behaviour in Geant4

[MarkusFrankATcernch]

Assumed fixed with latest ROOT. Closed due to no reaction.