lines drawn behind data

[doutriaux1]

@dlonie @aashish24

can you please take a look at my branch:
https://github.com/doutriaux1/uvcdat/tree/issue_587_projected_ticks

it works fine in most case but for polar projections somehow the data gets drawn on top of the tick marks not matter what. Any idea on how to force VTK to respect priority/layer ordering?

@chaosphere2112 you're welcome to take a look as well 😉

Here's the code:

import os,sys,cdms2,vcs
f=cdms2.open(os.path.join(sys.prefix,"sample_data","clt.nc"))
s=f("clt",slice(0,1))
x=vcs.init()
gm = x.createisofill()
gm.projection = 'polar'
t= x.createtemplate()
t.xtic1.y1 = t.data.y1
t.xtic2.y2 = t.data.y2
t.ytic1.x1 = t.data.x1
t.ytic2.x2 = t.data.x2
x.plot(s,t,gm)
raw_input("Press enter")

[doutriaux1]

@aashish24 @dlonie any progress on this?

[alliepiper]

On another project at the moment, I'll take a look when I switch back to UV-CDAT.

[doutriaux1]

ok, Iremember you did some magic a while back for the continents that had the same issue, do you remember about which function it was calling? thanks

[alliepiper]

Not offhand, but these commits look like they may be related:

aa05421
90a2ff3

IIRC, the issue you're referring to was caused by having multiple renders at Layer = 0, which causes them to be rendered with opaque backgrounds and cover each other up.

[alliepiper]

I took a look at the branch and made a few comments. Try printing out the layers in setLayer to see if there are multiple renderers with layer 0 -- that's the most likely culprit.

[alliepiper]

If the lines are in the same layer/renderer as the data, try the approach in aa05421 -- it may be a z-fighting issue.

[alliepiper]

BTW, is this supposed to be assigned to me? It sounds like @doutriaux1 is working on it.

[doutriaux1]

Assign to you for the lines thing. Will look at it if you don't beat me to it. I'm off today though.

[doutriaux1]

Did try the layer set them to very high number. Also it works for other projections like robinson. I think the z fighting thing is indeed the issue.

[alliepiper]

The issue is that the renderer with the isofill data is being moved up to a higher layer, obscuring the tick marks. It's not the absolute highest layer, which is why the continents etc still appear above it.

Apply this patch to print the plot type and the renderer addresses + layers:

diff --git a/Packages/vcs/Lib/VTKPlots.py b/Packages/vcs/Lib/VTKPlots.py
index 7ccdecd..c580e60 100644
--- a/Packages/vcs/Lib/VTKPlots.py
+++ b/Packages/vcs/Lib/VTKPlots.py
@@ -404,6 +404,12 @@ class VTKVCSBackend(object):
       gm = vcs.elements[gtype][gname]
     tpl = vcs.elements["template"][template]

+    try:
+        priority = gm.priority
+    except:
+        priority = -1
+    print "plot:",gtype,"priority=%d"%priority,"call=%d"%self.numberOfPlotCalls
+
     if kargs.get("renderer",None) is None:
         if ( gtype in ["3d_scalar", "3d_dual_scalar", "3d_vector"] ) and (self.renderer <> None):
             ren = self.renderer
@@ -591,6 +597,7 @@ class VTKVCSBackend(object):
     nMax = max(self.renWin.GetNumberOfLayers(),n+1)
     self.renWin.SetNumberOfLayers(nMax)
     renderer.SetLayer(n)
+    print "setting layer to",n,"for renderer at",hex(id(renderer))
     pass

   def plot3D(self,data1,data2,tmpl,gm,ren,**kargs):

We see the renderer with the isofill data (0x7f5ee2ebd590) repeatedly changing layers (note that this id is a runtime memory address, and will change for each execution of the script):

plot: isofill priority=-1 call=0
Yes doing the long one
setting layer to 1 for renderer at 0x7f5ee2ebd590
setting layer to 1 for renderer at 0x7f5ee2ebd590
plot: text priority=1 call=1
...
setting layer to 2 for renderer at 0x7f5ee2ebd950
plot: text priority=1 call=2
...
setting layer to 3 for renderer at 0x7f5ee2ebd950
plot: text priority=1 call=3
...
setting layer to 4 for renderer at 0x7f5ee2ebd950
plot: text priority=1 call=4
...
setting layer to 5 for renderer at 0x7f5ee2ebd950
plot: text priority=1 call=5
...
setting layer to 6 for renderer at 0x7f5ee2ebd950
plot: text priority=1 call=6
...
setting layer to 7 for renderer at 0x7f5ee2ebd950
plot: text priority=1 call=7
...
setting layer to 8 for renderer at 0x7f5ee2ebd950
plot: text priority=1 call=8
...
setting layer to 9 for renderer at 0x7f5ee2ebd950
drawTicks
plot: text priority=1 call=9
...
setting layer to 10 for renderer at 0x7f5ee2ebd950
plot: line priority=51 call=10
Yes doing the long one
...
setting layer to 11 for renderer at 0x7f5ee2ebd950
drawTicks
plot: text priority=0 call=11
setting layer to 12 for renderer at 0x7f5ee2ebd950
plot: line priority=51 call=12
...
setting layer to 13 for renderer at 0x7f5ee2ebd950
drawTicks
plot: text priority=1 call=13
...
setting layer to 14 for renderer at 0x7f5ee2ebd950
plot: line priority=51 call=14
...
setting layer to 15 for renderer at 0x7f5ee2ebd950
drawTicks
plot: text priority=0 call=15
setting layer to 16 for renderer at 0x7f5ee2ebd950
plot: line priority=51 call=16
...
setting layer to 17 for renderer at 0x7f5ee2ebd950
plot: line priority=1 call=17
...
setting layer to 18 for renderer at 0x7f5ee2ebd950
...
drawColorBar
plot: fillarea priority=1 call=18
...
setting layer to 19 for renderer at 0x7f5ee2ebd950
plot: line priority=2 call=19
...
setting layer to 20 for renderer at 0x7f5ee2ebd950
plot: text priority=2 call=20
...
setting layer to 21 for renderer at 0x7f5ee2ebd950
setting layer to 21 for renderer at 0x7f5ee2ebd590
setting layer to 21 for renderer at 0x7f5ee2ebd950
Press enter

I've tracked it down to this being the renderer returned from fitToViewport. I'll let you take it from there, as you have a better understanding of how the data should be partitioned between the renderers in this design.