Make a TGraph2D non-transparent

[LeWhoo]

---

ROOT Version (e.g. 6.12/02): 5.34.36
Platform, compiler (e.g. CentOS 7.3, gcc6.2): Fedora 27

---

Hello,

I am drawing a TGraph2D, as on attached plot. The problem is, that the lines and markers seem to be partially transparent - you can see most of the lower parts behind the peaks through the peaks. This is not a matter seeing through the breaks between lines, because for line size of 15 the problem is the same. The same also, if I set a marker size to very big. Does not matter if I use GL back-end or not. The same effect is in stored png and pdf, as well as on the screen. So I guess, it must be a feature. How can I turn it off?

[couet]

@LeWhoo

The problem is, that the lines and markers seem to be partially transparent -

Unless you asked explicitly for it there is no transparency involved in that kind of plot. Can you provide a macro we can run ? I am not sure to fully understand what your problem is exactly.

[LeWhoo]

I attach a tree and the file I used to produce the plots. Please execute

./draw_all_scurves.py tree.root

Also, I attach a version of plot with option “tri”. That’s how it should look like (for me) - no transparency. However, tri option takes ages…

draw_all_scurves.py (1.4 KB)
tree.zip (265.9 KB)

[couet]

@LeWhoo

However, tri option takes ages…

Yes because you are using an old version of root. The delaunay triangulation algorithm has been improved . I will look at your code.

[couet]

@LeWhoo

./draw_all_scurves.py tree.root

it gives me:

$ ./draw_all_scurves.py tree.root
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6

[couet]

I modified a bit your macro to not have input parameter:

f = ROOT.TFile("tree.root", "read")
t = f.Get("tcal")

and I did:

$ python draw_all_scurves.py 

It gives me:

$ python draw_all_scurves.py 
Traceback (most recent call last):
  File "draw_all_scurves.py", line 7, in <module>
    fn = sys.argv[1]
IndexError: list index out of range

[LeWhoo]

You need to call it with parameter file name. So just, please replace

fn = sys.argv[1]

with

fn = “tree.root”

I hope you unpacked tree.zip

[couet]

I get a blank canvas. No graphics

[LeWhoo]

I just downloaded the stuff I posted here, changed the 7th line to fn = “tree.root”, ran and I get the result. I can just add some debug output to see if you get the arrays filled from the TTree, but I see no point why you wouldn’t… Unless there is a difference in plotting options between your and mine version of root…

[LeWhoo]

I’ve simplified the script and added some debug output. You should get the following printed:

Entries: 256
32512 32512 32512
[[    0.     8.    16. ...,   992.  1000.  1008.]
 [    0.     8.    16. ...,   992.  1000.  1008.]
 [    0.     8.    16. ...,   992.  1000.  1008.]
 ..., 
 [    0.     8.    16. ...,   992.  1000.  1008.]
 [    0.     8.    16. ...,   992.  1000.  1008.]
 [    0.     8.    16. ...,   992.  1000.  1008.]] [[   0.    0.    0. ...,    0.    0.    0.]
 [   1.    1.    1. ...,    1.    1.    1.]
 [   2.    2.    2. ...,    2.    2.    2.]
 ..., 
 [ 253.  253.  253. ...,  253.  253.  253.]
 [ 254.  254.  254. ...,  254.  254.  254.]
 [ 255.  255.  255. ...,  255.  255.  255.]] [[ 0.02819824  0.03271484  0.03515625 ...,  0.          0.          0.        ]
 [ 0.03540039  0.03967285  0.04107666 ...,  0.          0.          0.        ]
 [ 0.0581665   0.05407715  0.06231689 ...,  0.          0.          0.        ]
 ..., 
 [ 0.03027344  0.03741455  0.03637695 ...,  0.          0.          0.        ]
 [ 0.02423096  0.02325439  0.02539062 ...,  0.          0.          0.        ]
 [ 0.01263428  0.01220703  0.0135498  ...,  0.          0.          0.        ]]
enter "q" to quit: q

However, I can rewrite to C++, if it makes tracing the issue simpler.

draw_all_scurves.py (1.1 KB)

[couet]

Now I get graphics.

The line option makes no sense in that particular case because it connect le point “in order”. It il some a surface drawing. I would suggest:

g2d = ROOT.TGraph2D(points_x.size, points_x.ravel(), points_y.ravel(), points_z.ravel())
g2d.SetLineWidth(3)
g2d.SetMarkerSize(0.5)
g2d.SetMarkerStyle(20);

c1 = ROOT.TCanvas()
g2d.Draw("pcol ")

Which gives:

or:

g2d = ROOT.TGraph2D(points_x.size, points_x.ravel(), points_y.ravel(), points_z.ravel())
g2d.SetLineWidth(1)

c1 = ROOT.TCanvas()
g2d.Draw("surf1")
c1.Modified()
c1.Update()

which gives:

TRI1 is fast with ROOT 6. Combined with p0 we get:

g2d.Draw("Tri1 P0")

[LeWhoo]

In general, I would like to have TMultiGraph with “l3d” option, that changes the color of the line according to Z, same as “pcol” does for markers. I’ve seen it in some other package and it would really help here. But since this is not available, I try to work with markers/surfaces.

surf/tri would work, if it was not so terribly slow on root 5. I can’t switch to root 6 because of lack of windows compatibility that I have to maintain (and, at least ~1 year ago, when I checked, pyROOT GUI examples were not working, so…).

So I would go for pcol, perhaps with line as I was doing (since surface drawing is so slow), but in your screenshot it also looks wrong, I think. In the area that I marked on the attache dplot, the dark blue markers which are behind the lighter blue markers that belong to the peak, are drawn over the light blue markers. At least, the light blue markers are not visible in the marker area, while they should be.

[couet]

Markers are drawn in the order they are stored in the TGraph2D. There is no special treatment to draw them from back to front.

[LeWhoo]

I see. Which means that I can’t really look at the back or the front of the plot if I rotate it. I was expecting similar behaviour as with surf plots. Would you consider in the future uniformising this behaviour, or do majority of users expect markers to be drawn according to order of adding, not geometrical placement?

[couet]

There is no plans nor requests right now to implement this.