Turn ON/OFF different geometry volumes in in different geometry scenes in Eve

Dear ROOTers (even if I already know this is a question for @matevz)

I have a Eve application setup with three different viewports showing the same event from three different orthographic projections.
Since there are always some elements of the geometry between the camera and the hits I draw in each projection I would like to find a way to select specific volumes and disable their rendering in a particular geometry scene.
I can’t find a way to do this, I tried all possible variant of SetRnr* but if I disable one volume in the “XY projection” geometry scene it disappears also from the other two scenes.

I attach a small reproducer that I’ve been using to toy around. A few of the things I tried are in the CleanScene function but none produces the desired result.
test.C (3.7 KB)

I also tried to copy/duplicate the geometry, with the idea of having three of them so I could remove elements from each scene as I saw fit, but apparently TGeoManager cannot be copied anymore and you’re supposed to have a unique global object for the geometry.

Any help is deeply appreciated as alwasy.

Cheers,
Valerio


ROOT Version: 6.20/00
Platform: Ubuntu 20.04
Compiler: GCC 9.3.0


Hi Valerio!

Yes, geo-manager state is global, there’s no way about it, the drawing state is stored in TGeoNodes / Volumes so it’s the same everywhere.

You have two options:

  1. In principle EVE should support loading of the same geometry multiple times, see this:
    https://root.cern.ch/doc/master/classTEveManager.html#a9863a05d1c2ea2719cd56754335d1155
    There is a possibility TGeoManager loader is “smarter” and detects the files or geometries are the same … I will try it out as well.

  2. You could use TEveGeoShapeExtracts to save a (simplified?) geometry and then laod this several times. Or create custom extracts for each view, if this works for you. This is somewhat complicated to start with but there were several people who managed to get it done with some help (probably there are several threads on the forum as well, let me know if you’re interested in this option).

How about making the geometry transparent? You might be able to push it further back in the view … but it’s possible I’d have to hack a way to apply this to tgeo shapes. I’ll try this too.

Cheers,
Matevz

Yup, the alias method works, see the modified test.C:

test.C (4.2 KB)

The docs for RegisterGeometryAlias() say you can get the geomanager by calling gEve->GetGeometryByName(name) … but it is gEve->GetGeometryByAlias(alias).

TEveGeoManagerHolder allows you temporarily set gGeoManager to some value in constructor and set it back to the previous value in destructor.

Cheers,
Matevz

Hmmm it would seem you can load the same geometry multiple times but I’m afraid it doesn’t work either. Whenever I then call SetRnrState on a given element it gets removed from all scenes, so it looks like the underlying geometry object is still the global one.
(by the way, In your version of the macro I still see both boxes in all scenes)

Going back to the previous reply:

In principle EVE should support loading of the same geometry multiple times, see this:
https://root.cern.ch/doc/master/classTEveManager.html#a9863a05d1c2ea2719cd56754335d1155
There is a possibility TGeoManager loader is “smarter” and detects the files or geometries are the same … I will try it out as well.

Yeah the thing I’m afraid of is exactly this: if the underlying geometry is still the same then removing one element from a scene will remove it from everywhere else as well :frowning:

You could use TEveGeoShapeExtracts to save a (simplified?) geometry and then laod this several times. Or create custom extracts for each view, if this works for you. This is somewhat complicated to start with but there were several people who managed to get it done with some help (probably there are several threads on the forum as well, let me know if you’re interested in this option).

This might look like a viable solution, I’d like to try it. Can it be done in memory without having to dump on file? I’m trying to avoid having dedicated rootfiles just for the geometry, also because in the framework for this application the geometry comes directly as a TGeoManager* provided by an upstream service.
I’ll start to poke around the class documentation right now!

How about making the geometry transparent? You might be able to push it further back in the view … but it’s possible I’d have to hack a way to apply this to tgeo shapes. I’ll try this too.

The geometry is already at 99% transparency, and some of the volumes are still getting in the way :disappointed:


Also seems like some volumes don’t really respect the MainTransparency setting. I’m still trying to figure this out. On top of this, the geometry is converted from the original Geant4 code to TGeo using VGM, so I’m wondering if there is a point anywhere in this pipeline where I could act to improve the situation :thinking:
My first thought is still to try to “clean” each view removing all the volumes that are not needed in a given view.

Cheers,
Valerio

I tested the multiple geometry case and it worked ok, I was able to hide a box in view view only by toggling the draw state of TEveGeoNode in respective geometry sub-tree.

It is the same geometry but it is instantiated multiple times, so all drawing state and colors are separate.

If you send me your version of the code, I can look at it again. Have you tried running the modified example I sent back and flipping the “visible” switch for one of the boxes in GUI editor?


Ah, you want to create those in-memory, that’s easier than creating a shape extract :slight_smile:

You basically need to create a hierarchy (or list) of TEveGeoShape objects where you set each of them up with TGeoShape (it gets cloned) and global transformation matrix from TGeo geometry. Take a look at this code:

This is how modules that are hit are created for ALICE ACCORDE cosmic trigger visualization.

Cheers,
Matevz

Have you tried running the modified example I sent back and flipping the “visible” switch for one of the boxes in GUI editor?

My bad, I was to focused on doing it programmatically that I didn’t even check the GUI! Can confirm, this works and I think I’m ok with the multiple-import solution, looks way easier.

Now the next question would be: What’s the corresponding way of switching the visibility on the C++ side? :thinking:

Ok, according to TEveGeoNodeEditor.cxx:96 I should call SetRnrSelf() but if I do so the boxes disappear from all scenes again. I don’t get it, how come it’s working in the GUI code but not in the application? I think I’m doing the same thing, but there must be some difference I’m unaware of…

I attach the “updated” macro test2.C (3.8 KB)

Argh … I’m sorry, this never worked as I thought it does :frowning:

TEveManager in reality works with filenames, not aliases, and TGeoManager looks into a global list to see if a geometry is already loaded (by name, I assume). So there were two places where this things goes wrong.

The reason it worked from the GUI was that EVE is very “smart” about the updates and it only did redraw of one gl viewer, the one that held the scene where the visibility was toggled.

Also, TGeoManager::Import deletes previous gGeoManager, if it exists … so this concept is like a snake-pit, sigh.

Now, I was able to work around this by saving the geometry three times in a different root file, using a different name for the geometry (not sure if this is necessary … nope, seems not, went through TList, TNamed, TObject … it checks pointer equality), and by setting gGeoManager to 0 before calling import … but this is getting way too hackish and I’m not sure if I haven’t missed some other implicit behavior and thing just works because there is nothing else going on in the program.

Are you willing to try it anyway? :slight_smile: I can cleanup the test2.C I have and send it back, it sure doesn’t look pretty right now …

How many shapes do you expect to have in your real-world setup? Shall we try getting it to work with copying the shapes out of a TGeo, like the ALICE ACORDE example above?

Sorry again for the mess & Cheers,
Matevz

Shall we try getting it to work with copying the shapes out of a TGeo, like the ALICE ACORDE example above?

Yes I think it’s better to switch to plan B, let’s avoid hacking too much :slight_smile:

I’ll take a look at the example and try to figure out how it works, if you have any suggestion for a starting point let’s use the existing toy macro!

Cheers,
Valerio

test2.C (4.0 KB)

Here it is … it imports all shapes and then filters them out / sets visibility to false … i don’t know if you might need them to be there at some point.

Cheers,
Matevz

Nice, this looks like a viable solution. I’ll try to implement it in the main application and see what comes out.

Cheers,
Valerio

Yep, that works, and it’s more or less what I was looking for :slight_smile:

Thanks!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.