caching computed values from fragment programs

[john]

Hello,

I need to do some very crazy blending in a multi-pass rendering loop and trying to figure out a way to preserve blending coefficients between passes.

I need to compute new blend coefficients in a fragment program that will be used in the next render pass. Ideally I'd like to be able to write this coefficient to the framebuffer so I can then read it back in the next iteration, compute a new value, and write it back.

The problem is that fragment programs can't access the frame-buffer. The only way I can think of getting this functionality is to copy the alpha channel to a texture and using the texture as input to a fragment program, but I'd like to avoid the copying overhead when it seems so conceptually simple for a fragment program to source coefficients from the framebuffer.

I investigated the possibility of writing values to a texture, but that doesn't seem to be possible either.

Does anyone have any ideas on how I can cache data from one render-pass to the next?

[edit: the other point is that I can't use render-to-texture (which would also save the copy) because it isn't yet supported under GLX. damn, eh?]

thanks in advance,
John

[This message has been edited by john (edited 09-03-2003).]

[SeskaPeel]

And same question, is there a way to have access to the Z-Buffer for the current fragment, or to the stencil buffer ?

SeskaPeel.

[edit] Actually, the only way I found at this point was to write to destination alpha, and use it in subsequent passes, by tweaking the blending equation to get what you want. I did not find a way to make it work for my current problem though.

[This message has been edited by SeskaPeel (edited 09-03-2003).]

[zeckensack]

Originally posted by SeskaPeel:
And same question, is there a way to have access to the Z-Buffer for the current fragment, or to the stencil buffer ?

SeskaPeel.Topic hijacking is impolite. Anyway, as I don't have anything to say regarding john's issue ...

My copy of the ARB_fragment_program spec goes to great lengths explaining the interaction with depth. You get read access to depth via fragment.depth and write access via result.depth.

Please don't tell me that my version of the spec is outdated and depth access has been subsequently removed ... http://www.opengl.org/discussion_boards/ubb/eek.gif

[SeskaPeel]

Here is what I made so far :




// Pass 1
glBlendFunc(GL_ONE, GL_ZERO) ;
// Render scene

// Pass 2
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_FALSE) ;
glBlendFunc(GL_ONE_MINUS_DST_ALPHA, GL_ONE) ;
// Render scene


This way, you can cache a scalar value that is supposed to modulate your 2nd pass. I need a 4-uple to perform everything though ...

The aim is to encode per pixel ambient / diffuse ratio in the frame buffer alpha channel, but I need the rgb value to modulate my diffuse pass too. I get those rgb and alpha value with bump + cubic diffuse, I'd like to compute it only once ...

SeskaPeel.


[This message has been edited by SeskaPeel (edited 09-03-2003).]

[Mazy]

fragment.depth is not the zbuffers value for that fragment position, its just the incomming fragments depth value.

so, No, there is no way to access the zbuffers values, or the stencil buffers values from the fragment_program

[SeskaPeel]

zeckensack -> you're being rude, and you have no reason to be. First, I tried to answer his question, and then I completed by another one, so this is no topic hijacking. Second, fragment.depth is definitely not the z-buffer value.

SeskaPeel.

[zeckensack]

I didn't mean to be rude. I don't think "impolite" is an overly harsh word, though I'm not a native English speaker and may be wrong.

Regarding framebuffer depth, yes, you're correct. result.depth appears to be write only, and is pre-test anyway. Sorry for that.

Maybe it'll be sufficient if you copy-to-depth-texture and bind that to your fp to gain read access. That would be very slow with frequent updates though.

[SeskaPeel]

Hum ... might be interesting. Actually I could copy to texture the whole first pass, and access this data in the second. There would be no update at all.

But, ... how can I get correct s,t texture coordinates to look up in that frame buffer copied texture for the current fragment ?

SeskaPeel.