[visit-developers] Need another set of eyes

tom fogal tfogal at alumni.unh.edu
Thu May 28 11:42:57 EDT 2009


Thanks for looking at this!

Hank Childs <hankchilds at yahoo.com> writes:
> See the attached images. before_OpaqueComposite_00[01]_001.png show
> what each processor has before the composite.

Doh.  I don't use -dump as much as I should ...

> Note that they are not evenly dividing screen space.  That may be a
> new thing or it may be that's how it has always worked.  (I believe
> the transparency actor duplicates data along boundaries.)
>
> If you look at after_AllComposites_003.png, you'll see that those
> lines are= actually where there is data on both processors.=A0 And
> that the lines are= where the perspective transform makes data appear
> for the front face, but = not the back face (that's a poor phrasing,
> so I hope you know what I mean).

Ahh, yes, I see what you mean.  Almost seems like the cuts aren't
axis-aligned -- as if I can see minutely above and below them.

Anyway, this is promising; I'll check to see how the subdivision worked
before that commit.

Offtopic: I noticed another compositing bug that we don't seem to have
a test for (at least not in annotation.py or transparency.py).  We only
render the annotations on one of the processors, it looks like.  Yet it
seems like we want to also split the annotations, just like we do with
a plot.  Look at the image after_ image you sent -- notice how the axis
labels are composited out in the top half of the image, unless they are
`on top' of the rendered image.  That is, the lines of the bounding box
which go *in* to the data disappear completely.  Also note the "Axis
(cm)" part of "Y Axis (cm)" gets a tiny bit of the top clipped off.
Looking at the `annotation.py' results, I'd guess this is limited to
plots with transparent geometry (which makes sense).

> If I had to guess, I would say that the composite phase used to
> respect pre-made boundaries set up by the transparency actor, but
> that it is no longer doing it.  Jeremy can probably give a little
> more info, as I think he is more familiar with the implementation.

Hrm, yeah, I'm starting to think I mucked up something in the
transparency actor, but I'm not sure what yet; that change was
dead-simple.  Perhaps there is some bit of hidden state, which affects
subdivision, and hasn't been configured since I've changed the ordering
of transparency calculation w.r.t. other rendering.  Though the time of
sorting shouldn't have changed, now that I think about it...

Anyway, promising leads now.  Thanks!

-tom

> --- On Wed, 5/27/09, tom fogal <tfogal at alumni.unh.edu> wrote:
> 
> From: tom fogal <tfogal at alumni.unh.edu>
> Subject: [visit-developers] Need another set of eyes
> To: visit-developers at ornl.gov
> Date: Wednesday, May 27, 2009, 4:12 PM
> 
> I've been staring at a compositing issue for too long; I must be
> missing something obvious.=A0 Could someone else take a look?
> 
> r7402 revealed or created an interesting bug.=A0 I've
> attached the 9th images (baseline, my machine, diff) from
> tests/rendering/transparency.py, which demonstrates the problem.
> Basically I'm getting two lines which appear to average the background
> color and the actual image.
> 
> Valgrind reports we're doing Bad Things there.=A0 I've also attached
> a valgrind log; there's more than one issue, but the one that I'm
> referring to is the last entry.=A0 Essentially we new[] in that method
> (well, it's a vector now, but the trace is essentially equivalent), and
> use that new'd buffer in reduces.=A0 Somehow 7 bytes of that data are
> uninitialized.
> 
> I've been staring at that code, throwing in little hacks.=A0 I wrote
> it out to a std::ofstream in hopes of triggering the valgrind issue
> earlier (it didn't).=A0 I deleted the entire method and rewrote it with
> nothing in front of me -- and saw the same bug.
> 
> Any ideas are more than welcome.
> 
> -tom


More information about the visit-developers mailing list