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