Now that Vulkan has taken on the role of low-level/high-performance API, perhaps it's time to make OpenGL easier to set up? With GL 3.x they greatly increased the amount of code required to render a single triangle - and not everyone actually wants that much flexibility, at least not all the time. The standard directional lighting shader is fine for a lot of scientific/engineering visualisations, for instance.
Another thought is that perhaps GL could become a library written in Vulkan, rather than being a separate interface.
"Another thought is that perhaps GL could become a library written in Vulkan, rather than being a separate interface." That would be the natural way for things to flow, in my opinion. Unless there are some hardware issues to prevent it, like a significant enough portion of hardware not supporting Vulkan.
"Now that Vulkan has taken on the role of low-level/high-performance API, perhaps it's time to make OpenGL easier to set up?"
There are plenty of libraries that allow you to choose the level of abstraction you want. If all you want to do is render a triangle without using GL buffers and shaders, SFML or SDL are perfect. If you want to eschew the use of third party libs, there's nothing stopping you from using the compatibility profile and just doing glBegin(GL_TRIANGLES)...glEnd().
Well, right now I essentially am using the compatibility profile since I've stuck with GL 1.x/2.x for my programs so far.
What I'd *like* to see is GL becoming a standard higher-level interface (possibly stacked on top of Vulkan), which gets rid of the clunkiest stuff like glBegin/glEnd pairs, yet provides the user with sensible default settings, like default shaders and default vertex data structures, so a beginner (or anyone really) can get going quickly and customise later.
At the moment GL 3.x and above are sufficiently opaque to discourage a lot of newcomers to graphics programming, which I think is an important consideration for the whole future of the industry.
As for me, I understand what GL 3.x does and I could upgrade my code, but I haven't bothered because it's not worth the time investment. 3.x seemed like an abortive attempt to do what Vulkan has now done successfully, so I have difficulty seeing the point in its approach.
I'm confused, I thought Vulcan is the next version of ES for Android. not to mention that it already support OES 3.1 hardware level. How the two are gonna coexist? is Vulcan just intended as ultra fast API for performance apps (without the new features), while ES 3.1 fill the feature gaps like ASTC and whatnot? Any who, according to Android Dashboard OpenGL ES 3.0 is still less than 40% and it was announced exactly three years ago. so by the current pace Google updates Android plus H/S fragmentation by 2018/19 we'll have less than half the devices use ES 3.2 and probably a critical mass still using ES 2.0. I guess us developers should just continue brainstorming hacks to decouple alpha maps from the rest of RGB texture or just ditch Android altogether, horrible platform to develop on, 50% iDevices support Metal already.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
5 Comments
Back to Article
stephenbrooks - Monday, August 10, 2015 - link
Now that Vulkan has taken on the role of low-level/high-performance API, perhaps it's time to make OpenGL easier to set up? With GL 3.x they greatly increased the amount of code required to render a single triangle - and not everyone actually wants that much flexibility, at least not all the time. The standard directional lighting shader is fine for a lot of scientific/engineering visualisations, for instance.Another thought is that perhaps GL could become a library written in Vulkan, rather than being a separate interface.
AndrewJacksonZA - Tuesday, August 11, 2015 - link
"Another thought is that perhaps GL could become a library written in Vulkan, rather than being a separate interface."That would be the natural way for things to flow, in my opinion. Unless there are some hardware issues to prevent it, like a significant enough portion of hardware not supporting Vulkan.
Brianmj - Tuesday, August 11, 2015 - link
"Now that Vulkan has taken on the role of low-level/high-performance API, perhaps it's time to make OpenGL easier to set up?"There are plenty of libraries that allow you to choose the level of abstraction you want. If all you want to do is render a triangle without using GL buffers and shaders, SFML or SDL are perfect. If you want to eschew the use of third party libs, there's nothing stopping you from using the compatibility profile and just doing glBegin(GL_TRIANGLES)...glEnd().
stephenbrooks - Tuesday, August 11, 2015 - link
Well, right now I essentially am using the compatibility profile since I've stuck with GL 1.x/2.x for my programs so far.What I'd *like* to see is GL becoming a standard higher-level interface (possibly stacked on top of Vulkan), which gets rid of the clunkiest stuff like glBegin/glEnd pairs, yet provides the user with sensible default settings, like default shaders and default vertex data structures, so a beginner (or anyone really) can get going quickly and customise later.
At the moment GL 3.x and above are sufficiently opaque to discourage a lot of newcomers to graphics programming, which I think is an important consideration for the whole future of the industry.
As for me, I understand what GL 3.x does and I could upgrade my code, but I haven't bothered because it's not worth the time investment. 3.x seemed like an abortive attempt to do what Vulkan has now done successfully, so I have difficulty seeing the point in its approach.
xCyborg - Wednesday, August 12, 2015 - link
I'm confused, I thought Vulcan is the next version of ES for Android. not to mention that it already support OES 3.1 hardware level. How the two are gonna coexist? is Vulcan just intended as ultra fast API for performance apps (without the new features), while ES 3.1 fill the feature gaps like ASTC and whatnot?Any who, according to Android Dashboard OpenGL ES 3.0 is still less than 40% and it was announced exactly three years ago. so by the current pace Google updates Android plus H/S fragmentation by 2018/19 we'll have less than half the devices use ES 3.2 and probably a critical mass still using ES 2.0.
I guess us developers should just continue brainstorming hacks to decouple alpha maps from the rest of RGB texture or just ditch Android altogether, horrible platform to develop on, 50% iDevices support Metal already.