[Paraview] holes in distributed polydata

[Moreland, Kenneth]

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>
>





   ****      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/20091207/cc4b5bf2/attachment.htm>