I can't find anything wrong other then there must be some sort of precision issue that is interfering with the decision of when to draw a polygon that is smaller than a pixel. I just checked in a change to IceT that prevents shifting around the projection matrix in single-display mode. That should fix the problem.
-Ken On 1/15/10 11:07 AM, "burlen" <burlen.lor...@gmail.com> wrote: Using the dataset below I can reproduce the issue on my workstation using 4 processes and both hardware and mesa rendering. burlen wrote: > Ken, > > Here is a dataset that I am able to reproduce with: > http://nashi-submaster.ucsd.edu/movies/PV/holes.tar.gz > > run with 96 procs. Set the view to +y. If the long holes aren't > appearing in your view I found that smaller holes can show up by > rotating the plane in small increments about either the x or z axis. > These ones are pretty small so you have to look closely. > > Burlen > > Moreland, Kenneth wrote: >> Burlen, >> >> Is there any possible way you can send me some data or replicate the >> problem with something like the Mandelbrot source? So far I have not >> been able to replicate it exactly. >> >> -Ken >> >> >> On 1/5/10 2:34 PM, "burlen" <burlen.lor...@gmail.com> wrote: >> >> Ken, >> Some bad news, this patch didn't solve the problem, the holes >> returned >> on my first run. >> Burlen >> >> >> Moreland, Kenneth wrote: >> > That was not intended to be a solution, but rather a >> diagnostic. My >> > guess is that there are precision errors in the rasterization >> when the >> > viewport is shifted. Could you restore vtkIceTRenderManager and >> try >> > the attached patch to IceT? >> > >> > -Ken >> > >> > >> > On 12/10/09 12:26 PM, "burlen" <burlen.lor...@gmail.com> wrote: >> > >> > Hi Ken, >> > >> > it seems to have solved the problems. I say that with fingers >> > crossed, I >> > haven't seen holes any since your suggested changes, where before >> > I was >> > seeing them quite often, popping up from time to time. >> > >> > Burlen >> > >> > Moreland, Kenneth wrote: >> > > Hmm. It is possible that the "floating viewport" feature of IceT >> > could >> > > be causing troubles with precision. Could you try adding >> > > >> > > icetDisable(ICET_FLOATING_VIEWPORT); >> > > >> > > >> > > somewhere in the vtkIceTRenderManager::UpdateIceTContext() >> method and >> > > see if the problem goes away? >> > > >> > > -Ken >> > > >> > > >> > > On 12/7/09 10:11 AM, "burlen" <burlen.lor...@gmail.com> wrote: >> > > >> > > Hi Ken, >> > > For that figure you mention I turned on "surface with edges" to >> > > show the >> > > cell size better. Sorry I can see how that could be >> confusing. But >> > > just >> > > to clarify, there aren't actually any holes in the surface. >> > > >> > > Here is another zoom in of the same area where "surface with >> > edges" is >> > > off and you can see that there are no holes. >> > > http://nashi-submaster.ucsd.edu/movies/PV/bug-zoom.png >> > > >> > > Now I also have hit a case where after running through D3 I >> got a >> > hole >> > > at the process boundary. this run had 80 processes, the surface >> shown >> > > has dimensions of 5.5 x 10 units with 1500 x 2727quads with side >> > > 0.0036 >> > > units. >> > > http://nashi-submaster.ucsd.edu/movies/PV/bug-d3.png >> > > >> > > I am only seeing this with the small quads and in parallel at >> process >> > > boundaries. >> > > >> > > Burlen >> > > >> > > >> > > Moreland, Kenneth wrote: >> > > > Burlen, >> > > > >> > > > For the zoom in, you say there are no holes/lines, but in the >> > image I >> > > > see a grid of lines. It looks like you have a bunch of little >> quads >> > > > with spacing in between them. Is this the case? If so, then >> the >> > > "hole" >> > > > artifacts you see on the bottom of the screen are probably >> simply >> > > > aliasing artifacts. They are places where the pixel happens to >> > align >> > > > right where the gap is. >> > > > >> > > > I can't think of an easy way around this (other than to >> modify your >> > > > data to remove the gaps, if that makes sense). Anti-aliasing >> > > > techniques such as oversampling or smoothing would probably >> fix the >> > > > problem, but they would also break the parallel rendering so >> > they are >> > > > no good. >> > > > >> > > > -Ken >> > > > >> > > > >> > > > On 12/5/09 12:18 AM, "burlen" <burlen.lor...@gmail.com> wrote: >> > > > >> > > > its ugly but I get a lot better performance by splitting the >> > work up >> > > > dynamically with a small grain size. in the run shown below >> > there are >> > > > only 16 processes but there are a whole lot of process >> boundaries. >> > > > >> > > > I was able to reproduce it on a second system today. >> > > > >> > > > these holes are pretty non-deterministic in where they show >> up. >> > > moving >> > > > the camera they can show up in different places. Which makes >> > sense if >> > > > this is related to some parallel rendering/finite precision >> issue >> > > with >> > > > all those process boundaries. The small size of the quads are >> > also a >> > > > factor, because I didn't ever notice it before when using >> larger >> > > > quads. >> > > > >> > > > I saved the data as a legacy file and opening it on my desktop >> > > > there are >> > > > no issues, so its definitely a parallel only issue. Also >> running >> > > > through >> > > > D3 seems to fix it, but the issue may still be there because >> > with the >> > > > minimal number of process boundaries its much less likely to >> > get the >> > > > camera in just the right position. >> > > > >> > > > Berk Geveci wrote: >> > > > > Ouch. That's very distributed :-) Does the problem go away >> > when you >> > > > > decrease the number of partitions? >> > > > > >> > > > > On Thu, Dec 3, 2009 at 10:55 AM, burlen >> <burlen.lor...@gmail.com> >> > > > wrote: >> > > > > >> > > > >> I'm seeing lines where the background shows through a >> surface >> > > > polydata of >> > > > >> quads. When I zoom into the region to investigate the >> holes are >> > > > gone. Moving >> > > > >> the image around the holes appear in different places. They >> > > > depend on camera >> > > > >> position. In this surface there are 2.5E6 quads. the >> area is >> > > > 10x16 units and >> > > > >> the number of quads is 1250x2000. each quad has 0.008 >> units on a >> > > > side. I >> > > > >> hadn't seen the holes before going to this higher >> resolution. >> > > > It's likely >> > > > >> that the hole is near a process boundary, in my polydata >> filter >> > > > each process >> > > > >> adds his quads to his output polydata, in this run the >> quads are >> > > > distributed >> > > > >> in strips of 512 as needed. >> > > > >> >> > > > >> 3 holes/lines in bottom half of the image (black background >> > > > shows through): >> > > > >> http://nashi-submaster.ucsd.edu/movies/PV/bug.png >> > > > >> >> > > > >> zoom in no holes/lines: >> > > > >> http://nashi-submaster.ucsd.edu/movies/PV/bug-zoom-2.png >> > > > >> >> > > > >> process boundaries (from process id filter): >> > > > >> http://nashi-submaster.ucsd.edu/movies/PV/bug-procs.png >> > > > >> >> > > > >> Should PV be able to handle a polydata distributed like >> this? >> > > > >> >> > > > >> >> > > > >> >> > > > >> _______________________________________________ >> > > > >> Powered by www.kitware.com >> > > > >> >> > > > >> Visit other Kitware open-source projects at >> > > > >> http://www.kitware.com/opensource/opensource.html >> > > > >> >> > > > >> Please keep messages on-topic and check the ParaView >> Wiki at: >> > > > >> http://paraview.org/Wiki/ParaView >> > > > >> >> > > > >> Follow this link to subscribe/unsubscribe: >> > > > >> http://www.paraview.org/mailman/listinfo/paraview >> > > > >> >> > > > >> >> > > > >> > > > _______________________________________________ >> > > > Powered by www.kitware.com >> > > > >> > > > Visit other Kitware open-source projects at >> > > > http://www.kitware.com/opensource/opensource.html >> > > > >> > > > Please keep messages on-topic and check the ParaView Wiki at: >> > > > http://paraview.org/Wiki/ParaView >> > > > >> > > > Follow this link to subscribe/unsubscribe: >> > > > http://www.paraview.org/mailman/listinfo/paraview >> > > > >> > > > >> > > > >> > > > >> > > > **** Kenneth Moreland >> > > > *** Sandia National Laboratories >> > > > *********** >> > > > *** *** *** email: kmo...@sandia.gov >> > > > ** *** ** phone: (505) 844-8919 >> > > > *** web: http://www.cs.unm.edu/~kmorel >> <http://www.cs.unm.edu/%7Ekmorel> >> > <http://www.cs.unm.edu/%7Ekmorel> >> > > <http://www.cs.unm.edu/%7Ekmorel> >> <http://www.cs.unm.edu/%7Ekmorel> >> > > > >> > > >> > > >> > > >> > > >> > > >> > > **** Kenneth Moreland >> > > *** Sandia National Laboratories >> > > *********** >> > > *** *** *** email: kmo...@sandia.gov >> > > ** *** ** phone: (505) 844-8919 >> > > *** web: http://www.cs.unm.edu/~kmorel >> <http://www.cs.unm.edu/%7Ekmorel> >> > <http://www.cs.unm.edu/%7Ekmorel> >> <http://www.cs.unm.edu/%7Ekmorel> >> > > >> > >> > >> > >> > >> > >> > **** Kenneth Moreland >> > *** Sandia National Laboratories >> > *********** >> > *** *** *** email: kmo...@sandia.gov >> > ** *** ** phone: (505) 844-8919 >> > *** web: http://www.cs.unm.edu/~kmorel >> <http://www.cs.unm.edu/%7Ekmorel> <http://www.cs.unm.edu/%7Ekmorel> >> > >> >> >> >> >> **** Kenneth Moreland >> *** Sandia National Laboratories >> *********** >> *** *** *** email: kmo...@sandia.gov >> ** *** ** phone: (505) 844-8919 >> *** web: http://www.cs.unm.edu/~kmorel <http://www.cs.unm.edu/%7Ekmorel> >> > **** Kenneth Moreland *** Sandia National Laboratories *********** *** *** *** email: kmo...@sandia.gov ** *** ** phone: (505) 844-8919 *** web: http://www.cs.unm.edu/~kmorel
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview