Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 5 of 173 FirstFirst ... 345671555105 ... LastLast
Results 41 to 50 of 1724

Thread: OpenGL 3 Updates

  1. #41
    Junior Member Newbie
    Join Date
    Oct 2007
    Posts
    8

    Re: OpenGL 3 Updates

    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!

  2. #42
    Junior Member Regular Contributor
    Join Date
    Jan 2005
    Posts
    182

    Re: OpenGL 3 Updates

    Quote Originally Posted by ector
    Quote Originally Posted by ZbuffeR
    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

  3. #43
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    353

    Re: OpenGL 3 Updates

    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.
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

  4. #44
    Member Regular Contributor
    Join Date
    Apr 2004
    Location
    UK
    Posts
    420

    Re: OpenGL 3 Updates

    Quote Originally Posted by praetor_alpha
    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.

  5. #45
    Senior Member OpenGL Pro sqrt[-1]'s Avatar
    Join Date
    Jun 2002
    Location
    Australia
    Posts
    1,000

    Re: OpenGL 3 Updates

    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.

  6. #46
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    353

    Re: OpenGL 3 Updates

    Quote Originally Posted by 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.
    Good point.

    Quote Originally Posted by sqrt[-1
    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
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

  7. #47
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: OpenGL 3 Updates

    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.
    GLIM - Immediate Mode Emulation for GL3

  8. #48
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293

    Re: OpenGL 3 Updates

    Quote Originally Posted by Jan
    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!

  9. #49
    Senior Member OpenGL Pro k_szczech's Avatar
    Join Date
    Feb 2006
    Location
    Poland
    Posts
    1,108

    Re: OpenGL 3 Updates

    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...

  10. #50
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: OpenGL 3 Updates

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •