OK, just ranting a little. I love OpenGL. I really do. But there is one point, that bugs the hell out of me: the non-standarization of medium level texture environment combiners. Low level combining is approved by the ARB (ARB_texture_env_combine). High level shading as well (ARB_fragment_shader/program). But what about the level inbetween ? Did you ever had that problem, that you wanted to support nice shader effects, but without having to resort to DX9 type cards ? ARB_texture_env_combine is far too limited. NV_register_combiners, NV_texture_shader1/2/3 or maybe ATI_fragment_shader are available on most intermediate DX7/DX8 type cards. But this combine level is simply not ARB approved ! It''s very common to use it, but you always need to code at least two code paths (nvidia and ATI), and maybe even a fallback path. That sucks. Now besides this rant directed at the ARB, I still have a question: does anyone know if there is some utility library/code snippet available, that will present a unified interface for the most used vendor dependent combiner extensions ? Basically a (fast) layer between the programmer and reg coms / ATIs equivalents ?

the only thing i know which might do the job is Cg, i know it supports the NV Reg Com/tex shader stuff but i''m not to sure about the ATI fragment shader extension

Cg is no option, since it only supports nvidia and ARB extensions, but no ATI extensions (which is not surprising, considering that Cg is developed by nvidia...)

And help the language from their biggest competitor to gain grounds ? I don''t think so

With the current and upcoming GLSL implementations, Cg is rendered obsolete anyway. I''ve never been a big Cg fan. Far too vendor dependent, and locked into control from a single manufacturer. GLSL remedies that problem for ARB_FP and ARB_VP style shading.

I''ve searched the web for some adequate vendor independent ''medium-level'' combiner support, but couldn''t find anything. There is this older nvparse thing, but this is nvidia-only again. I guess it''s time to write something myself. *sigh*. I''ll LGPL it, as soon as I have something working.

Thanks for the suggestions.

Well, technically Cg is very nice, I fully agree. I don''t have a problem with nvidia either, despite some people saying otherwise, their chipsets are actually pretty good (but their devrel sucks, compared to ati). But Cg is still vendor dependent - not from a technical, but from a marketing point of view. ATI will never ever implement a translation module, simply because the language is under nvidias control. It''s not an open standard, or a language designed by a board of manufacturers, such as GLSL. That''s an immense advantage of GLSL over Cg. ATI (and other third party manufacturers) don''t have the slightest control over Cg. If nvidia decides to change things, there is nothing ATI can do. This is different with GLSL.

About D3D support, well there is HLSL. The only drawback is that GLSL and HLSL unfortunately aren''t compatible, this is indeed an advantage of Cg. A less and less important one, since the dual-API approach seems to become less attractive nowadays. Now that D3D and OGL support are both standard on common 3D hardware, you''ll probably just use one or the other.