OpenGL Blending Question

Lutz · 2005-05-25T08:18:51

Hey there! Yet another blending question. I've a fragment program computing TWO colours C1 and C2 and I'd like to perform the following blending operation: C_new = C2 + C_f * C1 where C_new is the new color of my fragment and C_f is the old one (the "destination values" as in the reference of glBlendFunc). Is this possible in 1 pass?

Graphics and GPU Programming Programming OpenGL

Started by Lutz May 23, 2005 09:38 AM

15 comments, last by Gorax 18 years, 11 months ago

Gorax

202

May 24, 2005 10:56 AM

Perhaps you can tell me how things get coloured if the programs are given nothing to work with?

Some Cg fragment shader code:

typedef struct {  float4 col0 : COLOR0;  float4 tex0 : TEXCOORD0;}FragIn;arbfp1 fragout_float main(FragIn inFrag,uniform sampler2D texture1){  fragout_float outFrag;  //just like GL_MODULATE:  outFrag.col = inFrag.col0 * tex2D(texture1,inFrag.tex0.xy);  return outFrag;}

The equivalant ARB fragment program code (produced by Cg):

!!ARBfp1.0PARAM c[1] = { program.local[0] };TEMP R0;TEMP R1;TEX R0, fragment.texcoord[0], texture[0], 2D;MUL result.color, fragment.color.primary, R0;MOV result.depth.z, R1.x;END

The input is limited to 8 texture coordinates (0-7) and 2 colours (0-1), the output is limited to 1 colour and 1 depth value. These are on pages 219 and 220 of the Cg Toolkit (235 and 236 if you're using the PDF pages). I think it's time for you to do a little research. ;)

JavaCoolDude

670

May 24, 2005 11:09 AM

Thanks for the advice, but if you read into it a little more you'd figure that the primary and secondary colors are linear interpolation of the vertex attributes coming fresh out of the rasterizer. To be a little more precise, fragment.color.primary is the linearly interpolated diffuse color of the vertex and it has absolutely NOTHING to do with the frame buffer or existent colors; it is brand new.
Take care

SXML 3D Engine Test

Gorax

202

May 24, 2005 12:22 PM

Quote:Original post by JavaCoolDude
As far as I know fragment programs and shaders for that matter do not take an input color or an existent fragment and act on it to produce the output.

The 'input color' and 'existent fragment' in this case are two seperate things, seperated by the disjunction 'or'. Fragment shaders do take an input colour, therefore my response was not invalid. Choose your words carefully and they wont be misinterpreted. Also, if you bothered to read my previous posts, you would have noticed I mentioned the fact that frame buffers were not even mentioned till AFTER I made my first post, at which point you have done nothing but complain about what I've written.

Since this was not clear enough, I'll try to make it as clear as possible. THIS is how I saw Lutz's posts:

Lutz: "I've got this fragment program:"

//Cg codetypedef struct {  float4 col0 : COLOR0;  float4 tex0 : TEXCOORD0;}FragIn;arbfp1 fragout_float main(FragIn inFrag){  fragout_float outFrag;  float4 c1 = calculateC1();  float4 c2 = calculateC2();  outFrag.col = inFrag.col0;  return outFrag;}

From there, I was obviously confused as to how in the hell Lutz couldn't get the desired result. This *should* be evident by my posts. The single line of code needed to turn this into something usable is this:

outFrag.col = c1 + inFrag.col0 * c2;

After all, if the fragment program already calculates C1 and C2, would it not be safe to assume (without the buffers you NEGLECTED TO MENTION earlier) that this would solve the problem?

Lutz, PLEASE REMEMBER TO NOTE DOWN EVERYTHING RELEVANT TO YOUR PROBLEM NEXT TIME. Finally, JavaCoolDude, I'm not psychic, so don't start complaining about my replies when I haven't been given all of the relevant information.

JavaCoolDude

670

May 24, 2005 12:29 PM

It's all good buddy, it's just a matter of miscommunication that has been cleared up now.
Indeed, fragment programs receive incoming color that they may or may not use depending on the nature of the program. The thing is, I was under the impression that you were saying that it is totally feasible to retrieve frame buffer colors from within the fragment shader/program without using an intermidiate target; and that’s what is clearly impossible :P
It's all good now, thanks for clearing up the misunderstanding :)

SXML 3D Engine Test

Kalidor

1,087

May 24, 2005 11:04 PM

I know this is pretty much resolved now, but I just wanted to comment on this...

Quote:Original post by Gorax
Lutz, assuming you understand English, perhaps you should re-read your original post before commenting on my reply. Perhaps you can point out the part where you mentioned the fact that you were using a frame/colour/whatever buffer, because I can't. Is it not fair to say that somebody, like myself, who manages to stumble upon this thread, with this *very* limited amount of information, would fail to see exactly what in the hell it was you were trying to accomplish?

Looking at the first post again I don't see any sign of it being edited, and I'm pretty sure I remember reading the following when I first read it...

Quote:where C_new is the new color of my fragment and C_f is the old one (the "destination values" as in the reference of glBlendFunc).

To me that says C_f is the value of the pixel already in the frame buffer. So before making such a condescending reply in the future try to make sure you fully understand what you are replying to. (Hmm... I wish I took my own advice more often [grin]).

To make this post semi-constructive...

As has been said, the only way to get a fragment's previous color inside a fragment program is to render to texture and use that later in your fp. If you're not sure how to do this, look into glCopyTexSubImage2D or the new GL_EXT_framebuffer_object extension. As of right now, only nvidia beta drivers support this extension, but it should be pretty well supported in the near future.

Another alternative is PBuffers and using the render_texture extension, but if you haven't used it before there's not much of a point to learn now with FBOs so close, so stick with glCopyTexSubImage2D in that case.

Lutz

462

Author

May 25, 2005 05:21 AM

@Gorax:
I really didn't want to offend you in any way. You are absolutely right that I should have made my post more precise (something like C_f is the color already in the frame buffer).
Sorry for that. Language is the main source of misunderstanding.

Quote:Original post by Kalidor
As has been said, the only way to get a fragment's previous color inside a fragment program is to render to texture and use that later in your fp. If you're not sure how to do this, look into glCopyTexSubImage2D or the new GL_EXT_framebuffer_object extension. As of right now, only nvidia beta drivers support this extension, but it should be pretty well supported in the near future.

Another alternative is PBuffers and using the render_texture extension, but if you haven't used it before there's not much of a point to learn now with FBOs so close, so stick with glCopyTexSubImage2D in that case.

Let's hope ATI puts somewhat more work into their OpenGL drivers and come up with new drivers soon. I've got a Radeon 9800, so framebuffer objects are no alternative right now.

I've worked once with pbuffers and I don't like them much due to memory and context switching overhead. Also, they don't seem to support fullscreen antialiasing. I don't know, however, whether FB objects do.

The easiest method will be 2-pass (using blending twice), although probably quite slow... I'll see anyway.

Thanks for your comments!

Gorax

202

May 25, 2005 08:18 AM

Quote:Original post by Kalidor
To me that says C_f is the value of the pixel already in the frame buffer.

To me, it was merely a variable name (the fact that I don't read books/articles on programming probably doesn't help), so I see where it all went off the tracks. Hopefully I wont make this mistake twice. ;)

OpenGL Blending Question

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

OpenGL Blending Question

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines