PDA

View Full Version : Aux buffers on current consumer hardware?



timfoleysama
04-11-2001, 08:56 AM
I asked this question in the pre-GF3 era and got a "no," but I'm wondering if the release of nVidia's version 10 drivers with the pbuffer extension means that we can also find a way to get auxilliary buffers for our use also. pbuffers are great but they reside in their own contexts and have their own depth/stencil buffers. I want a second buffer for colors that shares z and stencil with the main buffer, as well as a fast means of compositing that buffer with the main buffer (in a glBlend sort of way). Accumulation buffers don't have the flexibility I'm looking for (you can't render directly to them).

Why do I need this? Doing lighting and shadowing along with proper colored specular is hard when you only have one RGBA value per pixel to play with...

LordKronos
04-11-2001, 09:27 AM
Originally posted by timfoleysama:
Why do I need this? Doing lighting and shadowing along with proper colored specular is hard when you only have one RGBA value per pixel to play with...

Not difficult at all with the register combiners (and if you are willing to accept a feature that works only on the GF3, then you can accept register combiners).

You can do fully bump mapped, gloss mapped, distance attenuated, shadowed/self-shadowed, diffuse & specular lighted objects with only the RGBA color buffer (the alpha part is important), Z-Buffer, and stencil buffer.

The trick is to do all the "luminance" calculations first (gloss map, bump map, distance attenuation) by storing these in the alpha of the color buffer (you will need to use the color mask to avoid trashing the RGB portion). Then when you are ready to apply the color of the light, you load the object's texture in one tex unit, light RGB color into a primary, seconday, or constant color register, and multiply them together, then blend the result into the color buffer using a DEST_ALPHA:ONE blend mode.

I've actually done this: http://www.ronfrazier.net/apparition/research/advanced_per_pixel_lighting.html

There is also a bunch of similar stuff at the nvidia site: http://www.nvidia.com/developer

That being said, if you are still insistant upon using your technique...well, I dont know the answer to you question.

mcraighead
04-11-2001, 10:48 AM
Maybe at some point I'll get around to implementing aux buffers.

- Matt

HFAFiend
04-11-2001, 11:22 AM
Holy crap LordKronos! Thank you! :-) I am glad I stumbled into that post, because your site has some stuff I was just looking for!

IsaackRasmussen
04-11-2001, 12:16 PM
"Maybe at some point I'll get around to implementing aux buffers."

Harhar, you are mighty lazy today... it definately sound like it.

No, joke aside. Now I know who to bug, when I need Aux's.

timfoleysama
04-11-2001, 03:27 PM
I think my mind has been changed about how important aux buffers are for what i'm describing.

My thoughts were that if you had a pixel with diffuse light contributions d1...dn and specular light contributions s1...sn and a surface color c that the optimal equation for the end color would be:

(d1 + d2 + ... dn)*c + s1 + s2 + ... sn

but since d1 and s1 would need to be masked by the same shadows (stored in the stencil buffer for shadow volume methods) they had to be calculated in consecutive passes. I threfore thought an aux buffer for accumulating the specular contributions would be useful so that the sum(di)*c and sum(si) terms could be calculated in parallel.

Lord Kronos' contribution, i think, amounts to calculating:

d1*c+s1 + d2*c+s2 + ... dn*c+sn

with the helpful hint being that if di*c is to much for a single pass it can be dissected into scalar and vector (RGB) parts that are done in separate passes.

I had originally thought that this would be slower, since "c" must be recalculated many times. However, i neglected to note that:

1) switching buffers at least once per light source (my method) would be really slow
2) calculating "c" is often trivial these days (usually a solid color or single texture) so doing it once per light is no real loss.
3) my method can lead to bad results in bright scenes or on dark objects, since the summed diffuse lighting in the framebuffer is limited to [0,1] before being modulated down by the surface color. In the incorrect equation a surface can never "oversaturate" as the light on it adds up to over 100%. The correct equation, however, handles these situations.

Thanks...