Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iOS how hard is it to learn OpenGL ES
- Thread starter thekev
- Start date
- Sort by reaction score
Imagine the hardest thing you've ever learned. This is probably times harder (unless you thought of OpenCV, in which case that might be harder and you might be capable of doing this. IDK, I never got past the basics of either of them.)
What are you looking to do with it? You'll likely be better served by Unity (if you're looking to make a game) or Ogre 3D (if you're looking to do pretty much anything else 3D graphics related.)
Not really 3D and nothing to do with games. I want it to do 2D computation, so no normals or heavy trigonometric computation. It's mostly for future projects. May I ask if any specific thing made it difficult? It's difficult to view the most difficult thing ever as a point of reference. Is it syntactically complex? Do you have to deal with a lot of near metal issues that require an understanding of the underlying hardware? Is it more like an issue of approximating transcendental values to an accurate level of precision that makes it difficult? I don't have to deal with anything that would require various levels of nested coordinate systems or anything like that.
Also were you trying to learn it just to learn it?
I was looking to make a game using it. I spent weeks reading about its pipelines and whatnot and in the end I managed to make it render a spinning triangle with color. At that point I concluded that it was far, far too low level and began looking into other game engines that already existed. I was able to move quicker with Ogre - in the same time it had taken me to learn to animate a triangle, I was able to make a simple space shooter using it. I decided that was still too low level for as big a game as I want to make and have since been learning Unity. This seems about the right level for what I need - there's no need to write generic could-be-any-game code.
The API is large and complex. The environment has a lot of very fussy setup that isn't very well documented, and that fails with little feedback if you get anything wrong. The concepts are complex and difficult to grasp. The documentation is sparse and assumes a high level of understanding.
It makes heavy use of pointers, offset tables, buffers, etc.
I would agree with ArtOfWarfare. It is one of the most difficult APIs I have dealt with in my 30+years in the computer industry. I've got 3 apps in the app store now that use OpenGL, but it took intensive study and a great deal of determination to get up to speed with it. (Face Dancer is a live face morphing app for iOS devices. FractalWorks is a fractal rendering program for Macs that creates 3D fractal images using directional lighting, and offers stereoscopic projection. ScopeWorks is a kaleidoscope app for Mac that uses OpenGL to slice and dice still and video images and turn them into various types of animated and still kaleidoscopes.)
Those look amazing. Pointers and offset tables aren't scary. Poorly documented finicky apis are scary, because I like to know what I'm writing. Since I still feel the need to attempt this you have any suggestions where to start? What I want to do is probably not as complex as what you've done there. It's still extremely difficult when we're talking about OpenGL ES right? My reading suggests what I did know was out of date, given that scissor and alpha tests were apparently deprecated some time ago.
Just echoing what Duncan said about largely undocumented and failing without much info as to why. But I do want to add one thing.
I find it to be the most rewarding type of programming out there. You can churn out quite a lot of UIKit code without having to think about too much what you are doing. OpenGL code on the other hand you need to be in the presence. I wish I had more work coming in that required OpenGL, it keeps you on your toes.
I find it to be the most rewarding type of programming out there. You can churn out quite a lot of UIKit code without having to think about too much what you are doing. OpenGL code on the other hand you need to be in the presence. I wish I had more work coming in that required OpenGL, it keeps you on your toes.
Feel the fear and do it anyway 
I use it for games but you can do anything you like - my buddy uses GPUs to process database records!
I use it for games but you can do anything you like - my buddy uses GPUs to process database records!
Feel the fear and do it anyway
I use it for games but you can do anything you like - my buddy uses GPUs to process database records!
Ugh. With shaders? That's awful. I wish Apple would release OpenCL for iOS. That is a much cleaner way to do GPGPU than trying to force OpenGL to do general computing.
Those are the aspects that are likely to be annoying. I like documentation that imparts some understanding of how the framework is constructed. It helps me know what to avoid if bugs are not entirely obvious.
Feel the fear and do it anyway
I use it for games but you can do anything you like - my buddy uses GPUs to process database records!
I know GLSL doesn't look that scary. The math doesn't look that scary. It seems like I'll have to reach something non-trivial before I'll be able to fully appreciate the warnings.
They should have done so by now. The hardware can make use of it, and several graphics apps seem to use OpenGL ES for computation in spite of its flaws. I don't know why Apple has lagged on it.
If memory serves scissor tests are part of the fixed pipeline in desktop OpenGL. OpenGL ES 2.0 is purely shader-based.
I would suggest simply creating an OpenGL template app and looking at what it does. Then look around for open source sample apps that use GLKit.
GLKit makes life much easier than setting up OpenGL layers on your views yourself, which is what I've had to do for our our OpenGL app. (We started it before iOS 5 came out) GLKit also provides lots of useful extras like matrix math utilities, standard lighting functions, etc - stuff that you would have to do yourself if you were using "plain" OpenGL ES 2.0.
Thank you. I will look at GLKit. You mentioned shader computation just a bit higher in the thread. Did you do that with any of the apps? I mean did the results of the shaders have a side effect beyond drawing something to screen?
I am in the process of learning Open GL (with C++) and don't find it much harder then XNA, which is considered to one of the most easy to learn graphical APIs out there. Already knowing XNA though, I already know a lot of the concepts, but with Open GL it really helps if you use a mathematical library in conjunction with the Open GL specification, since it handles all the matrix calculations for you. Since I haven't used a game engine before, I can not say that I recommend one, however, make sure to hype yourself and friend up about the project, and keep chatting about it and coming up with new ideas. That way you will never lose interest
I do OpenGL dev for a living. It took me 5+ years to get a solid grasp on everything. If you are really interested in learning go learn WebGL it's basically OpenGL ES 2.0.
Javascript WebGL is much more forgiving then c/c++ OpenGL and there is a plethora of examples documentation for WebGL. It's easy to run right in your browser and makes prototyping etc. very simple.
Once you understand the concepts of WebGL they translate to any other system quite well.
Javascript WebGL is much more forgiving then c/c++ OpenGL and there is a plethora of examples documentation for WebGL. It's easy to run right in your browser and makes prototyping etc. very simple.
Once you understand the concepts of WebGL they translate to any other system quite well.
That is quite a long time. OpenGL ES hit version 3.0 if I'm not mistaken. May I ask what was most difficult to learn? Was it an issue of documentation? bugs? figuring out reliable practices? Are debuggers of much use there? It's interesting to know what was difficult about it, even if the answer isn't precise due to encompassing a long list. I wanted the ability to write some amount of low level code, so I'll probably have to learn this at some point. Also scripted languages always seem to be more forgiving
.That is quite a long time. OpenGL ES hit version 3.0 if I'm not mistaken. May I ask what was most difficult to learn? Was it an issue of documentation? bugs? figuring out reliable practices? Are debuggers of much use there? It's interesting to know what was difficult about it, even if the answer isn't precise due to encompassing a long list. I wanted the ability to write some amount of low level code, so I'll probably have to learn this at some point. Also scripted languages always seem to be more forgiving
There was no one specific thing that was difficult. It just requires knowledge in a few key areas and experience of knowing where you might have made a mistake. The first major area is linear algebra. Having a solid grasp is fundamental because at the end of the day graphics programming is all math. I also think some knowledge in parallel programming is helpful.
In my opinion the documentation is mediocre at best. Debugging can be a pain, but the tools that Apple has created for OpenGL ES performance and testing are without a doubt some of the best I have ever used.
There are tons of tiny options, all of which must be set correctly to do the simplest thing, the correct setting of which is not obvious from initial reading of the documentation.
Even a basic simple game object, which can consist of thousands of triangles specifications and millions of texture pixels, may not be that simple to create or specify without knowledge of how to use complicated software tools.
Camera positioning may still be an art form.
I took a semester of linear algebra in college, and I recently picked up a slightly more advanced book to review. I don't have trouble with math. I might look for a reference on parallel programming, because anything gpu driven is way more than a few threads.
I'm not making game objects, but I do understand the fundamentals of a lot of graphics structures. As you point out, it reads in vertices and their order along with texture data, uv coordinates, and normals. The available documentation isn't difficult to understand, but the potential limitations of it worry me. Bad or sparse documentation sometimes leads to misconceptions that only become problematic upon reaching something of sufficient complexity.