OpenGL 3 Updates

[Toji]

I don't have much to say about the arguments over alphatesting/texture formats/etc (though I will say that I think glVertex3f() and crew need to go away. No point in having them anymore) but I would like to give a big thank-you to the guys at Khronos for not leaving us in the dark any longer! Even if it has been delayed it's great to know that it's only because you're making it better!

[PkK]

Indeed, S3TC is a strange requirement. Who is actually using it by the way ? I am sincere.

Every major game out there for the last 5 years. The performance increase it offers over uncompressed textures is pretty dramatic, and as a bonus consumes less memory. The slight quality loss is very often worth it.

If you want the performance increase and save graphics memory you can use a generic compressed format and let the card handle the details. No need to explicitly require S3TC support.
Recent research has created compression schemes which give better quality than S3TC, but don't need more memory (ETC2 is an example).

Philipp

[Stephen A]

S3TC *is* a strange requirement, because as was said previously as the format is patented. To me, the decision sounds more like politics getting in the way. Mesa3d will probably work around the issue by substituting S3TC with a different compression scheme behind the scenes.

As PkK said, the best solution would be to support compressed formats and let the driver choose the best implementation (S3TC, ETC2 etc), according to the hardware's capabilities.

[bobvodka]

Why is DOUBLE being dropped? We know that future hardware will be able to support it, regardless. Isn't OpenGL supposed to be a forward looking standard?

The problem with leaving double in however is that it looks like the hardware can do it, and right now afaik no hardware can (not even the G92 based chips and probably not the new AMD ones either when they appear) which puts us a good year away from it being useful and instead confusing matters for an API which is meant to be closer to how the hardware works.

Double will be back I'm sure, just not for a year at least, during which time we are due at least 2 more updates to GL (Long Peaks Reloaded and Mt. Evans), plenty of time to add it back in.

Will EXT framebuffer object be core?

FBO like functionality is at the core of GL3 for rendering.

[sqrt[-1]]

As PkK said, the best solution would be to support compressed formats and let the driver choose the best implementation (S3TC, ETC2 etc), according to the hardware's capabilities.

That would be a fatal choice. That would mean you would have have to ship your app with all textures uncompressed and compress at load/install time.

Do you have any idea how long it takes to do quality S3TC compression? On our current app it would take hours to do this. It is second only to shader pre-compiling. (but that is another discussion)

Also each compression scheme has different trade offs - you would have to specify stuff like "is this a color map?" "is this a normal map"? "is this a height map?" to enable the driver to select a appropriate compression format.

[Stephen A]

As PkK said, the best solution would be to support compressed formats and let the driver choose the best implementation (S3TC, ETC2 etc), according to the hardware's capabilities.

That would be a fatal choice. That would mean you would have have to ship your app with all textures uncompressed and compress at load/install time.

Good point.

Also each compression scheme has different trade offs - you would have to specify stuff like "is this a color map?" "is this a normal map"? "is this a height map?" to enable the driver to select a appropriate compression format.

I am not sure what you are trying to say. Decisions like selecting the correct format for normal maps, height maps, font textures etc are simply unavoidable.

Edit: Your name is breaking forum quotes

[Jan]

I like alpha-tests and already feared they might be removed. Good to know it will stay.


What i'd like to know more about is the "default state" as mentioned above. It said you can "render a simple polygon without specifying vertex-buffers...". I would like to know more about what the default-state will allow. E.g. is simple texturing (not multi-texturing) available, too? (i doubt it)

Also, i'd like to know everything about context-creation (multisampling, adaptive antialiasing, etc.) and how the "drawable" interacts with the window-system. Using FBOs all the time and then only "presenting" the result to the window-system is what i would like to do in the future.

And i'd like to know what general information one can query from the system. For example gfx-memory, vender, renderer and, of course, whether the extension-system has been modified.

A list, which current extension will be "core" in 3.0 would be nice. In general a "minimal-requirements" listing.


For the PR department:
I think for OpenGL 3 to get a bit more excitement, outside of these forums, it would be great, if there will be a new logo (maybe the old one, but revamped). It should be available in several formats and at low to very high resolutions, for people to use it on websites, in games (option-menus...) etc.

A small video featuring an animated OpenGL logo would be very cool, so that game-developers can play it at program-startup (like the nVidia, ATI, etc. logos).

This would allow people to show off, that they are using OpenGL 3 and thus it will be more present to the public.


Jan.

[Chris Lux]

Also, i'd like to know everything about context-creation (multisampling, adaptive antialiasing, etc.) and how the "drawable" interacts with the window-system. Using FBOs all the time and then only "presenting" the result to the window-system is what i would like to do in the future.

this too is what interests me the most. i also think that framebuffer creation and handling should be passed to the gl and only the result blitted onto the OS surface.

For the PR department:
I think for OpenGL 3 to get a bit more excitement, outside of these forums, it would be great, if there will be a new logo (maybe the old one, but revamped). It should be available in several formats and at low to very high resolutions, for people to use it on websites, in games (option-menus...) etc.

A small video featuring an animated OpenGL logo would be very cool, so that game-developers can play it at program-startup (like the nVidia, ATI, etc. logos).

This would allow people to show off, that they are using OpenGL 3 and thus it will be more present to the public.

great idea!

[k_szczech]

A small video featuring an animated OpenGL logo

Maybe we should start a contest for GL3 static and animated logo in a separate thread then?
Now let me think... Should we present OpenGL as something bright and futuristic (bright future?) or something dark and powerful...

[Korval]

What i'd like to know more about is the "default state" as mentioned above.

I don't think the whole "default state" thing exists to be usable. That is, you aren't expected to actually use it in any real application. It is there to make sure that the context is viable from GL startup.

The only piece of default state that you might find useful is the default framebuffer object.