<HTML>
<HEAD>
<TITLE>Re: [Paraview] holes in distributed polydata</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Hmm. It is possible that the “floating viewport” feature of IceT could be causing troubles with precision. Could you try adding<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'>icetDisable(ICET_FLOATING_VIEWPORT);<BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
somewhere in the </SPAN></FONT><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'>vtkIceTRenderManager::UpdateIceTContext()</SPAN></FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> method and see if the problem goes away?<BR>
<BR>
-Ken<BR>
<BR>
<BR>
On 12/7/09 10:11 AM, "burlen" <<a href="burlen.loring@gmail.com">burlen.loring@gmail.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Hi Ken,<BR>
For that figure you mention I turned on "surface with edges" to show the<BR>
cell size better. Sorry I can see how that could be confusing. But just<BR>
to clarify, there aren't actually any holes in the surface.<BR>
<BR>
Here is another zoom in of the same area where "surface with edges" is<BR>
off and you can see that there are no holes.<BR>
<a href="http://nashi-submaster.ucsd.edu/movies/PV/bug-zoom.png">http://nashi-submaster.ucsd.edu/movies/PV/bug-zoom.png</a><BR>
<BR>
Now I also have hit a case where after running through D3 I got a hole<BR>
at the process boundary. this run had 80 processes, the surface shown<BR>
has dimensions of 5.5 x 10 units with 1500 x 2727quads with side 0.0036<BR>
units.<BR>
<a href="http://nashi-submaster.ucsd.edu/movies/PV/bug-d3.png">http://nashi-submaster.ucsd.edu/movies/PV/bug-d3.png</a><BR>
<BR>
I am only seeing this with the small quads and in parallel at process<BR>
boundaries.<BR>
<BR>
Burlen<BR>
<BR>
<BR>
Moreland, Kenneth wrote:<BR>
> Burlen,<BR>
><BR>
> For the zoom in, you say there are no holes/lines, but in the image I<BR>
> see a grid of lines. It looks like you have a bunch of little quads<BR>
> with spacing in between them. Is this the case? If so, then the “hole”<BR>
> artifacts you see on the bottom of the screen are probably simply<BR>
> aliasing artifacts. They are places where the pixel happens to align<BR>
> right where the gap is.<BR>
><BR>
> I can’t think of an easy way around this (other than to modify your<BR>
> data to remove the gaps, if that makes sense). Anti-aliasing<BR>
> techniques such as oversampling or smoothing would probably fix the<BR>
> problem, but they would also break the parallel rendering so they are<BR>
> no good.<BR>
><BR>
> -Ken<BR>
><BR>
><BR>
> On 12/5/09 12:18 AM, "burlen" <<a href="burlen.loring@gmail.com">burlen.loring@gmail.com</a>> wrote:<BR>
><BR>
> its ugly but I get a lot better performance by splitting the work up<BR>
> dynamically with a small grain size. in the run shown below there are<BR>
> only 16 processes but there are a whole lot of process boundaries.<BR>
><BR>
> I was able to reproduce it on a second system today.<BR>
><BR>
> these holes are pretty non-deterministic in where they show up. moving<BR>
> the camera they can show up in different places. Which makes sense if<BR>
> this is related to some parallel rendering/finite precision issue with<BR>
> all those process boundaries. The small size of the quads are also a<BR>
> factor, because I didn't ever notice it before when using larger<BR>
> quads.<BR>
><BR>
> I saved the data as a legacy file and opening it on my desktop<BR>
> there are<BR>
> no issues, so its definitely a parallel only issue. Also running<BR>
> through<BR>
> D3 seems to fix it, but the issue may still be there because with the<BR>
> minimal number of process boundaries its much less likely to get the<BR>
> camera in just the right position.<BR>
><BR>
> Berk Geveci wrote:<BR>
> > Ouch. That's very distributed :-) Does the problem go away when you<BR>
> > decrease the number of partitions?<BR>
> ><BR>
> > On Thu, Dec 3, 2009 at 10:55 AM, burlen <<a href="burlen.loring@gmail.com">burlen.loring@gmail.com</a>><BR>
> wrote:<BR>
> ><BR>
> >> I'm seeing lines where the background shows through a surface<BR>
> polydata of<BR>
> >> quads. When I zoom into the region to investigate the holes are<BR>
> gone. Moving<BR>
> >> the image around the holes appear in different places. They<BR>
> depend on camera<BR>
> >> position. In this surface there are 2.5E6 quads. the area is<BR>
> 10x16 units and<BR>
> >> the number of quads is 1250x2000. each quad has 0.008 units on a<BR>
> side. I<BR>
> >> hadn't seen the holes before going to this higher resolution.<BR>
> It's likely<BR>
> >> that the hole is near a process boundary, in my polydata filter<BR>
> each process<BR>
> >> adds his quads to his output polydata, in this run the quads are<BR>
> distributed<BR>
> >> in strips of 512 as needed.<BR>
> >><BR>
> >> 3 holes/lines in bottom half of the image (black background<BR>
> shows through):<BR>
> >> <a href="http://nashi-submaster.ucsd.edu/movies/PV/bug.png">http://nashi-submaster.ucsd.edu/movies/PV/bug.png</a><BR>
> >><BR>
> >> zoom in no holes/lines:<BR>
> >> <a href="http://nashi-submaster.ucsd.edu/movies/PV/bug-zoom-2.png">http://nashi-submaster.ucsd.edu/movies/PV/bug-zoom-2.png</a><BR>
> >><BR>
> >> process boundaries (from process id filter):<BR>
> >> <a href="http://nashi-submaster.ucsd.edu/movies/PV/bug-procs.png">http://nashi-submaster.ucsd.edu/movies/PV/bug-procs.png</a><BR>
> >><BR>
> >> Should PV be able to handle a polydata distributed like this?<BR>
> >><BR>
> >><BR>
> >><BR>
> >> _______________________________________________<BR>
> >> Powered by www.kitware.com<BR>
> >><BR>
> >> Visit other Kitware open-source projects at<BR>
> >> <a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><BR>
> >><BR>
> >> Please keep messages on-topic and check the ParaView Wiki at:<BR>
> >> <a href="http://paraview.org/Wiki/ParaView">http://paraview.org/Wiki/ParaView</a><BR>
> >><BR>
> >> Follow this link to subscribe/unsubscribe:<BR>
> >> <a href="http://www.paraview.org/mailman/listinfo/paraview">http://www.paraview.org/mailman/listinfo/paraview</a><BR>
> >><BR>
> >><BR>
><BR>
> _______________________________________________<BR>
> Powered by www.kitware.com<BR>
><BR>
> Visit other Kitware open-source projects at<BR>
> <a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><BR>
><BR>
> Please keep messages on-topic and check the ParaView Wiki at:<BR>
> <a href="http://paraview.org/Wiki/ParaView">http://paraview.org/Wiki/ParaView</a><BR>
><BR>
> Follow this link to subscribe/unsubscribe:<BR>
> <a href="http://www.paraview.org/mailman/listinfo/paraview">http://www.paraview.org/mailman/listinfo/paraview</a><BR>
><BR>
><BR>
><BR>
><BR>
> **** Kenneth Moreland<BR>
> *** Sandia National Laboratories<BR>
> ***********<BR>
> *** *** *** email: <a href="kmorel@sandia.gov">kmorel@sandia.gov</a><BR>
> ** *** ** phone: (505) 844-8919<BR>
> *** web: <a href="http://www.cs.unm.edu/~kmorel">http://www.cs.unm.edu/~kmorel</a> <<a href="http://www.cs.unm.edu/%7Ekmorel">http://www.cs.unm.edu/%7Ekmorel</a>><BR>
><BR>
<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'><BR>
**** Kenneth Moreland<BR>
*** Sandia National Laboratories<BR>
*********** <BR>
*** *** *** email: <a href="kmorel@sandia.gov">kmorel@sandia.gov</a><BR>
** *** ** phone: (505) 844-8919<BR>
*** web: <a href="http://www.cs.unm.edu/~kmorel">http://www.cs.unm.edu/~kmorel</a><BR>
</SPAN></FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT>
</BODY>
</HTML>