[Paraview] holes in distributed polydata
Moreland, Kenneth
kmorel at sandia.gov
Mon Jan 18 13:54:10 EST 2010
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.loring at 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.loring at 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.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>
>> > > <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>
>> > <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> <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/20100118/631c91e5/attachment-0001.htm>
More information about the ParaView
mailing list