Well, after a quick skim through the deprecation list, the API seems to have gotten quite a cleanup, if that forward-compatible profile really works. The 'fast path' should be easy to hit, since all data has to be in VBOs, and you have to use shaders. So at least that's there, and I know I'll be playing around with it when drivers are released.
But yes, dropping the objects was a bad idea.
OpenGL3.0.. I mean 2.2
I got my reply from khronos (you can email them too at gamedev@khronos.org) about what happened. My questions were answered with a question and some marketing fluff. Again, epic fail. Somebody from Khronos or the ARB needs to stand up and take responsibility for the bait and switch.
The problem with an api that doesn't mature with the hardware is that it will no longer be used, then no longer updated and then eventually be forgotten. The need for a up to date cross platform API is important to prevent vendor lock-in, which in the long term is always bad thing for the computing community. Healthy competition also makes all products better. DX9 is worlds better than DX3 due to OpenGL competition.
The ARB needed to look at this API with a software darwinism approach and evolve it. The people who couldn't be pleased with a new approach can continue to use the old API until it is no longer implemented by the ISV.
Bob
The problem with an api that doesn't mature with the hardware is that it will no longer be used, then no longer updated and then eventually be forgotten. The need for a up to date cross platform API is important to prevent vendor lock-in, which in the long term is always bad thing for the computing community. Healthy competition also makes all products better. DX9 is worlds better than DX3 due to OpenGL competition.
The ARB needed to look at this API with a software darwinism approach and evolve it. The people who couldn't be pleased with a new approach can continue to use the old API until it is no longer implemented by the ISV.
Bob
Quote:
Barthold will be hitting on some of those topics at the BOF. It would be premature for me to relay any details about the current state of work on improved object model and API, other than to say that addressing long standing warts in the current API is still important to us and an active topic of work.
I'd like to hear about which features or capabilities are missing, since adding capabilities in a standardized way, was one of the higher priorities in the development of the current 3.0 spec. (Another high priority was marking very carefully which features are going to be dropped in upcoming releases, which will simplify drivers and improve performance)
On Aug 11, 2008, at 9:34 AM, Bob Holcomb wrote:
> I am disappointed with the lack of advancement made by the ARB and Khronos. As an independent developer for cross platform visualization and games, OpenGL is my only option for 3d accelerated rendering. Where is the 3.0 spec that was promised a year ago? Where is the clean, updated API and the object model that was promised? Why all the secrecy for the last year? It doesn't look like anything was really done. There is a lot of explaining to do.
>
> Bob Holcomb
Perhaps the projected lifetime of the OpenGL3.0 standard had become so short, in the face of true GPGPU, that they decided to just nail together a semi-malleable standard over OGL2.1 to cover it and then concentrate on OpenCL for the future?
I was really looking forward to objects though, so I'll stick to my D3D10 a-thank you.
I was really looking forward to objects though, so I'll stick to my D3D10 a-thank you.
Oh dear, I wasn't expecting it to be great, but this is just poor, poor work. They've thrown out all the good stuff they had promised in the newsletters and basically just made a bunch of functionality core.
The BOF should be interesting, hopefully people will actually call them out on their bullshit because they're obviously incompetant.
The BOF should be interesting, hopefully people will actually call them out on their bullshit because they're obviously incompetant.
Agreed to most of the sentiment here. I've been waiting anxiously for the new API and this is a big letdown, and the year of silence in the face of such massive under-delivery is inexcusable. I've said many times here that I had faith that Khronos, given the excellent job they've done on ES and Collada (among others), and the new ARB could right the OpenGL ship; yet here I stand with the proverbial egg on my face.
That said, maybe catering to the CAD crowd, with enterprise-class concerns -- stability, legacy support, some otherwise obscure features, etc -- and the entertainment and multimedia crowd, with consumer-class concerns -- speed, fast iteration and cutting-edge features -- is not the best idea.
Even if for no technical separation of concerns (after all GL has successfully catered to both audiences in the past) at least separating market concerns would allow both sets to evolve on their own path without being chained to the other, similar to how OpenGL|ES is free of much of the GL legacy. In fact, taking OpenGL|ES 2.0 as a base, adding all the object-model changes that had been planned for 3.0, and support for more recent hardware features would be a pretty decent stab at a games and multimedia-centric API for the desktop PC, maybe it could even be made an OpenGL|ES profile similar to SC, or all the OpenSL variants.
That said, maybe catering to the CAD crowd, with enterprise-class concerns -- stability, legacy support, some otherwise obscure features, etc -- and the entertainment and multimedia crowd, with consumer-class concerns -- speed, fast iteration and cutting-edge features -- is not the best idea.
Even if for no technical separation of concerns (after all GL has successfully catered to both audiences in the past) at least separating market concerns would allow both sets to evolve on their own path without being chained to the other, similar to how OpenGL|ES is free of much of the GL legacy. In fact, taking OpenGL|ES 2.0 as a base, adding all the object-model changes that had been planned for 3.0, and support for more recent hardware features would be a pretty decent stab at a games and multimedia-centric API for the desktop PC, maybe it could even be made an OpenGL|ES profile similar to SC, or all the OpenSL variants.
Just another thought (although I must admit I didn't read all the posts): What is the alternative to OpenGL when it comes to DX10-like features on OSes other than Vista? I don't know any.
Quote:Original post by rbarris
3.0 could be looked at as the last fully upward compatible revision of OpenGL; since it introduces a deprecation model allowing for the phased elimination of obsolete API's (a set of which are already defined in the spec). The intent there is to provide for an orderly simplification of the specification and drivers for upcoming releases, the next of which is scheduled for less than 12 months from now.
Yeah, and what good does intent do anyone?
A year ago, Khronos intended to give us a new, cleaned-up API, didn't they?
Why on Earth should we expect the situation to have changed next year? Or two years from now? 15 years? It doesn't matter. Deprecation hardly ever means anything other than add a few extra words into the specification.
Next year, old CAD apps will *still* use the same GL code, deprecated or not. Next year they'll complain just as much if you drop support for 15 year old functionality that should never have been added in the first place.
Be logical. The so-called rationale for ditching the "real" GL3.0 was that old existing CAD codebases *refuse* to update to a completely new API. So where exactly is the incentive for them to prepare to do so now? They've just proven that they can effectively freeze the API. Wanna guess at how much development time they're going to throw at "updating our codebase to not use deprecated OpenGL features" over the next year?
Why would they bother? What does that buy them? Isn't it easier for them to do the same next year, saying "You can't remove this, we still use it"?
No, the deprecated features won't be removed. Not now, not next year, not ten years from now. And the API won't be cleaned up. There's no real incentive for doing so, is there? Not for CAD people. Not for the ARB. And game developers aren't important.
Why should anyone care that the next revision is scheduled for "less than 12 months from now"?
First, GL3.0 is way overdue, so why shouldn't 3.1 or whatever be delayed as well?
And second, even if it's out on time, what is there to look forward to? Inclusion of two more extensions into the core?
It seems to me that what you're saying is that "two years from now, we'll have another big nothing ready".
Gosh, can't wait.
Quote:
BTW we have set up a mail reflector specifically for questions and suggestions specifically relating to game development using OpenGL 3.0 - if there is some piece of hardware functionality not addressed by the current 3.0 spec, now is exactly the right time to let us hear about it.
I thought a year ago would have been "exactly the right time" to ask for feedback. But apparently that's not how the ARB works? Fail to deliver *first*, and ask for feedback once it's too late to make changes?
Why exactly is it exactly the right time to let you hear our questions? What are they going to achieve *now*?
Actually, I do have a question. Why should anyone write an OpenGL application today? if I have a 15-year old one, then sure, it makes sense to use OpenGL, because I know that I can keep using the same code for the next 30 years. But that's not exactly a strategy that's going to boost the popularity of OpenGL, is it? Scare away all new projects, and try to hold on to existing ones?
That is what amazes me the most about this fiasco. It's not just "CAD is more important than games" (which is arguable), but it seems to be a much more basic case of "old, existing OpenGL applications are more important than new ones". It doesn't matter that no one starts new OpenGL projects, as long as we can keep the existing ones happy.
That's not the most forward-looking strategy I've heard. I'd be hard pressed to think of another organization or company that actively decided that "gaining bigger marketshare isn't important!"
Quote:Original post by Yann L
But what can you do if the only real competitor kills itself with a stunt that would be the digital equivalent of a Darwin Award ?
Actually, that seems like it would be one of the better outcomes. As long as OpenGL lives, it seems it'll be the same mess it is today.
If it were to really kill itself, what then? Obviously, non-Windows platforms need some kind of access to 3d rendering, so a new API would have to be created.
Of course, OpenGL actually dying is pretty unlikely (more likely, it'll just hang around like the mess it currently is), but *if* it were to disappear completely overnight, something new would have to be created. And that might not be such a bad outcome.
Quote:and other opengl applications that people use and develop all over the globe that run not only on windows, but also on linux and mac.
So what you're saying is, OpenGL is for platforms where you don't have a choice. [grin]
Complete and utter Fail. I stopped reading the spec the moment I saw "Vertex3f".
That's it. I'm done. There's nothing to even have faith in anymore. OpenGL is dead, Long live DirectX.
That's it. I'm done. There's nothing to even have faith in anymore. OpenGL is dead, Long live DirectX.
Now in all that atmosphere of doom, there might actually be a little ray of hope after all...
May I direct your attention onto This 'little' extension here. This (well, monstrous) extension probably leaves quite a few people scratching their heads. But in the light of recent events, it actually makes much more sense. In fact, this thing could allow the implementation of the very object model that was ditched in OGL3.0, without the overhead of the obsolete binding state model ! Assuming it is well supported and uses a fast path (ie. it circumvents the internal bind logic of the driver), one could think about implementing a pretty efficient high level object model oneself on top of it.
Also note (emphasis added):
Hmm...
May I direct your attention onto This 'little' extension here. This (well, monstrous) extension probably leaves quite a few people scratching their heads. But in the light of recent events, it actually makes much more sense. In fact, this thing could allow the implementation of the very object model that was ditched in OGL3.0, without the overhead of the obsolete binding state model ! Assuming it is well supported and uses a fast path (ie. it circumvents the internal bind logic of the driver), one could think about implementing a pretty efficient high level object model oneself on top of it.
Also note (emphasis added):
Quote:
This extension trivially interacts with NV_texture_cube_map_array
Hmm...
To be fair, Microsoft has been putting an amazing amount of effort into its game development libraries across the board, and essentially giving them all away for free. The only thing you need to "give up" in return is to use one of their OSes (which isn't such a big deal when you look at their 80%+ marketshare).
Of course, it remains to be seen how this changes, if at all, when it becomes apparent that OpenGL isn't being used extensively anymore.
Of course, it remains to be seen how this changes, if at all, when it becomes apparent that OpenGL isn't being used extensively anymore.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
