Just for completeness:
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=255712
Oh and while we are at comparing OpenGL with D3D10:
D3D10 includes “DepthClip” (aka NV_depth_clamp). Maybe that could be included into core sometime, too.
What is the real-world usage of this functionality (different blend func per rendertarget)?
I’d argue that aesthetically it would be nice to treat all render targets as equals rather than to single RT0 out as special - brings a nice symmetry to things in a general sort of way.
As for a real-world use case, I’m stumped 
For pure graphics there are certainly only few use-cases. But when you use your GPU for more general stuff it could be quite handy. For example you could store in RT0 the combined result of a computation, while in RT1 and RT2 you store MIN and MAX values that appeared (this reminds me of HDR). Granted, this sounds more like a case for Cuda or OpenCL but not every problem is so complicated that it needs the full power those.
The whole point is, that it seems to be no problem for the hardware and is in use for over 2 years. As such i would like to finally have this restriction lifted in my favorite API too. Especially because blending as the very last step in the pipeline is much too restricted anyway. Of course simply getting access to the already present value in the framebuffer through the fragment-shader would be the best solution by far, but there seem to be hw restrictions that make this impossible.
Jan.
Second that. For stencil shadow volumes, that and an infinite far clip are the only robust ways to avoid having to generate far caps for shadow volumes (AFAIK).
In use for two years? By who? For what?
I completely agree the API should expose hardware functionality. I’m just curious what people are actually doing with it.
Can anyone list any rendering technique, or whitepaper, or game engine that uses this functionality?
http://developer.download.nvidia.com/SDK/10.5/opengl/src/dual_depth_peeling/doc/DualDepthPeeling.pdf
“In use for two years?”
Implemented in D3D10 for over 2 years.
And that depth-peeling paper is a very good argument for adding that functionality to OpenGL.
That paper says that:
- GeForce 8 hardware doesn’t support different blend functions per render target.
- This feature was added to D3D10.1, which means it isn’t really two years old.
Nonetheless, that sort of algorithm is a good example of where you could use this functionality, if the hardware supported it.
Looks like the upcoming SM5 hw will allow for some basic A-buffer like operations, so we may at last be closing in on “solving” the OIT problem at any rate.