Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lines drawn behind data #1143

Closed
doutriaux1 opened this issue Mar 12, 2015 · 18 comments
Closed

lines drawn behind data #1143

doutriaux1 opened this issue Mar 12, 2015 · 18 comments
Assignees
Milestone

Comments

@doutriaux1
Copy link
Contributor

@doutriaux1 doutriaux1 commented Mar 12, 2015

@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
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 12, 2015

@aashish24 @dlonie any progress on this?

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Mar 12, 2015

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

@doutriaux1
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 12, 2015

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

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Mar 12, 2015

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.

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Mar 12, 2015

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.

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Mar 12, 2015

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

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Mar 12, 2015

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

@doutriaux1
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 12, 2015

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
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 12, 2015

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.

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Mar 12, 2015

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.

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Mar 12, 2015

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.

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Mar 12, 2015

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
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 16, 2015

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
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 16, 2015

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

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Mar 17, 2015

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
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 17, 2015

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!

@allisonvacanti
Copy link
Contributor

@allisonvacanti allisonvacanti commented Mar 17, 2015

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
Copy link
Contributor Author

@doutriaux1 doutriaux1 commented Mar 17, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants