Drawing geometry of a detector using opengl (aliceO2)

I experience issues while drawing geometry volumes with opengl: t->Draw(“ogl”). I work in ALICE for the MFT project, building all volumes for this detector (aliceO2).
Sometimes, there are some kind of skins covering some empty volumes, or even some empty volumes appear in some places where there is material. These issues are still there with ray tracing. All is fine without opengl, t->Draw(), i.e. no problem with the building of the volumes but it’s very difficult to work with this drawing.
Other people concern by these issues?
Best regards, F.M.

ROOT Version: 6.14.04
Platform: ubuntu 14.04
Compiler: in the context of aliceO2

Maybe @matevz can give some hints…


You are probably seeing mother volume surfaces for volumes that do not have vacuum as the material. There is a visualization option for tgeo that only draws leaf nodes.

Can you try something along the lines in tutorials/eve/geom_alice_its.C? You don;'t need to get the root file, just use a TGeoNode you already have and pass it to TEveGeoTopNode constructor.

Then you can play wiht depth / visualization option in the gui of this object.



 Thanks to your informations, I used the commands from geom_alice_its.C macro to visualize my geometry. In the attached jpeg files, you can that there is still the same problem, whatever the options (VisLevel, VisOption). Without using opengl for the drawing, we can see (image1 of the jpeg) the subtraction operations that I perform to the central volume to obtain the final central volume (these operations are same for smallest parts). Why this very strange "skin" on the right side of my volume? On the other side of this volume, it's even worse, some grooves seem to fully disappear under some "skins" (image2 of the jpeg).

Best regards, F.M.

The 2 jpeg files:
image1 https://ent.uca.fr/filez/w9jtt1k9hf

image2 https://ent.uca.fr/filez/w7l5hjmi


Ah, I didn’t realize you’re doing boolean shapes. Can you tweak the sizes of the shapes a bit? It could be a problem of limited accuracy and the algorithm has trouble making the inside / outside decision. In particular, make sure the grooves stick out of the box.


the axis of the cylinders used to dig these grooves are very close to the surface of the main plate. This means I remove a large half cylinder inside the material. It’s may be a general issue related to opengl and boolean shapes: another people doing the same kind of boolean operations on another volumes see these strange issues. By example, depending of the view angle in the drawing, some surfaces are seen or disappear… It’s same for me.


Do you use full cylinders for cutting or you limit them to half cylinders (phi [pi -> 2 pi])?


Here are how I proceed for the cutting. It’s not only full cylinders but also torus:

for (Int_t igroove = 0; igroove < 4; igroove++) {
grooveTube[0][igroove] = new TGeoTube(“linear”, 0., diameter, mLWater4[igroove] / 2.);
grooveTorus[1][igroove] = new TGeoTorus(“SideTorus”, mRadius4[igroove], 0., diameter, 0., mAngle4[igroove]);
grooveTube[2][igroove] = new TGeoTube(“tiltedLinear”, 0., diameter, mLpartial4[igroove] / 2.);
grooveTorus[3][igroove] = new TGeoTorus(“centralTorus”, mRadiusCentralTore[igroove], 0., diameter, -mAngle4[igroove], 2. * mAngle4[igroove]);
grooveTube[4][igroove] = new TGeoTube(“tiltedLinear”, 0., diameter, mLpartial4[igroove] / 2.);
grooveTorus[5][igroove] = new TGeoTorus(“SideTorus”, mRadius4[igroove], 0., diameter, 0., mAngle4[igroove]);
grooveTube[6][igroove] = new TGeoTube(“linear”, 0., diameter, mLWater4[igroove] / 2.);

After that, I remove these volumes using TGeoSubtraction.

Best regards, F.M.

In order to increase the “entropy”, I put another view of one MFT half disk, with manifolds (in pink) created by another guy.

One can see a kind of hole in it: this hole doesn’t exist in reality, we have carefully checked. On top on the manifold, one can see funny shape: the sides of this shape are not drawn in fact. But if we look the other side of this half disk, the shape fully appears fine…
Not easy to control what we are coding since the drawing is not working well.
Cheers, F.M.

OK, let’s stay with the tubes :slight_smile:

Can you try moving the tubes/torii an epsilon up or down so the vertices don’t align completely with the top surface of the object you are cutting things out of?

I suspect this is a bug in the CSG library used by ROOT GL … if the above helps, this will confirm my suspicion. But the bad news is it’s going to be hell to fix it there … it’s been imported from blender a long time ago and I don’t think anybody would enjoy poking at it, even with a ten foot pole.


In fact that was the first test that I performed when I saw this drawing issue, several months ago. Anyhow, here are the results if I play with the distance between the cylinder axis and the surface plane (epsilon distance).
There are 3 files:
Epsilon = 0 ==> cylinder axis merged at the surface of the cutted object
Epsilon = 0.1 cm ==> cylinder axis outside the cutted object
Epsilon = -0.2 cm ==> cylinder axis inside the cutted object

As you can see, there is a dependence of the drawing respect to the depth of the groove. In my case, the groove geometry should be defined by a half cylinder but in this case the results are the worst… Then I shifted grooves to minimize these drawing issues but it was impossible to avoid it.

Hi Frank,

Just for curiosity - can you upload your geometry that I could test it with JSROOT.



 Here is a root file of the 5 disks (heat exchangers) of the MFT geometry:


Best regards, Franck.

It is really tough geometry. rohacellPlate_D0_H1_1 elements have very deep level (~40) of combination of logical volumes. This makes combinatoric extremely complex. You should try to make it more simple - at least for visualization purposes.

Well, I would worry far more about simulation … Geant is going to hate you. A beautiful piece, though … I’ve been enjoying it for quite some time now :wink:

Do you use an inversion to make the final straight tube segments at x < 0? I don’t think the CSG library can deal with left-handed matrices (I see the issues all appear on one side) as it screws up the surface normals and through that in/out calculations. And I’m pretty sure TGeo doesn’t deal with this in the CSG painting path.



 I don't understand why you speak about 40 deep level for the rohacell plate. I perform ~40 operations of subtraction to obtain the final results. May be it's too much for opengl (through CSG) but I need to build my detector.

Now, I have also verify that there is no overlap volumes in this geometry, even if opengl is drawing some funny skins cutting my water pipes.
Finally, I used instead Raytracing and you can see the results here:
All is fine in my geometry. The only problem is that the drawing is very long now.
The checks of the geometry are definitively tricky with the drawing.
Thanks for the help.

40 substractions is much and therefore drawing is extremely slow. In worse case after each substraction number of triangles for drawing grows quadratic. Algorithm can try to optimize this, but at the end you still get too complex figure. In addition, problem mentioned by @matevz - inversion matrix may not work correctly here.

The two half heat exchanger are created as real volumes, doing exactly the same operations, the second one is just rotated to create a disk geometry.

I have modified the algorithm of subtraction using only TGeoCompositeShape (and not TGeoSubtraction):

auto* cs0 = new TGeoCompositeShape(“cs0”, Form("(rohacellBase0_D0_H%d:t01)-(linear1_G0:tTransfo_ip0_G0)-(SideTorus1_G0:tTransfo_ip1_G0)-(tiltedLinear1_G0:tTransfo_ip2_G0)-(centralTorus_G0:tTransfo_ip3_G0)-(tiltedLinear2_G0:tTransfo_ip4_G0)-(SideTorus2_G0:tTransfo_ip5_G0)-(linear2_G0:tTransfo_ip6_G0)",half,half));
This is to create one groove, made of 7 elements. The result in term of display is the same, skins and missing painted areas appear…
Is it possible to use a container to link the 7 elements in one in order to perform one boolean operation only with a single volume?
I’m not sure that TGeoVolumeAssembly could work since it’s for “real” volumes with materials.

TGeoAssembly is basically just a list of volumes that can have overlapping bounding boxes. You could use that but it will not change anything as when you do CSG operations all the hierarchy is traversed and individual shapes are sent out.

During navigation, the same happens, all daugther shapes used in a CSG operation need to be considered when answering inside/outside and distance to/from queries.

@agheata, do you have any additional input here? :slight_smile: