Re: [Paracomp-devel] Standard Alpha Blending problems

[Shree K. <shr...@hp...>]

Hi James,

James S Perrin wrote:
> Hi,
>         We've run into some problems using alpha blending for HW volume
> rendering. We've been carefully through our code an everything seems
> correct. Each render is using the recommended glBlend function:
> 
> glBlendFuncSeparateEXT(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA,
>                  GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
> 
> This is necessary to preserve the correct alpha value, correct?

Yes.

> 
> However when we looked at the PClib compositing code it was performing
> the same operation on both RGB *and* Alpha, I presume the equivalent of:
> 
> glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
> 

That's right. Paracomp's alpha blending was written to mimic base OpenGL 
directly.

With this blending function, the composited color values come out right. 
But the composited alpha value is incorrect. So you can't use the final 
alpha. This is a drawback of Paracomp compositing. I sometimes veer to 
the opinion that this is a bug that needs to be fixed.

> When we changed the operator to "preserve alpha" by explicitly
> performing the equivalent of:
> 
>         glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA)
> 
> on the alpha value we got the correct result!?

You mean you changed the paracomp operator itself ? I have no 
explanation at the moment about why this worked.

Can you describe the method by which you are rendering the volume on 
every host ?

> 
>         Since other people have done alpha blending we had assumed it was our
> code that is wrong or at least we were passing incorrect data. Can
> someone explain where the mistake is? Are we just correcting for our
> error by changing the compositor operation?
> 

The key to getting the right results is to generate the right alpha 
value on each host. But I can't say more till you tell us how you are 
rendering sub-volumes on each host.

If you are drawing slicing planes in a back-to-front order, then using 
the above equation should work.

> Attached are some images showing the problem, render0 and render1 are
> the inputs and composite the output. The problem can specifically seen
> in the blue halo which doesn't show the expected smooth progression
> across the volume.
> 

The images are missing the alpha channel, since .JPG cannot take them. 
To help debugging this, we'll need the alpha values.

Can you create .PNG files with an alpha channel and send them across ?

I've attached some source code (pngfile.cpp) which will help you write 
png files. Note that you'll have to readback RGBA values and feed that 
array to the WritePNG function.

As an aside --you can actually use an image editor like GIMP to see the 
final result of the compositing, as follows --
   - Dump .PNG files with alpha channels from all the hosts
   - import each of them as a layer in GIMP, and
   - arrange the layers with the nearest one on top

If your program works you won't need this, but it's an easy debugging tool.

HTH
-- Shree