A Need For Change
Another example demonstrates the ARB’s inability to make rapid, efficient decisions. For a long time, OpenGL relied on a technique called pbuffers to render textures. All programmers agreed that the technique was very poorly conceived, difficult to use, and yielded poor performance. So, ATI proposed an extension to replace it—über-buffers. This extension was very ambitious. Beyond rendering to a texture, ATI wanted to make it possible to render to an array of vertices, along with other advanced capabilities. It may have all been a bit too ambitious, since the extension took too long to define, programmers got impatient, and Nvidia and 3DLabs finally made a competing proposal to at least enable rendering to a texture efficiently, without the generic approach taken by ATI’s solution. It ended up taking several years to see results from all these efforts—in the form of an extension called framebuffer_object, just to offer a basic feature already in DirectX 9!
So, in 2005, OpenGL had caught up with the Microsoft’s API launched three years earlier. All of the major players (ATI, Nvidia, 3Dlabs, and the software developers) agreed that things couldn’t go on this way, or else OpenGL would sink into oblivion little by little due to obsolescence. In this agitated context, the ARB passed the baton to Khronos in 2006, putting the future of OpenGL into the group’s hands. ATI and Nvidia both swore a pledge that they would rise above their own rivalry and collaborate effectively so that OpenGL could finally enter the 21st century. Developers were enthusiastic, since the Khronos group had shown itself to be very effective in managing OpenGL ES, the 3D API for mobile peripherals.
Very quickly the Khronos group began issuing communications about the future of OpenGL. Again the plan was based on a reworking of the API in two stages. The first revision, Longs Peak, would offer a R300/NV30 level of functionality on par with Shader Model 2 and a new, more flexible programming model. A little like OpenGL 2.0 Pure, which 3DLabs had proposed years before, the Khronos group planned to drop aspects of the API that were considered obsolete and focus on a small number of modern functions. This subset was called OpenGL Lean and Mean. The second major revision, codenamed Mount Evans, was to take the new API, correct any faults that had appeared in the meantime and add R600/G80 (Shader Model 4) features. The draft timetable was very tight, calling for the arrival of Mount Evans less than six months after Longs Peak. But the members of Khronos seemed confident.
In another change from the ARB, Khronos decided to communicate more openly. An informational newsletter was made available on the OpenGL site, to begin educating developers about the new API and let them give their impressions of it. Everything seemed to be going well until the end of 2007. Whereas the final specification for Longs Peak was expected in September, the Khronos group announced that due to problems, it would be delayed—without providing any details. The effort at more open communication of a few months earlier was forgotten and the Khronos group continued its work behind a total blackout. No more newsletter—in fact, there was not any news at all about the new API’ progress.
So, is the tesselation stage similar to AF or bi/trilinear filtering?
Tesselation, from what I've seen, takes a simple model intended for say a 4650 and "upgrades" it in memory making it more complicated and details for higher end cards. If I understand this correctly it will drastically reduce development time and costs while increasing visual quality.
Hmm, not sure about "upgrading" in memory. I looks like it just lets you pass in the control points that define your geometry rather than passing in all vertices for the mesh, which you yourself would probably have defined in a similar manner anyway.
Direct3D remains utterly irrelevant to me as a Linux user.
Direct3D remains utterly irrelevant to me as a Linux user.
But it is relevant to a lot of GNU/Linux users as the Wine programmers have to compatiblise what M$ implements in their 3D API... Currently they are making a dogs dinner of DirectX 9.0 support. However Windows games are generally well supported if they have an OpenGL option... Far Cry for example will not render under Wine in DirectX mode but when switched to OpenGL it works very well.
It is sad to hear about the difficulties OpenGL is having therefore.
Bob
Tessellation as far as I'm aware is adding more triangles to a model to give smoother surfaces over curves. It does not add any visual details but does add to the complexity of the model.
It breaks down the existing geometry into smaller triangles. (most 3d models are built out of triangles to begin with)
Very good aricle, thanks! I'm an OpenGL developer as well, and I wish it the best. I think that now, OpenGL needs money and commercial support - unfortunately these are the rights of current world. It would be a shame to have only one modern 3D API...
"the professional market, where OpenGL is the standard"
what market are you talking about? Please detail. Your readers are mostly common computer users, not specialsts knowing in-depth details about the computer graphics market.
"Since the ARB—the group in charge of ratifying the API’s development—included many different, competing companies.."
What are the most important members of this ARB? Whose words have big weight in that group? The readers might be curious - who are the people generating the conflicts that slow down the OpenGL evolution?
And by the way, why ATI and nVidia don't just take care about OpenGL and ignore that silly ARB? If they can't because of patents and such, they should make a new API from the scratch. Im pretty sure they are more than capable of it.
The problem with OpenGL is that industry users (e.g. CAD and scientific users) are opposed to change in the API which is blatantly against the ethos of the games development community. Industry users have already spent a lot of money on the OpenGL apps, so naturally they don't want the features they use to die. I think that what Khronos has done to date is the most logical route to take given the constraints they are working within.
The ideal solution would be to cut any ties that lead to a conflict of interest and pursue untainted API refreshes as they had originally promised.
As a cross-platform developer I want OpenGL to be a true competitor to D3D, I don't use anywhere near the full feature set of what current versions provide but if it looses at the top end, support will dwindle and the bottom end will also be affected.
If OpenGL even have a chance of competing against DirectX 10, then I'm more than impressed! OpenGL is the way to go for Linux and I and many others with me would like to use Linux as an gaming platform instead of Windows.
I'm very tired of using Windows and I don't like the operating system. It works, but it isn't very fun, unlike Linux which IS a enjoyable experience and feels fast even on old computer hardware, unlike Windows which never get the power it needs.