OpenGL 2.0 formally announced!

Story here , though it’s a bit thin on detail.

Kind of odd that this didn’t appear on the opengl.org homepage first.

There are some features missing:

  • floating point textures/buffers
  • pixel memory management (either PBO or Superbuffer)
  • color clamp control

Some extensions are already listed in the extension registry:
http://oss.sgi.com/projects/ogl-sample/registry/

ARB_draw_buffers
ARB_texture_rectangle

There are some features missing:

  • floating point textures/buffers
  • pixel memory management (either PBO or Superbuffer)
  • color clamp control

Regardless of the misinformation that’s outthere about GL 2.0, it is nothing more than a GL 1.6; an incremental change. They just folded more extensions into GL like they always do with new GL revisions. Nothing major or earth-shattering.

Since none of the functions you are refering to (outside of PBO) has an actual ARB extension publically available, it isn’t reasonable to just hurry them into the core. Let them be extensions first.

Originally posted by Korval:
[b]Regardless of the misinformation that’s outthere about GL 2.0, it is nothing more than a GL 1.6; an incremental change. They just folded more extensions into GL like they always do with new GL revisions. Nothing major or earth-shattering.

Since none of the functions you are refering to (outside of PBO) has an actual ARB extension publically available, it isn’t reasonable to just hurry them into the core. Let them be extensions first.[/b]
I know that OpenGL 2.0 is just one more new version of OpenGL where some extensions are pushed into the core. But the question is, which extensions are in OpenGL 2.0 core. I hope there will be an answer in the next days…

My information about OpenGL 2.0 extension was only based on March ARB notes where those extensions seemed to be in OpenGL 2.0 core.

Either way, they really need to start speeding up this kind of thing else OpenGL is going to be left in the dust. You would think a 3D rendering API in the year 2004 would be able to adapt to new technologies faster than the years it seems to take to even ARB an extension non the less add it to the core.

OpenGL seems to be keeping pace with developments, extensions are useable and finally get into common or ARB extensions each major release after much debate. The ARB is a bunch of collaborating competitors so the situation isn’t surprising. It’s naive to expect anything better.

2.0 seems to put more in the core and make some formerly optional stuff mandatory, it’s about time but it would never have happened if SGI, SUN and a few others hadn’t been thoroughly beaten to the point where they can only afford to use the graphics chip designs of the PC commodity vendors. OpenGL implementors on the ARB tend to block anything getting into core that implies they aren’t up to date, even when it is obvious they aren’t. This is how the ARB works, get used to it, it won’t change. What has changed is the way everyone on the ARB uses increasingly similar hardware from fewer design houses and that is probably good for the pace of OpenGL spec, although a lot of the ‘big stuff’ seems to be in place already (IMHO).

About the only significant thing in 2.0 that I can see is that some already popular core but optional ARB extensions are being promoted to non-optional core. There’s not a lot new in there to justify the 2.0 monicker vs 1.6 IMHO. The extensibility of OpenGL has stolen the 2.0 thunder around about version 1.5.

Originally posted by dorbie:
What has changed is the way everyone on the ARB uses increasingly similar hardware from fewer design houses
Say what?

OpenGL seems to be keeping pace with developments
Which OpenGL are you looking at?

OpenGL adopts things much slower than any competing API, and therefore is not “keeping pace with developments”. D3D had a decent C-like shading language well before the ARB got around to approving glslang. D3D has easy, trivial, render-to-texture facilities; OpenGL still doesn’t have this, either through superbuffers or through render_target.

There are a number of minor other features (the tech behind mesh instancing, etc) that are currently available, but do not have even vendor-specific extensions, let alone ARB or core.

The only forward-looking extension that the ARB is pushing is the NPOT texture.

The ARB is a bunch of collaborating competitors so the situation isn’t surprising. It’s naive to expect anything better.
Which is what makes it that much more sad that OpenGL is slowly becoming marginalized. You’d think that this group would see this happening and try to stop it, but they’re too caught up in politics and so forth to even consider it.

There is a presentation (anounced at www.opengl.org)) where you can see what is currently happening.
http://www.opengl.org/about/news/siggraph2004/bof2004_intro_web.pdf
It seems that we will have an ARB floating point texture extension in a month, a simpler render to texture extension, etc.

By the way, (OT) finally RenderMonkey 1.5 is on the web (including the SDK).
http://www.ati.com/developer/rendermonkey/index.html

Hope this helps.

“It seems that we will have an ARB floating point texture extension in a month, a simpler render to texture extension, etc.”
That’s really great news!

Originally posted by Cab:
It seems that we will have an ARB floating point texture extension in a month, a simpler render to texture extension, etc.
This would be really great!!!

I read the BOF about the ARB float buff which is great.

Also what about NVidia’s EXT_render_target?

The only forward-looking extension that the ARB is pushing is the NPOT texture.

Ahem! draw_buffers!

Korval, that’s an interesting point of view, but I’ve seen OpenGL look in much worse shape in the past. I too would like to see the vendors cooperate more, in some ways they’re playing into the “big predatory monopolist’s” hands, but I do see a lot of activity with OpenGL and in the final analysis plenty of cooperation (or capitulation by one side or the other on sticky issues). OpenGL tends to get the extensions it needs the only problem is there’s often a bifurication before the consolodation of the API and some interesting conflicts (Cg vs glslang being the most significant IMHO). There’s a lot to be happy about with the current state of OpenGL, I think things could have been much worse.

w.r.t. marginalization, I guess I don’t see that but it depends where you look. With windows games probably there’s some marginalization OTOH the proliferation of platforms makes OpenGL essential, D3D is a Microsoft only vehicle. Doom 3 should also herald a batch of OpenGL Windows games based on that engine. That’s not the whole picture though, OpenGL is supported and remains viable & that’s what counts if you’re interested in freedom.

Nice to see that there is a “shader metafile” working group. It would be nice to have a standard FX file similar to CGFX and DirectX.FX.

The adoption of extensions has been steadily improving as the ARB has committed to yearly release cycles. Tools on the other hand are a different story, D3D still has standardized tools long before OpenGL.

Originally posted by Cab:
There is a presentation (anounced at www.opengl.org)) where you can see what is currently happening. http://www.opengl.org/about/news/siggraph2004/bof2004_intro_web.pdf

[from the document]

Why “2.0”, anyway?
(…)

  • Opportunity for new T-shirts!
    slaps in forehead NOW this makes sense!

Still backwards-compatible with 1.x
So was the original “2.0”.

Minor clarifications to the Shading Language spec (v. 1.10) Late agreement to change the GLSL shader “object model” to match the rest of OpenGL (using Gen/Delete/Is and uint names instead of handle).
I still think it was bad that ARB killed the original 2.0, but I give mu thumbs up here. I couldn’t understand why ARB approved the new object model (for GLSL stuff) and at the sametime scrapped all essential extensions that would use it, and thus justify the whole object model change. Add to this the superbuffers proposals which looked like 50/50 mix of the 2.0 and 1.x design, and in result the OGL seemed to be getting Frankenstein appearance more then ever. Nice to see signs of consistence back again.

Originally posted by Corrail:
[quote]Originally posted by Cab:
It seems that we will have an ARB floating point texture extension in a month, a simpler render to texture extension, etc.
This would be really great!!!
[/QUOTE]“great” would be 2 years ago. Now it’s just “sigh, fine” IMO.

I couldn’t understand why ARB approved the new object model (for GLSL stuff) and at the sametime scrapped all essential extensions that would use it, and thus justify the whole object model change.
Which, of course, explains why they just changed the object model back when they adopted glslang into the core, thus breaking quite abit of already existing glslang code.

GL 2.0 would have been a perfect opportunity to make everything use the handle mechanism. But no, they decided to stick with integers, and force silly management stuff onto the driver developers.

Many drafts of “uber buffers”. In the end, felt to be too far beyond current hardware capabilities.
In short: they couldn’t agree on anything.

Reset to simpler “render target” approach
Which we should have had a good year or two ago. Come on, why didn’t anybody think of EXT_render_target last year, or 2 years ago? It’s a dirt-simple extension, and all transfering control of it to the ARB is doing is delaying its existence as part of useful code.

Originally posted by MZ:
“great” would be 2 years ago. Now it’s just “sigh, fine” IMO.
Yes, I agree. But that doesn’t change the current state: ugly p-buffers. Altough this extension should be released one or two years ago this extension would be great now too.

By the way, does anyone have an idea what the “shading language meta file” include?

I am also curious to see what the ARB has in mind for the shader meta-format. If it’s another .fx-style list of passes, models, and materials, I would almost say it’s outside the scope of OpenGL.

It would be the equivalent of adding an ARB specification for a scenegraph or model format, certainly neat, but whatever bloated and feature-rich solution the ARB comes up with, chances are it will be easier for developers to specify their own little text files.

Just my two cents worth…

It strikes me that the “metafile” thing has its place – in GLU.

That way it’s there for those that want to use it, but doesn’t affect the “scope” of the GL.

Originally posted by ar2k:
[b]…It would be the equivalent of adding an ARB specification for a scenegraph or model format, certainly neat, but whatever bloated and feature-rich solution the ARB comes up with, chances are it will be easier for developers to specify their own little text files.

Just my two cents worth…[/b]
Agreed, I also feel like it’s outside of OpenGL scope, could see it in GLU however.