I am a Root newbie, working with Root geometry files generated using
g2root from Geant3 files. I want to be able to draw my detector,
with the drawing attributes (color, line thickness, etc.) of each volume
customized.
In Root 3.02, I could do this by calling drawing parameter methods on
each node in the volume tree, for example:
CAIR1->SetLineColor(2); // set color of TNode::CAIR1
I could initialize each node in the detector by using recursively using
GetListOfNodes() to obtain the daughter nodes at each point. Once all
my nodes had been initialized, I could invoke Draw() for the top level
node, and get the detector picture I desired. (See the attached
picture for a simple example.)
Now, using Root 3.10, the g2root program generates entirely new
geometry files, and none of this works. My detector volumes have changed
from TNode to TGeoVolume objects, and unlike in the above example, I
can’t figure out how to call them directly from the command line, nor
how to look up any particular volume I want to configure, nor how to
recursively visit all the daughter nodes.
Before I get too buried in relearning what little I thought I knew,
I thought I’d ask for 2 things:
is there any documentation on migrating from the old g2root
geometry format to the new one?
is there a better way to produce customized detector drawings
starting from a geometry file produced by g2root?
Thanks for any help you can provide,
… Morgan Burke
First, you should know that you can still convert your G3 geometry to the old geometry classes of ROOT. You just have to use g2rootold instead of g2root. On the other hand, you might find the new geometry package more appealing since besides visualization there are many more additional features: overlap checking, raytracing, navigation and tracking functionality + the possibility to use a TGeo geometry directly with G3 (and soon FLUKA, eventually G4)
I do not want to advertise this new package, but if you are interested you can find a user guide at: ftp://root.cern.ch/root/doc/chapter17.pdf
Anyway, if you run the macro generated by the new g2root and open a TBrowser you will see the geometry manager and top volume. You can easily unfold/draw any piece of the geometry either from the context menu or from the interpreter. Changing line styles/colors is as easy as before, but you have more global visualization options. You can even set all colors in one step calling gGeoManager->DefaultColors() from the command line (arbitrary colors according material density)
I’m glad to hear this, but am not having much luck doing it in either case.
From the context menu, ROOT goes into an infinite loop almost half the time. The rest of the time I either get a blank canvas or an actual volume shape.
From the interpreter, it simply does not recognize my volume names.
Eg. I right click on a volume in the canvas to pull up a context menu that describes the volume as “TGeoVolume::TBV1”. I can successfully draw this volume by selecting the Draw option. But from the command line:
root [2] TBV1->Draw()
Error: Symbol TBV1 is not defined in current scope
These techniques all work using the old geometry file with the same Root binary (3.10).
It is not clear for me at which point you get into an infinite loop. Could you be more specific?
Indeed, volume names are not known by the interpreter - they cannot be. To grab a volume pointer from the interpreter, simply do:
TGeoVolume *vol = gGeoManager->GetVolume("TBV1");
vol->SetLineColor(kRed); // to change line color
gGeoManager->SetVisLevel(5); // to see volume daughters down to level 5
gGeoManager->SetVisOption(0); // to see all descendents, not just final leaves as default
gGeoManager->DefaultColors(); // to have some default colors for all volumes
...
vol->Draw(); // finally draw your volume
If you want to see your geometry starting from top, just do:
gGeoManager->GetMasterVolume()->Draw();
Without generating any output, Root goes unresponsive, and runs at 100% CPU until I kill it. Similar behaviour observed with other, but not all, volumes. Geometry file available on request if you want to reproduce the problem.
They used to be, when they were TNodes instead of TGeoVolumes, which was kind of handy. But to do real work, one has to work with pointers anyway, so it’s not a real complaint.
The problems are fixed. They were related to the huge number of geometrical objects in your geometry (1.3E9). You will find the fix in CVS at the end of the day.
All of this has been helpful to understanding the new geometry package, but unfortunately, it hasn’t helped much for my original problem, which was to be able to highlight specific nodes in a detector drawing, as I could in Root 3.02.
It’s fairly obvious how to highlight a volume, eg.
gGeoManager->GetVolume("TBV1")->SetLineColor(2)
but that doesn’t help me really, since I don’t want to see every instance of the volume, but a specific node at a specific location.
I understand that physical nodes are specified by path now, but the only related tool I can find is the gGeoManager->DrawPath("…") function, which draws the node in isolation, whereas I want to highlight it within the context of the surrounding detector.
Is there a way to operate on specific, unique nodes (specified by path, presumably) so that one can affect how they are displayed in the overall detector drawing (analogous to what I did with volumes in the above example)?
Unfortunatelly, you cannot highlight only specific nodes (in fact paths) in your detector in the current version. This is due to the fact that the object having visibility/line attributes cannot be a path, but just a volume/node. Changing attributes for this will of course affect all other copies.
Indeed, you could do this with the old ROOT geometry since there every node was in fact representing an unique object/path. On the other hand, this is a quite big problem when trying to represent geometries with huge number of nodes like yours - it just cannot fit memory. This is why you cannot use any more the old g2root convertor for the latest version of your geometry.
I might find something in the future to be able to do what you need, but for the time being I do not see any easy work-arround.
In practice, the number of paths that needs to be highlighted is small, so there is no requirement that they all be ready and waiting in memory for me. I can declare them as needed, but I’d need to draw them all onto the same drawing, positioned correctly with respect to each other.
DrawPath() seems to position the nodes correctly in a global frame of reference - ie. if I loop over a set of paths with DrawPath(), I can see them appear one-by-one in their relative positions. If I could draw multiple paths onto the same canvas, that would be a huge step forward for me. For instance, I could draw the important paths (which would be relatively small in number), and overlay them with a few high-level nodes (also small in number) to give some overall detector context.
So I guess what I’m looking for is something like a DrawPaths() method that accepts an array of paths. I know it doesn’t exist, but is it feasible? I am able to do the development myself, if necessary.
OK Morgan, there might be a way to provide this feature, but it has to be implemented in a more consistent way than DrawPaths(). Here is what I propose:
as I explained, the modeller cannot build/store all physical objects that have a related path, however, I can imagine user-defined list of them. They will represent ‘touchable’ objects - e.g. paths in the geomery - but they may also contain visualization attributes (inheriting from TAttLine). The idea would be that the TGeoPainter class will call their Draw(“SAME”) method after a normal drawing is performed.
The advantage of this approach is that you will be able to preserve all global visualization options (visible depth,…) and ‘overlaying’ your desired extra features on top. Moreover, such TGeoPhysicalNode objects may be used also for alignment purposes (e.g. changing a shape/relative position with respect to the initial ‘ideal’ geometry)
That sounds perfect! My next question was going to be about setting path-specific drawing attributes, but you’ve anticipated my requirements
Looks like TGeoPhysicalNode would be a whole new class, although it might inherit most of its features and store not much more than the path itself. Let me know if there is any way I can contribute to the development, if you’re overworked. Either way, I’d like to study the new code to understand how things are implemented at that level.
I will do the initial implementation and let you know. You can look into it and test it afterwords and it would be great if you can implement/suggest improvements.
I’ve just implemented physical nodes. Please update /geom and /geompainter modules from CVS and have a look/run the attached macro to see how they work. You will find there several options for drawing. As I said, they will represent in future also the support for applying alignment constants to geometry, but currently this is not implemented.
, I can reproduce it from the command line:
