Does anyone know about upcoming OpenGL extensions for new hardware? There have been many references to a _much_ needed 'Render-to-Texture' extension, but little else on new OpenGL extensions, particularly those that expose the pixel-processing power of upcoming chips, which will come with the DX8 pixel shaders.
Considering that the *consumer* graphic accelerator biz has consolidated [really just 4 big players right? => Nvidia:ATI:VIA(via S3):Matrox], i hope that exposing cross-platform GL extensions will be a requisite to stay competitive. Although Windows is the $$primary$$ 3d PC platform, the tiny market of non DirectX platforms (linux/apple/cross-platform-titles) should be have some value for chip-makers that outweighs the costly engineering of driver/api_extension development.
Unfortunately, nobody except Nvidia has really developed their GL capabilities. Despite repeated email petitions, ATI has yet to expose any Radeon pixel/register processing except a 'dot3' env, which is sad considering the potential of 'limited dependent texture reads' via their EVBM as well as the priority_ID (for Shadow-maps) and any register capabilities.
Via NV_RegCombiners, Nvidia exposed capabilities not available in DX that reduce the #passes or enhance operations (additional attentuation, 16bit compare for Shadow-maps,etc.). Hopefully this chip-specific exposure continues for NV20 & X-Box.
Since there are only 4 major chip-makers, it is simple for a software developer to write pixel-handling routines for each chipset/style-of-chip-capabilities (in fact, this really needs to happen in most 3d games/environments just to balance performance/visual-quality tradeoff). In the past, most chip vendors exposed an entire API(Glide,S3Metal,RRedline,etc.), not just an optional extension to a common API (OpenGL).
I'm raising these issues because i need to stay with OpenGL, since it is _the_ choice for any cross-platform work. Although we spent considerable time playing with the new DX8 materials, there isn't enough new functionality to have 2 codebases (1 DX8 for Windows, 1 OpenGL for all others). More importantly, the new DX8 pixel shaders forecast some difficulties since they are costly to generate (i.e. recommended pre-compiled use).
When rendering from a large database of dynamic 3d objects/materials, there is an enormous variety of possible shading methods. Many events in the world will change an object's 'shader' such as adding a highlight, x-ray movie-projection, burning, wet, or even consider a piece of shiny metal that gains a splattered dirt decal texture which also varies the specular shininess. The possible configurations are too large to be precomputed (& compiled as a fixed set of DX Shaders). But dynamically generating these shading methods into a set of register commands and/or multi-pass states or a 'run-time' pixel shader is feasible. That's what we do now for plain vanilla GL, dual-pass EXT_Env_Comb, NV_RegComb, etc. For programmable shaders, we will just have to treat them like textures and have a working 'uploaded & compiled' cache of current shaders. Yet we fear the compilation-time for creating/uploading a new shader will regularly interrupt the game world.
Thus we are very curious if anyone out there can share/hint at upcoming plans for GL exposure and any pros/cons for programmble but highly-dynamic pixel-handling?
Thanks for reading this lonnnnnng post and for any thoughts-
[[PS-Chip-makers:: it'd be great to see you guys speaking out on this, which keeps the GL community enthusiastic to develop for your future chipsets. The 3d market is slowly evolving beyond just games! ]]
