In a quick check it looks to have made a difference. I will report back if I see anything as I have a chance to use it more on the cluster. Thanks Ken!

Burlen


Moreland, Kenneth wrote:
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" <[email protected]> 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" <[email protected]> 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" <[email protected]> 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" <[email protected]> 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" <[email protected]> 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
    >> <[email protected]>
    >> > > > 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: [email protected]
    >> > > > ** *** ** 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>
    >> <http://www.cs.unm.edu/%7Ekmorel>
    >> > > >
    >> > >
    >> > >
    >> > >
    >> > >
    >> > >
    >> > > **** Kenneth Moreland
    >> > > *** Sandia National Laboratories
    >> > > ***********
    >> > > *** *** *** email: [email protected]
    >> > > ** *** ** 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: [email protected]
    >> > ** *** ** 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: [email protected]
    >> ** *** ** 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: [email protected]
** *** ** phone: (505) 844-8919
*** web: http://www.cs.unm.edu/~kmorel <http://www.cs.unm.edu/%7Ekmorel>


_______________________________________________
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

Reply via email to