[Paraview] holes in distributed polydata

Moreland, Kenneth kmorel at sandia.gov
Fri Dec 11 17:14:18 EST 2009 

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.loring at 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.loring at 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.loring at 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.loring at 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: kmorel at 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: kmorel at 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: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20091211/bbc57e03/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IceTHoles.patch
Type: application/octet-stream
Size: 756 bytes
Desc: IceTHoles.patch
URL: <http://www.paraview.org/pipermail/paraview/attachments/20091211/bbc57e03/attachment.obj>

More information about the ParaView mailing list