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.
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.
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.
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)
In principle EVE should support loading of the same geometry multiple times, see this: ROOT: TEveManager Class Reference
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
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
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
My first thought is still to try to “clean” each view removing all the volumes that are not needed in a given view.
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
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.
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?
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…
Argh … I’m sorry, this never worked as I thought it does
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? 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?
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.
