The ARB announced OpenGL 3.0 and GLSL 1.30 today

@People who are looking for a “new feature only spec” there is a spec that highlights the new parts [in magenta though :(( ] and strikes out the deprecated parts.

Now to the subject :
Well, this certainly proves that Khoronos did not have the capacity to be entrusted with upgrading the OpenGL in the first place.

What was supposed to be the main focus of OpenGL 3.0, was the new form, so every developer having a product for a specific purpose and hardware, would be able to port code to it, and maintain the code much more easily.

But OpenGL 3.0 is utter fail in having an identity and a purpose to serve.
Is it an all-encompassing standard ? Fail, it needs DX10 class hardware to support it fully.
Performance that rivals DX ? Fail, it does not really represent the internal hardware and tuning your program to have good performance needs extensive knowledge of the underlying hardware, it probably needs a book of it’s own to have a good performance.
Is it an intermediate standard for something better ? Double Fail:
1 - From Jan 2008, the new direction should have been announced, asking developers for feedback and help [along with an apology for what you bragged about at OGL BOF 2007 and what you were to deliver], not by doing it like this and leaving OpenGL developers with a very strong feeling of resentment.
2 - Every new OpenGL standard that is to be half-useful, SHOULD break code compatibility, vendors that are too lazy to update their OGL code should rely on an older version, be it OGL 2.1 + Extensions, be it “Non deprecated OGL 3.0”

Does it really bring something with “Direct Access” extensions : Most probably failure, people should BOTHER to make Direct Access code for it, less developers, less feedback as well as AMD and Intel’s reluctance on making competitive OpenGL drivers [reading the first lines, it only mentions nVidia bothering about implementation and contributions as a major GPU vendor]

Does it succeed in being taken seriously ? FAIL, and that probably could have been the only thing that would warranty serious support and enthusiasm from the developer community.

The put it bluntly, the only people who are really happy, are the one’s that have tons of existing legacy code, what I want answered by the ARB people here is that they feared to branch the code, and they failed to confront CAD companies, why should I expect anything different in the upcoming year ? How are you going to muster the courage for that ? How am I going to believe that you actually CAN remove deprecated features ??

Then read it again, and put it in the context of someone who assumed we were moving to the object model, rather than someone who knows it was a compromise reached after weeks of meetings with CAD companies.
Believe me, it’s funny.

Does the ARB know that with the garbage they pulled will literally kill the OpenGL community? Like seriously, every forum, I’ve been to that does graphics, like GameDev, Here, and others. Alot of people have started learning direct3d now. It sucks that the ARB doesn’t give the community what they asked for and wanted. Can’t compete with Direct3D anymore, no nothing. They basically just shot off any chance of rivaling Direct3D to bare nothing.

Even if they release the stuff, how many more years are we going to be stuck with stupid 1.x/2.x crap?

Just as a point I have it on good authority that this change wasn’t down to CAD companies. As to what happened inside the ARB to bring about the current situation, well that I don’t know, but I can state that it wasn’t the CAD guys who caused it.

I’m really disappointed of the work of the ARB. I was hoping for a clean start with a new API. But hey, OpenGL can still be extended with extensions. We should develop a new extension GL_EXT_teh_real_ogl3 as a community effort :slight_smile:

well I can honestly believe that. I’ve had the pleasure of working with the source code of a few big name CAD/engineering apps over the years, and they all had the rendering code quite well abstracted. This is to be expected, because they go back a long way before OpenGL, like SGI’s original GL etc.
The new object model would have simply meant a few new source files put into the makefile, and a smattering of #ifdef’s.
But the ARB needed a scapegoat - and to some extent so do we.
Having said that, I did read somewhere that AutoCAD still uses selection mode, which suggests GL is heavily embedded in their source.

if you refer to
http://www.opengl.org/registry/doc/glspec30.20080811.withchanges.pdf
either I am blind, but nothing is is stroke out for me, just the new stuff in magenta.

The GLSL specs have the strike out, but the GL specs don’t.

I am completely disappointed.

In 2 years was plenty of time to write a completely new API with docs and examples and everything, considering the amount of ARB peoples involved.

Honestly, is that what you show at siggraph?? It cant be true…

Yeah, OpenGL looks more like dead now. There are loads of reasons to consider that. And yeah, I compare it with DX.

OpenGL 3.0?
You mean 2.2, that’s more like it. Believe me if they are heading this way with extending the extended extensions, they will be killed by legacy.

Has anyone noticed that only fixed function vertex processing is deprecated? What about fragment processing??

Just a quick question. Seeing as ALL the matrix stuff is deprecated (glMatrixMode, glTranslate, etc.) does that mean we need to keep track of the matrices (modelview, texture etc.) ourselves and pass it to the vertex shaders?

i would call it half a**ed attempt. the more i read the new spec the less i can understand it.

what in hell prevented them from doing a fully new api as GL3 profile? even it it would take versions up to 3.5 to get it round and clean. why not try this way?

the profiles are nice, they can be used in the future to distinct hardware tech level (like D3D is doing ;)). but in this form they are a waste.

i think this is just a marketing game to say GL3 is the equivalent to D3D10, which it is clearly NOT (spell geometry shaders for example).

as nice as the new direct state access extension is. it will take ages to get it into shape and the ages to get the then depricated bind-to-change code out of the code bases (with again resistance of some software vendors to change their bases).

all in all just a waste of time and good effort into the long peaks api.

yes

Yes, and its going to be a mess since the promised “program environment uniforms” are also missing. You have to upload each matrix into all the shaders that use it every time it changes. Same is true for glPushAttrib/glPopAttrib. They ripped it out without providing a proper replacement mechanism (such as state objects).

OpenGL 2.2?
You mean 1.8. We’ve been through “major version” once allready.

OpenGL 3.0 was exactly what I’m looking for. It was like a dream.

Today I woke up and the World looks grey again.

I’ve been working with opengl for a few years now.
I think the 2.1 api is basically solid. I would much prefer to see an opengl ES approach to opengl 3.0. Ie strip out the parts of the API which suck. Immediate mode for one, since it is nearly impossible to optimise for. Plus i’ve seen so many CAD programs try to push 500k vertices per frame, and wonder why performance is so poor. Display lists are another, again these must be a nightmare to maintain at the driver level. Other bizare stuff such as glRectf ?? That really has no place in the API.

I’d also like to see frame buffer objects standardised rather than just be extensions. Plus, the ability to do multisampling with offscreen render targets. The current extensions to do this seem to be somewhat of a mess.

It would also be a novelty to have updated header files. The header files for windows are now 12 years old ? I mean, wtf.

Dukey, FBO is a core feature in GL 3.0 (including multisampling and blit).

And what about multisample textures and signed fixed point texture formats? Cubemap arrays? Per color attachment blend modes?

Both FF vertex and pixel processing are deprecated in OpenGL 3.0, it’s in appendix E (a few paragraphs down from the reference to FF vert processing).