Then one can build a specially crafted hierarchy of mother volumes to outline the detector geometry for event-display. This can be done from the TGeo geometry by removing all un-needed nodes from the hierarchy (select, hit ‘Delete’ key), exporting the TEveGeo node you want to have as the top node to CINT (via context menu) and calling: evenode->SaveExtract(file, name). This saves a hierarchy of TEveGeoShapes that represent the geometry elements that are existing in the eve list-tree view below the selected node.
Cheers,
Matevz[/quote]
Hello Matevz,
Could you elaborate on this procedure further? What application allows you to delete out subvolumes with the Delete key?
In EVE list-tree widget the outlined entry (selected, but can be changed by up/down keys) can be removed from the parent determined by the list-tree hierarchy via the ‘Delete’ key. This will cause the element to be automatically deleted if this was its last point of attachment and it is not protected agains automatic destruction (via IncDenyDestroy()).
Now, to give you details, it would help to know that we are talking about the same thing / use-case. I assume you have a TGeoManager and show the geometry from certain TGeoNode downwards via TEveGeoTopNode (as is done in tutorials/eve/geom_cms.C, for example). Is this true?
Do you want to extract sub-parts of this geometry to show them independently of the geo-manager? This is the procedure I was describing before.
If all you want to do is change settings of TGeoVolume/Node visibility, you can simply iterate over daughters of given volume and set visibility flags, colors etc. – recursively if you need it so. You can also use TGeoManager::cd(path) to get to a specific node in the hierarchy where you want to start / make the change.
In EVE list-tree widget the outlined entry (selected, but can be changed by up/down keys) can be removed from the parent determined by the list-tree hierarchy via the ‘Delete’ key. This will cause the element to be automatically deleted if this was its last point of attachment and it is not protected agains automatic destruction (via IncDenyDestroy()).
Now, to give you details, it would help to know that we are talking about the same thing / use-case. I assume you have a TGeoManager and show the geometry from certain TGeoNode downwards via TEveGeoTopNode (as is done in tutorials/eve/geom_cms.C, for example). Is this true?
Do you want to extract sub-parts of this geometry to show them independently of the geo-manager? This is the procedure I was describing before.
If all you want to do is change settings of TGeoVolume/Node visibility, you can simply iterate over daughters of given volume and set visibility flags, colors etc. – recursively if you need it so. You can also use TGeoManager::cd(path) to get to a specific node in the hierarchy where you want to start / make the change.
Cheers,
Matevz[/quote]
Hello Matevz,
Yes, I have an adapted version of geom_alice_its working where I basically just load my geometry instead (I made one for the PHENIX silicon vertex detector). I also made a modified version to set the transparency high for everything but the regions of interest (briefly, I want the sensitive volumes to be the predominant visual in the scene). It’s quite slow, though, probably because the geometry is too crowded. I want to try deleting the endcaps and support structures, and if that’s not enough, simplify down what else remains.
I have some screenshots showing how far along I’d gotten before classes started back in:
One more question, if I may: is there a way of doing this deletion of the TEveGeoNodes from a script? In my case there are a very large number of nodes to individually click and delete to get the shape extract I want. Ideally I’d like to just tell a script to delete every node whose name matches some criterion (regex or substring match, ideally, or since they are sequentially numbered, loops could also be used).
Sorry for not replying earlier, actually took a day off the net
You can just say:
parent->RemoveElement(el_to_remove);
or brutally destroy it:
el_to_remove->Destroy();
The problem here is that you first need to populate the children sub-trees to be able to traverse them, see TEveGeoNode ExpandIntoListTrees() and ExpandIntoListTreesRecursively(). If your geometry is big, this can grow really big.
Another option would be to just put in the elements that you need and add them manually, like:
TEveGeoNode *parent; // representing TGeoNode geoparent
for daughters geod of geoparent
daughter = new TEveGeoNode(geod);
parent->AddElement(daughter);
The problem here might be that you need to recurse quite deep before you can tell if this sub-tree needs to be used. And, of course, all the items in the hierarchy need to be present, too, otherwise the transformation matrices will not get stored properly when dumping a shape extract.
But on the positive side, you traverse TGeo geometry directly and there is less chance to blow up memory usage.
Let me know if you need more detailed example – can make one running on the alice geometry.
[quote=“matevz”]
Let me know if you need more detailed example – can make one running on the alice geometry.
Cheers,
Matevz[/quote]
Please do so. I have tried recursive traversals using the Destroy/Remove methods, but nothing seems to make anything disappear from the final display (other than my manually unchecking volume names in the browser).
(EDIT: Scratch the above, it looks like it is removing the volumes I want removed from the “Geometry scene” - those changes are merely not being reflected in the display. This ought to be good enough for me to get a shape extract though).
(EDIT: That didn’t work either. The shape extract comes up with only the volumes I had in there saved out - but the viewer still draws everything!! I am at a loss.)
Don’t hesitate to ask if you have further questions … I know this is far from trivial
Cheers,
Matevz[/quote]
It worked! My shape extract looks exactly as I want now, in terms of volumes I want shown or not. I was able to cut and paste from the demo directly and needed only a few minor changes to the project-specific lines.
Now (and maybe I should split the thread?), I would like to be able to set the colors and transparencies of my volumes. Before I’d been doing this in TGeo with techniques similar to the “geo” tutorial scripts. How does it work with the shape-extracts?
No need to change the thread … we got already quite far away from the original title anyway
So … if you change color and transparencies of the volumes before extraction, this will be saved to the shape-extract.
Another option is to load the shape-extract and then loop over the TEveGeoShape hierarchy and call one of the SetMainColor() / SetMainTransparency() functions from the base-class TEveElement. After setting the color, you can save a modified extract using corresponding functions in TEveGeoShape: root.cern.ch/root/htmldoc/TEveGe … aveExtract
or root.cern.ch/root/htmldoc/TEveGe … iteExtract
You just call this on the “top” shape and all the hierarchy below will be saved.
I was not able to resolve this issue. I’ve attached an excerpt of my failed attempts - it is a modified version of the descend_extract function from the updated tutorial script in your last post. There are calls to alter transparencies, but the calls to not appear to have any visual effect.
Could I perhaps instantiate a new medium and somehow replace the one it loads (the Silicon medium)?
I’m now using a regularly updated checkout of the subversion trunk for ROOT for this project. However, our experiment uses version 5.17 with little reason to believe they will upgrade any time soon. So, while I’d love for my viewer to be able to dig directly into the files output from reconstruction and so forth, there appears to be no realistic approach for doing that. I’m going to have to use an intermediate format, something written out by the software built on v5.17, but that won’t rely on having any of the experiment’s libraries available to read it back in (I’ve made some attempts to rebuild the libraries in question, but that’s already proven to be far more trouble than it is worth).
Before I embark on inventing my own new format, what about these “ESD” and “VSD” files used in the demos? Are those really experiment-independent? Is there any documentation on the file formats? How were the ones used in the EVE demos generated?
alice_esd.C showd the real ALICE event summary data (ESD). The minimal classes to read it are generated automatically with TFile::MakeProject(). So, if your experiment saves TTrees you can use the same concept.
alice_vsd.C reads “visualization summary data” (VSD) trees … it is generated with a special job in aliroot that reads the data (ALICE classes) and writes out the VSD. See:
So … ESD is experiment specific but read with root only, VSD is using Eve classes to store the data. Of course, you can also define your own containers and fill them into root files in whatever format suits you best. Can you tell us some more about your data, like sizes and numbers of different objects in an event?
In principle it is much much better to be able to read the experiment files directly.
In CMS there is a “light version of experiment software” that only holds data formats and other core stuff needed to read the data – this is enough to run analysis and event display.
The data is reconstruction output from a vertex detector; we have hits, clusters, and different forms of track, in varying number. One of the track formats uses a Runge-Kutta method and has hundreds of points per track, but is not always used. Also, the events can be p+p or gold-gold, so the counts per event can vary significantly.
I think I may yet pursue the possibility of recompiling stuff under v5.27, just for that added convenience. In the meantime, I believe this should be enough to work with.
