<br><font size=2 face="sans-serif">I'm experimenting with the vtkCompositeRenderManager
and am running into a problem. If I add lines (for example, the bounding
box of a data partition) to the rendering on a node, I get terrible streaks
all over the composited image. </font>
<br>
<br><font size=2 face="sans-serif">After much poking around, I've found
that (even outside of the compositing parallel rendering environment) OpenGL
line rendering is anti-aliased (even after setting RenderWindow->LineSmoothingOff()
immediately after creating the render window) and, further, when a pixel
is only partially affected by a line, it may or may not update the Z depth
buffer - based, I suppose, on whether the proportion of coverage exceeds
some threshold. But it *always* affects the color buffer, so you
can have a pixel thats not the background color but is at the background
depth. (No, I'm not hallucinating. Yes, I have a little program
that demonstrates this.)</font>
<br>
<br><font size=2 face="sans-serif">Then, in the parallel compositing code,
when it tries to run-length encode the background away, it looks for runs
of constant Z = 1. When it reaches the end of such a run, it uses
the color of the final pixel of that run as the color of the whole run.
Unfortunately, that pixel may be partially covered by an antialiased
line, enough to change the color, but not enough so that it updates the
depth. So the subsequent run of "background" receives a
color that isn't the background color, resulting in a streak of color
extending either to the next non-background pixel or the end of the buffer.</font>
<br>
<br><font size=2 face="sans-serif">Near as I can tell, the run-length encoding
code needs to match color as well as Z = 1. Or we can get the color
buffer and Z buffer updates to match, but I don't understand why they *aren't*
matching as it is now. </font>
<br>
<br><font size=2 face="sans-serif">Linux RHEL3, Quadro FX 3400/4400
driver 7676.</font>
<br>
<br><font size=2 face="sans-serif">Greg</font>