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.

[alliepiper]

Looking again at the full output with that debugging output:

https://gist.github.com/dlonie/8c0a3404d9e70d8a59ac

it looks like several renderers get moved to higher layers in subsequent plot calls. Is this expected? Seems like it'd cause problems.

[alliepiper]

I think it's renderer 0x7f5ee2e15a10 that contains the lines, and it ends up at layer 18, while the isofill data is at 21.

[doutriaux1]

got it! Thanks @dlonie for pinting us in the right direction. We needed to create different renderers in case priorities were different overwise the last object added to the renderer was used for all actors in renderer. Will update the branch and create new baseline soon.

[doutriaux1]

ok @dlonie I think the issue I was runnnig into was due the number of layers getting too big I had the setLAyer setting the VTK layer to:
n = self.numberOfPlotCalls + (priority-1)*10000 + 1
then in debug statements prio was bumped to 51! removing the debug statement seems to fix the issue

[alliepiper]

I ran the script a few times with tracing enabled (python -m trace -t (scriptname)), and saved a log of a good run and a bad run. I also deleted all layers > 1 and skipped the continents, so we're just dealing with the single renderer at layer 1 with a single actor rendering the isofill data -- thus nothing is getting obscured, etc.

The only difference a good and bad run was:

--- good.log    2015-03-17 14:19:12.000000000 -0400
+++ bad.log     2015-03-17 14:17:19.000000000 -0400
@@ -2659289,11 +2659289,9 @@
 VTKPlots.py(1720):          if xm!=-numpy.inf:
 VTKPlots.py(1721):            Xrg2[0]=min(Xrg2[0],xm)
 VTKPlots.py(1722):          if xM!=numpy.inf:
-VTKPlots.py(1723):            Xrg2[1]=max(Xrg2[1],xM)
 VTKPlots.py(1724):          if ym!=-numpy.inf:
 VTKPlots.py(1725):            Yrg2[0]=min(Yrg2[0],ym)
 VTKPlots.py(1726):          if yM!=numpy.inf:
-VTKPlots.py(1727):            Yrg2[1]=max(Yrg2[1],yM)
 VTKPlots.py(1728):          Xrg=Xrg2
 VTKPlots.py(1729):          Yrg=Yrg2
 VTKPlots.py(1730):         wRatio = float(sc[0])/float(sc[1])

Sure enough, adding the debugging output below shows that the points are coming out infinite some times, but not others:

diff --git a/Packages/vcs/Lib/VTKPlots.py b/Packages/vcs/Lib/VTKPlots.py
index 4ece1dd..50e042f 100644
--- a/Packages/vcs/Lib/VTKPlots.py
+++ b/Packages/vcs/Lib/VTKPlots.py
@@ -1661,6 +1715,7 @@ class VTKVCSBackend(object):
              pts = vtk.vtkPoints()
          geo.TransformPoints(pt,pts)
          b = pts.GetBounds()
+         print "bounds:",b
          xm,xM,ym,yM=b[:4]
          if xm!=-numpy.inf:
            Xrg2[0]=min(Xrg2[0],xm)

E.g.

good:
bounds: (-19923232.0, 19922468.0, -19923002.0, 19923352.0, 0.0, 7.274594544521728e-34)

bad:
bounds: (-19923232.0, inf, -19923002.0, inf, 0.0, 1358334976.0)

Not sure what's going on there, but it looks like an enormous quad is being mapped through the projection code? Maybe you'll have some ideas what's happening here?

[doutriaux1]

yes you draw the lines accross the globe you need to follow the line with small deltas in order to get the min/max values that the projected data will actually occupy. Values go from degrees to meters hence the big numbers. What is worrisome is that it seems the numbers comming back from the projection change all the time. In the previous code (master) I used to call TransformPoints/GetBOunds for each points, to avoid this I guess, I thought doing this way would make things faster, is there a way to getbounds skipping the inf?
I'm going to rever tfor now (it will be slower I guess butnot much) but we should figure out why sometimes we have inf and sometimes not when calling TransformPoints with the same points!

[alliepiper]

Agreed, the randomness is troubling. My bet is it's a numerical stability issue -- I'm not sure whether the code is intended to be used with inputs that have 20 orders of magnitude.

[doutriaux1]

I got it I had a left over

pt.SetNumberOfPoints(1)

in the end the total number of points came out as: Npts*Npts+1 so the first point was probably whatever is in the memory when VTK created the first point.