The multiplicity of APIs demonstrates that the problem is hard. The needs of game developers pull the APIs in a specific direction. And these requirements must be addressed, because the games market is huge and pushes the envelope.
But other users may have different needs. OpenGL is used by games, but not just games. For example, at Taodyne, we use OpenGL for real-time 3D rendering of business information on glasses-free 3D screens. I can tell you that my pet peeves with OpenGL have nothing to do with what's being described in any of the articles.
Some of the top issues I face include 3D font rendering (way too many polygons), multi-view videos (e.g. tiled videos, which push texture size limites, or multi-stream videos, that bring a whole bag of threading issues), large numbers of large textures without the ability to manually optimise them (e.g. 12G of textures in one use case).
Heck, even the basic shader that combines 5, 8 or 9 views into one multiscopic layout for a lenticular display makes a laptop run hot for a mere HD display, and requires a rather beefy card if you want to have any bandwidth left for something else while driving a 4K display.
Many of these scenarios have to do with limitations of textures sizes, efficient ways to deal with complex shapes and huge polygon counts that you can't easily reduce, very specific problems with aliasing and smoothing when you deal with individual RGB subpixels, etc.
Of course, multiscopic displays are not exactly core business right now, so nobody cares that targeting them efficiently is next to impossible with current APIs.
Sure, the problem is hard. But so are most problems worth solving. That it's hard doesn't mean it's impossible or excuse bad solutions; Direct3D actually does an extremely good job at it, in fact.
If you've not used modern Direct3D, it's hard to concisely explain how much better it solves this problem than OpenGL. It's just a cleaner, more elegant, faster API (of course, I know this wasn't always the case, but we're talking about now).
Many of the "non-game" problems you mention really have nothing to do with the API and should be solved by third party libraries or the OS. Text rendering is not a GPU feature so don't expect a graphics API to treat it as such. The problems game developers find in a 3D API affect everyone, because at its core the 3D API is just our way of talking to the GPU.
The main complaints from "non-game" applications like this are either common to everyone (texture, render target limits), or application specific things that have absolutely nothing to do with the GPU (like text rendering) and have no place in a low level GPU API.
I know it would make your life easier if the API was more like a library with exactly your use cases already implemented, but that's simply not the role of a hardware API.
P.S. You probably shouldn't be using polygons for font rendering. Nobody does it this way in practice (except rare cases perhaps). But this is another discussion; feel free to message me privately and I'd be glad to provide more info on best practices.
It seems no one has mentioned the long peaks fiasco yet, which is an important part of understanding OpenGL history and the committee(s) in charge of the standard:
TL;DR: This is not the first time people are pissed at OpenGL. Last time when industry, developers, etc were sick and tired, around 2006-2007, and it was decided to do something about the API, an effort was initiated. Once the work was close to finishing, those who had seen the glimpse of this yet-to-be-released API were excited and were eagerly waiting for the release. Then the OpenGL committee vanished from the scene for a year or so, and when it re-appeared, it released the same old shitty API with a handful of function calls on top of that.
OpenGL might well be the "only truly cross-platform option", but it seems to me that, for games or mobile app development, getting stuff drawn on screen is only part of the problem. The rest is about doing so with the minimum use of cycles - either for better frame rates or better battery life. I can easily imagine that this is a classic 80/20 problem, with the 20% that takes 80% of the time being adequate ("butter smooth") performance.
So, given that the capabilities of the graphics hardware can vary a lot, how closely can a single, unified API like glnext approach optimal use of the hardware? And without the kinds of platform-specific code paths which are necessary under current OpenGL?
As long as there are multiple different GPUs around, there will always be a need for multiple code paths if you want to get good use of those GPUs, whether you use the same API or not.
All the whining and complaining makes me wondering how anyone was able to write something with OpenGL at all. This is fascinating because a great amount of people were actually able to write awesome Games and Applications with this API.
Look at the whole lot of mobile devices. I have no numbers to base this statement on but I would be bold enough to claim that OpenGL is thanks to the multiplatform ability by far the most successful graphics API out there. The set of devices that brings some or another form of OpenGL support outnumbers other graphics platforms. This alone is a huge accomplishment. Heck, even Minecraft was able to run on PowerPC systems until they pushed the java version supported[1].
But now I need to look at the link and have to admit that the criticism is still correct. The API is still pretty rough and could see some improvements. I know this myself, I also played around with OpenGL at some point. There is a lot of boilerplate code that needs to be written before you can start yourself with the real game. This was always the case. This is why we always had an engine, a framework to built on.
But to say that it all is a huge pile of shit is a little bit harsh …
Well by that logic, IE is a great browser because a lot of people got some amazing applications to run on it despite the fact that it was a nightmare to develop for...
OpenGL is almost like the IE of graphics development. You usually have to support it because it's so ubiquitous, but it constantly makes you want to tear out your hair because it does so many unexpected things and you have to memorize 5000 little caveats.
>The API is still pretty rough and could see some improvements. I know this myself, I also played around with OpenGL at some point. There is a lot of boilerplate code that needs to be written before you can start yourself with the real game.
OpenGL is a graphics library (and a rather low-level one too), so it has very little to do with games. It's only a specification for the wrapper above the gpu hardware.
Now they just have to create ONE single API, instead of forcing everyone to write multiple code paths to target the various flavours, extensions and drivers workarounds.
Specific graphics APIs only matters when graphics middleware is not an option.
Which OpenGL always requires. Since the standard leaves out how image/shader/texture/fonts/GUI/math are handled.
I think the commoditization of engines will be the second coming of the OpenGL 2.0 - 3.0 stagnation, if they don't improve on these areas.
OpenGL has support for: image/shader/texture/. The standard is quite clear about how these are handled. Anyway the trend (and demand from games programmers) is away from more features and towards a simplified and lower level API.
We need OpenGL as an alternative. What would Direct3D have been today without competition? But at the same time, GL is such a PITA to use directly that I don't bother without some middleware abstracting it away.
We're still waiting for WebGL 2.0 to be finished, nevermind widely implemented, and that's based on a GLES version released two years ago rather than one that doesn't exist yet. Don't hold your breath.
We all got messed up with the transition to OpenGL 4 and now we are gonna have another OpenGL? I don't see OpenGL getting out of this funk until the language you learn today will be useful tommrow. Perhaps, a new API is a step in the right direction but things are gonna hurt bad bad for years to come, especially when OEMs don't support the API.
That saying is wrong. Total rewrites for the wrong reasons are a bad idea. Total rewrites for the right reasons and with _a right team_ can be great (i.e. better abstractions, better understood domain requirements which can lead to a more simple, better codebase, enable features that were not feasible before, and so on). Succintly: If the theory of the existing system is still understood well enough and the team understands the domain requirements and has experience of implementing similar systems then a rewrite can be a great idea (ref Naur: 'Programming as theory building' on what the theory of the system means as a concept and what are it's implications). For specific businesses, total rewrites can be startup-level risky and should be done due to specific domain requirements. I think this is usually what is meant by the 'bad idea' meme. Joel Spolsky wrote of this at some point and gave example of Netscape's rewrite attempt. His advice of "don't do it" was highly context dependent, though.
When we discuss of creating a new industry standard API, we are not discussing of a single rewrite. There are a few typical patterns how these are done: 'fostering' an existing tech stack under a public institution or developing the API publicly.The public API development usually consists of two parts - agreeing on the theory of the API and implementing one or more reference implementations of the said API at the same time by member institutions.
I'm not sure how to gauge the risk of this public API development. There are costs for member organisations but usually they are insignificant when compared to the size of an institution. There is usually no established product whose feature development and support stagnates because of this but rather the development is done to facilitate potential future products and features. Of course, the API adoption can fail (ref. for example OpenVG) but that fait can befall any new development for any number of reasons.
[+] [-] c3d|11 years ago|reply
But other users may have different needs. OpenGL is used by games, but not just games. For example, at Taodyne, we use OpenGL for real-time 3D rendering of business information on glasses-free 3D screens. I can tell you that my pet peeves with OpenGL have nothing to do with what's being described in any of the articles.
Some of the top issues I face include 3D font rendering (way too many polygons), multi-view videos (e.g. tiled videos, which push texture size limites, or multi-stream videos, that bring a whole bag of threading issues), large numbers of large textures without the ability to manually optimise them (e.g. 12G of textures in one use case).
Heck, even the basic shader that combines 5, 8 or 9 views into one multiscopic layout for a lenticular display makes a laptop run hot for a mere HD display, and requires a rather beefy card if you want to have any bandwidth left for something else while driving a 4K display.
Many of these scenarios have to do with limitations of textures sizes, efficient ways to deal with complex shapes and huge polygon counts that you can't easily reduce, very specific problems with aliasing and smoothing when you deal with individual RGB subpixels, etc.
Of course, multiscopic displays are not exactly core business right now, so nobody cares that targeting them efficiently is next to impossible with current APIs.
[+] [-] electrograv|11 years ago|reply
If you've not used modern Direct3D, it's hard to concisely explain how much better it solves this problem than OpenGL. It's just a cleaner, more elegant, faster API (of course, I know this wasn't always the case, but we're talking about now).
Many of the "non-game" problems you mention really have nothing to do with the API and should be solved by third party libraries or the OS. Text rendering is not a GPU feature so don't expect a graphics API to treat it as such. The problems game developers find in a 3D API affect everyone, because at its core the 3D API is just our way of talking to the GPU.
The main complaints from "non-game" applications like this are either common to everyone (texture, render target limits), or application specific things that have absolutely nothing to do with the GPU (like text rendering) and have no place in a low level GPU API.
I know it would make your life easier if the API was more like a library with exactly your use cases already implemented, but that's simply not the role of a hardware API.
P.S. You probably shouldn't be using polygons for font rendering. Nobody does it this way in practice (except rare cases perhaps). But this is another discussion; feel free to message me privately and I'd be glad to provide more info on best practices.
[+] [-] fizixer|11 years ago|reply
http://en.wikipedia.org/wiki/OpenGL#Longs_Peak_and_OpenGL_3....
TL;DR: This is not the first time people are pissed at OpenGL. Last time when industry, developers, etc were sick and tired, around 2006-2007, and it was decided to do something about the API, an effort was initiated. Once the work was close to finishing, those who had seen the glimpse of this yet-to-be-released API were excited and were eagerly waiting for the release. Then the OpenGL committee vanished from the scene for a year or so, and when it re-appeared, it released the same old shitty API with a handful of function calls on top of that.
[+] [-] zerebubuth|11 years ago|reply
So, given that the capabilities of the graphics hardware can vary a lot, how closely can a single, unified API like glnext approach optimal use of the hardware? And without the kinds of platform-specific code paths which are necessary under current OpenGL?
[+] [-] darkmighty|11 years ago|reply
[+] [-] Narishma|11 years ago|reply
[+] [-] sheng|11 years ago|reply
Look at the whole lot of mobile devices. I have no numbers to base this statement on but I would be bold enough to claim that OpenGL is thanks to the multiplatform ability by far the most successful graphics API out there. The set of devices that brings some or another form of OpenGL support outnumbers other graphics platforms. This alone is a huge accomplishment. Heck, even Minecraft was able to run on PowerPC systems until they pushed the java version supported[1].
But now I need to look at the link and have to admit that the criticism is still correct. The API is still pretty rough and could see some improvements. I know this myself, I also played around with OpenGL at some point. There is a lot of boilerplate code that needs to be written before you can start yourself with the real game. This was always the case. This is why we always had an engine, a framework to built on.
But to say that it all is a huge pile of shit is a little bit harsh …
[1] https://help.mojang.com/customer/portal/articles/884921-mine...
[+] [-] overgard|11 years ago|reply
OpenGL is almost like the IE of graphics development. You usually have to support it because it's so ubiquitous, but it constantly makes you want to tear out your hair because it does so many unexpected things and you have to memorize 5000 little caveats.
[+] [-] ekr|11 years ago|reply
OpenGL is a graphics library (and a rather low-level one too), so it has very little to do with games. It's only a specification for the wrapper above the gpu hardware.
[+] [-] EpicEng|11 years ago|reply
[+] [-] pjmlp|11 years ago|reply
- Font loading
- Texture loading
- Shader loading
- Math library
- Geometry loading
- Meshes
- Integration with the OS UI
- Debugging capabilities
[+] [-] pjmlp|11 years ago|reply
Specific graphics APIs only matters when graphics middleware is not an option.
Which OpenGL always requires. Since the standard leaves out how image/shader/texture/fonts/GUI/math are handled.
I think the commoditization of engines will be the second coming of the OpenGL 2.0 - 3.0 stagnation, if they don't improve on these areas.
[+] [-] sjtrny|11 years ago|reply
[+] [-] maaaats|11 years ago|reply
[+] [-] pjmlp|11 years ago|reply
You don't get OpenGL on those.
[+] [-] bhouston|11 years ago|reply
[+] [-] jsheard|11 years ago|reply
[+] [-] fulafel|11 years ago|reply
[+] [-] frozenport|11 years ago|reply
[+] [-] shurcooL|11 years ago|reply
That way graphics code written once can run on OS X, Linux, Windows, browser (including iOS).
[+] [-] ndesaulniers|11 years ago|reply
[+] [-] illumen|11 years ago|reply
OpenGL is now available to more people than ever. By an exponential amount.
It is supported by all major browsers. From IE, to Firefox, to Chrome, to Android, to iOS, and more.
[+] [-] pjmlp|11 years ago|reply
On iOS, only starting with iOS 8
On Android, only with Firefox. OEM modified browsers don't do it. Chrome only enables it in specific devices.
[+] [-] BadassFractal|11 years ago|reply
[+] [-] fsloth|11 years ago|reply
When we discuss of creating a new industry standard API, we are not discussing of a single rewrite. There are a few typical patterns how these are done: 'fostering' an existing tech stack under a public institution or developing the API publicly.The public API development usually consists of two parts - agreeing on the theory of the API and implementing one or more reference implementations of the said API at the same time by member institutions.
I'm not sure how to gauge the risk of this public API development. There are costs for member organisations but usually they are insignificant when compared to the size of an institution. There is usually no established product whose feature development and support stagnates because of this but rather the development is done to facilitate potential future products and features. Of course, the API adoption can fail (ref. for example OpenVG) but that fait can befall any new development for any number of reasons.
[+] [-] Tuna-Fish|11 years ago|reply
[+] [-] tormeh|11 years ago|reply
[+] [-] Dylan16807|11 years ago|reply
[+] [-] z303|11 years ago|reply
[+] [-] IshKebab|11 years ago|reply
[+] [-] shmerl|11 years ago|reply
[+] [-] joliv|11 years ago|reply
[deleted]
[+] [-] Stolpe|11 years ago|reply
[+] [-] _random_|11 years ago|reply