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 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Suggestions for the next release of OpenGL

  1. #1
    Junior Member Newbie
    Join Date
    May 2013
    Posts
    17

    Suggestions for the next release of OpenGL

    My suggestion would be to revamp the site and make it look at little bit more up to date and professional. Update the wiki, rid it of the grammar mistakes and have official Khronos approved examples to get beginners started. After all, this is one of the very few low level APIs. Something as important as this deserves better documentation and website. Think MSDN for microsoft developers.

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    First of all, what the hell does all that have to do with the OpenGL specification? The site doesn't have anything to do with it, neither does the wiki. And BTW, a wiki lives from contributions - so if you find stuff that is incorrect, by all means, correct it. This goes for content and grammar. BTW, although hosted and, from a technical standpoint, maintained by the same people as OpenGL.org, articles are mostly written by us - the members of the OpenGL discussion board and not members of the ARB, while the MSDN is mostly Microsoft stuff, garnished with some user contributions here and there. Other than that, the API reference pages are mostly ok to work with. However, the API ref in the wiki is more up to date and more frequently checked for bugs - plus, you can edit the contents yourself if you spot an error. Anyway, the primary source for more experienced devs is the GL spec. So, all you ask for is already there, it's just presented differently.

    Please refrain from posting suggestions in this sub-forum that have nothing to do with the OpenGL specification. If and only if you can think of a cool new feature that will actually improve OpenGL in some way, go ahead.

  3. #3
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Adding to what thokra said, it would also be more helpful if you made specific suggestions. Simply saying "do better" doesn't help anyone.

    For example, you say that the site should look "more up to date and professional". What does that mean? What exactly is not up-to-date about it? What looks unprofessional?

    "Update the wiki" is similarly unhelpful. I'm pretty much the principle maintainer of the wiki. What exactly is not "up-to-date"? Certainly, there are some pages that could use help, but the wiki is pretty comprehensive at present.

    And, at the "risk" of being immodest, I would say that it's probably the most up-to-date collection of documentation on modern OpenGL available on the Internet. Oh sure, there are dozens of "how to draw a triangle" tutorials on the Internet. Every tutorial has "my first texture" and other crap.

    But do any of them really explain how textures work, with detailed information about how their storage is structured and created? I haven't seen any online materials that go into detail on what fragment shaders actually do, with all of the fragment shader-specific options for them laid out in one page. I have yet to find any in-depth discussion of image load/store that addresses the important topic of the memory model for accessing that data. Can you point to a better resource for learning about how interface blocks work? I can keep going with that, but I think you get my point.

    If there's one thing I've learned about making things better in the GL community is this: complaining about it will never help. The Khronos group is not a well-funded organization; they spend money where they need it most. And hiring someone to write example code or maintain the Wiki or whatever is just not something they have the budget to do. They can't even put together a conformance test for desktop OpenGL yet.

    So if you see a deficiency in some way, then you have two choices: take the time to improve the situation or accept that it's not getting better. If you want to be part of the solution, the Internet is there, waiting for you to make the situation better. Contribute to a project, add stuff to the wiki, direct people to good learning materials, whatever you have the time and inclination for. If you don't want to or can't, that's fine too. But general complaints like this aren't helping anyone.

  4. #4
    Junior Member Newbie
    Join Date
    Jun 2013
    Posts
    3
    Suggestion in form of a question.

    Will Vertex Puller ever be programmable?
    It feels to me, that the possibility to implement custom indexing scheme for vertex arrays would be a very very nice feature.

  5. #5
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    First, this is not the miscellaneous suggestions thread. You're not helping this thread by adding more requests to it.

    Second, you already have the tools via buffer textures, image load/store, and shader storage buffers to acquire vertex data however you want in your vertex shader.

  6. #6
    Junior Member Newbie
    Join Date
    Jun 2013
    Posts
    3
    Same applies to you: "You're not helping this thread by adding more requests to it"

    If you ever read the OpenGL specs, you'd know that all these hidden details you are looking for are not part of the standard and left to hardware manufactures.

  7. #7
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Quote Originally Posted by dr.duban View Post
    Same applies to you: "You're not helping this thread by adding more requests to it"

    If you ever read the OpenGL specs, you'd know that all these hidden details you are looking for are not part of the standard and left to hardware manufactures.
    ... who are you talking to here? I didn't mention any "hidden details," nor am I looking for any. Neither is anyone else in this thread. Buffer textures, image load/store, and shader storage buffers are not hidden, and they are all very much "part of the standard". None of them are "left to hardware manufacturers". And any of these allow you to have "programmable" "Vertex Pulling".

    So what exactly are you talking about?

    As to the first part, my point is that you shouldn't be adding suggestions that have nothing to with the topic at hand. Which isn't programmable vertex reading. If you have a new suggestion to make, make it in its own thread.

  8. #8
    Junior Member Newbie
    Join Date
    Jun 2013
    Posts
    3
    I was talking about server side image loads and stores/texture management including their structure and allocation.

    As for the first, I agree with thokra: the topic has nothing in common with the first post. And it is slowly getting to me that favor is given to the first post rather than the topic.

  9. #9
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Quote Originally Posted by dr.duban View Post
    I was talking about server side image loads and stores/texture management including their structure and allocation.
    What does that meant to mean? Buffers are buffers, no matter they are accessed as vertex buffers, texture buffers, image buffers, or shader storage buffers.
    Everything is server side, including vertex fetches, texture buffer fetches, shader storage buffer reads, etc.

    What you say doesn't make any sense.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  10. #10
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    Quote Originally Posted by dr.duban
    And it is slowly getting to me that favor is given to the first post rather than the topic.
    Dude ... the title of the thread is cleverly chosen to be the same as the title of the sub-forum it lives in. By your logic, your suggestion would have been welcomed. The point is: make a separate thread - one thread per suggestions.

    On the matter of claiming someone has not "ever read the OpenGL specs", I suggest you at least try to muster up the decency to inform yourself properly before arguing false claims. You don't help yourself, especially if you're trying to convince fellow board members of a new, awesome idea to put in the spec.

Posting Permissions

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