ThomasAG

I need an alpha blend, which blends the alpha as well. I need this on systems which might not have seperate alpha blend, so I was considering doing it in a pixel shader. It would be easy to put the blend into ordinary code, but... I can not, as far as I know, do any blending in the shader. When rendering primitive n I want to blend with primitive n-1 which has been rendered, but in the shader I have no access to the pixels generated by earlier primitives.

Is the solution to render a primitive (back to front) to a full screen texture and then use that as a reference when rendering the next primitive Should I expect a large overhead from all that texture switching Actually there will be very few primitives. Probably never more than a houndred. My real bottleneck is to read the final result back into system memory and feed it to another video output, but the textures used in the blending would always reside on the graphics card I assume, so there will be no extra writing and readback over the bus.

Is this the way to do it and are my assumptions correct

As an extra question... IF I have seperate alpha blend, what would be a good blend to get an alpha which is the combination of the primitives in such a way that is a0=0.5 and a1=0.5 then the combination will be 0.75. This is to represent two half transparent objects on top of each other blocking out light from behind the scene (deeper info the screen).



Re: Game Technologies: Graphics Custom blending

ThomasAG

Seeing that there is no answer to my original question, let me rephrase it.

An ordinary blending could be destination*(1-alpha)+source*alpha

That method uses the pixel values which has already been written into the framebuffer. Can this be done with ones own pixelshader

When I must decide on a pixels rgba color, I would like to be able to see what value that same pixel currently has in the framebuffer. The fact that the built in alphablending can do this makes me suspect that a shader can do the same, but how

Could someone either tell me how to do that, o just ensure me that it can not be done, and point to an alternative method Currently I know of no way to do this other than

1 - set a texture A as render target

2 - set an empty texture B as a source texture for the shader

3 - render primitive

4 - set A as source and B as render target

5 - render primitive

6 - again swap A and B and render continously from back to front till done





Re: Game Technologies: Graphics Custom blending

BLANC Guillaume

>> That method uses the pixel values which has already been written into the framebuffer. Can this be done with ones own pixelshader

Blending cannot basically be done on the pixel shader. This is a plan I've heard at the GDC last year, like progrmmable filtering also is, but I can't remember if it's an OpenGL or a DirectX one.

>> Could someone either tell me how to do that, or just ensure me that it can not be done, and point to an alternative method Currently I know of no way to do this other than

From my understanding, I think the swapping technique will work cos you'll have half the primitive you need on each targets. Isn't it

I had two ideas, but don't know if any one works:
- If your render target can be used as a texture (ie: created as a texture with render target flag ), maybe you could sample it while writting to it. That way, you could sample previous pixel value in the shader, do your blending and then output final pixel color with no blending (overwrite pixel value). I'm not sure it's allowed by Dx or the driver because it could cos some cache issues as the texture could be read and write at the same time.

- Use 2 render targets with the following algorithm:
Clear RenderTarget 1 (RT1) and RT2
For all primitives from back to front
Set RT2 as a texture
Set RT1 as the current render target
Render the primitive on RT1 using RT2 as a texture where you can sample previous pixel color and do your specific blending code
Set RT2 as the current
Render again the same primitive on RT2 so that you'll use RT2 during the next iteration to sample previous pixels.
End For
Swap


I think the second technique will work. If you have only a hundred primitives that's no that much for the CPU. Of course it can be a lot for the GPU, but you could use a smaller code for both the vertex and the pixel shader for rendering on RT2 (which stores previous pixel color). This could limit overhead.