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