Set touchable visibily in Qt

Andrea · April 6, 2021, 1:33pm

Hello,

I have a question about the visiblity of touchables in Qt.

When I open the Qt GUI, I create a OGLSQt viewer and then I’m able to draw all the volumes in my geometry using the command /vis/drawVolume world.
Now, if I open the “Scene tree” tab in the GUI, i can change the visibility of the different touchables by clicking in their checkbox.

If I set the visibility of some touchables to FALSE and then I execute a run, these touchables disappear from the “Scene tree”.

To make them be there again I have to set their visibility to TRUE, but I have to do it one by one by setting the corresponding touchable and setting the vibility to true.
(/vis/set/touchable … and /vis/touchable/set/visibility true)
With this procedure I have to know the name and copy number of all volumes and set the visibility one by one.

Questions:

Is it normal the the volumes disappear from the “Scene tree”, or I’m doing something wrong?
Is there a way to set the visibility of ALL touchables to TRUE at the same time to make all of them reappear in the tree?

I hope that the problem is clear.

Any help is appreciated.

Thank you

allison · June 15, 2021, 10:48am

Hi Andrea

I see your posting was back in April. I marked it for attention but, sorry, it got forgotten. I hope you have found a good way of doing what you want.

Yes, the ability to set the visibility and colour of touchables in the Qt GUI is very nice. In principle, every action is paralleled by the /vis/touchable commands and recorded in the view parameters so the they can be transmitted to other viewers if required. And I’m not sure we’ve got that totally right.

Mmm. I don’t see your symptom. With B1, if I make, say, Shape1 invisible by a click in the scene tree widget, then /run/beamOn, it stays in the scene tree widget, and I can bring it back with another click.

Even if I force a rebuild (/vis/viewer/rebuild), it’s still there and can be brought back.

So I don’t know what’s happening for you. What G4 version are you on?

You can undo all the clicking with /vis/viewer/clearVisAttributesModifiers…but, oops, no, the VAMs get cleared but the viewer does not respect it. Mmm. A bug.

You could use /vis/geometry commands. They change the vis attributes of the logical volume, and therefore of all physical volumes that are daughters. And this can be propagated to granddaughters. /vis/geometry/set/visibility Envelope -1 true sets visible every volume from Envelope down - but again the viewer does not respect it. (This seems to be true of OGLSX as well as OGLSQt.) We will have to look into this.

Sorry not to be more helpful. But looks like you have found a bug - even if not the one you thought! And that’s very helpful - thanks.

Note: /vis/drawTree helps with names and copy numbers.

allison · June 15, 2021, 11:45am

The bug referred to in my last post was in my development version - thanks for helping me spot it. So please try my remedies to your Question 2.

John

Andrea · June 18, 2021, 7:59am

Hi John,

Thank you very much for your answer!

First of all, I have to correct myself because the command sequence that makes the touchables disappear from the Scene tree is this:

Set the visibility of a touchable to False from the Scene tree
Cut the geometry with: /vis/viewer/addCutawayPlane 0 0 0 m 0 -1 0
The cut touchables disappear from the Scene tree.

Also, if I remove the cut plane with /vis/viewer/clearCutawayPlanes the missing touchables are still not visible.

I have attached four screenshots:

The initial geometry
Set the visibility of some touchables to False
Addthe cut plane and show the Scene tree
The complete geometry with the cut plane

Is this behavior correct or is it a bug?

About the solutions:

The command “/vis/viewer/clearVisAttributesModifiers” works perfectly! If I use it the touchables reappear in the Scene treee
The command “/vis/geometry/set/visibility world -1 true” doesn’t have any effect. It only makes the world volume visible but the missing touchables are still missing.

Thank you for your help!

Andrea

P.S. I’m on G4.10.07.p01

allison · June 18, 2021, 1:35pm

That seems to me to be what one would expect. The command /vis/viewer/addCutawayPlane causes a rebuild.

OK. But they have already been “removed”.

Seems OK to me. What, exactly, is not as you would expect?

Mmm. Although you have set the visibility of all volumes to true, your viewer still “remembers” that you have asked for the “missing” touchable to be made invisible and it communicates this to the physical volume model that sends volumes to the graphics driver for rendering. If you open a new viewer (/vis/open OGL), it would not have this “memory”. Please try it and let us know what happens.

It looks like you are finding your way around the G4 vis system very well. We are always ready to fix bugs and make improvements to our system so you feedback is invaluable.

John

Andrea · June 20, 2021, 7:18am

Seems OK to me. What, exactly, is not as you would expect?

If I set the visibility of a touchable to False, I expect that it will not be visible anymore, but the touchable should still be there…
So, if I cut the geometry I think that also the “invisible” touchable will be cut but it is not visible.
In this case, I should be able to make it visible again, and it should be rendered with the correct cut.

Mmm. Although you have set the visibility of all volumes to true, your viewer still “remembers” that you have asked for the “missing” touchable to be made invisible and it communicates this to the physical volume model that sends volumes to the graphics driver for rendering. If you open a new viewer (/vis/open OGL), it would not have this “memory”. Please try it and let us know what happens.

I confirm that if I run the command “/vis/geometry/set/visibility world -1 true” and then “vis/open/OGLSQt” the complete geometry is rendered.

Thank you
Andrea

allison · June 20, 2021, 11:25am

Hi Andrea

Thanks for persisting with this. There is indeed an issue here.

The question is: when is it necessary to force a rebuild? As I said, adding a cutaway plane - actually only the first time and after clearing - causes a rebuild (I will explain why later). And as I explained, that makes the invisible volume “go away”.

If you reverse the order:

i.e., add cutaway plane first, then click to make invisible, you will find you can click it back to visibility - it does not go away.

The issue is this. Normally, for the OpenGL series of vis drivers, we we take advantage of “back plane culling”. For opaque objects in surface drawing mode, the “back planes”, i.e., the ones facing backwards from the viewing angle, are not rendered. This is just a performance improvement - we could render them, and all that would happen is they get overwritten by the from planes in the “z-buffer” rendering algorithm. (The performance improvement is probably not great.) But then, when you apply a cutaway plane, you can “see” the back planes of the cut objects and they aren’t there!! It looks weird.

In G4OpenGLStoredQtViewer.cc, you could try commenting out the line (about l.128):

      (lastVP.IsCutaway ()          != fVP.IsCutaway ())          ||
      // Cutaways implemented locally.  But still need to visit kernel
      // if status changes so that back plane culling can be switched.

and I think that will give you the behaviour you expect, but the cut solids will look strange. It is this line that triggers a rebuild. Switching back plane culling on or off requires a rebuild - I don’t see any way around that.

I’m not sure how to resolve this dilemma. If we disable back plane culling we would not need to trigger a rebuild, and we would get the behaviour you expect without the strange images. We would have to look at the performance penalty for other applications. Alternatively we could have a user option - /vis/viewer/backPlaneCulling [true|false] - with default true. Perhaps that’s the way to go.

Any thoughts would be appreciated.

John

Andrea · June 20, 2021, 5:16pm

I tried to comment out the line 128 in G4OpenGLStoredQtViewer.cc and the behavior is what I expect but you are right, the solids look strange…

It is this line that triggers a rebuild. Switching back plane culling on or off requires a rebuild - I don’t see any way around that.

Since the command /vis/viewer/clearVisAttributesModifiers works, this behavior is no longer so annoying !

I’m not sure how to resolve this dilemma. If we disable back plane culling we would not need to trigger a rebuild, and we would get the behaviour you expect without the strange images. We would have to look at the performance penalty for other applications. Alternatively we could have a user option - /vis/viewer/backPlaneCulling [true|false] - with default true. Perhaps that’s the way to go.

I agree, a user option like this could be useful in a lot of cases!
So, if the user switches the back plane culling to false, could the rebuild for cut plane automatically be disable?
something like: (lastVP.IsCutaway () != fVP.IsCutaway () && backPlaneCulling) ||

It is a bit off-topic but I’d like to point out this effect:
Are there a way to avoid the artifacts shown in the following picture?

Thank you so much for all your help!

Andrea

allison · June 23, 2021, 9:01am

Hi Andrea

Yes. Exactly.

This could be because the brown and green surfaces in your geometry are coincident, or very nearly so, at that position, so the z-buffer algorithm of OpenGL struggles to decide which is nearer. You could try making the brown cylinder a slightly smaller radius. Otherwise. not much one can do given our relatively simple graphical representations in Geant4.

John