For everyone interested in learning OpenGL I'd recommend learning WebGL. It's the same graphics API, except that it runs in the browser so you don't need to mess with compilers and linkers and your scenes will work on all platforms. If you think it's fun you can then move to native OpenGL later (if you must – WebGL is good enough for surprisingly many things).
Also, I've come into many situations where webgl doesn't work in some particular situations, would it be a a combination of OS, webgl driver support or web browser.
I guess it should work and will as time passes, but as long as there is nothing else than javascript, I won't bother.
As someone that's written C++ for 15 years and C for 30 I hated JS too. Now after several years of JS I can't stand C++. Things that I can do in 3 lines of JS take 100-300 in C++
It's hard for me to think of a language that doesn't feel preferable to C++. C included. JS is still a really poor competitor in this space; almost everything I've used scores higher in my personal ranking - even VB6.
Mmh it's not so good good because browser who don't support that mode won't execute js the same way, so it's breaking.
If there is a need to break compatibility, I think it's an opportunity to provide access to a standardized browser vm or a new language. If google or mozilla do and attract developers, it would be a nice thing: make it so it can attract users to use firefox, while making it open so that apple and google can implement it.
It could happen if it could be included inside mozilla nightly, but unless there is wide acceptance developers might not choose it, so it's an eternal chicken egg problem.
To me, there are sane alternative to js that are compatible with all platforms, only that it's very cumbersome. Js is just easy to deploy, but that's its only advantage. I don't think I should use a shitty language just because OS developers refuse to deliver and support better tools. I don't think I should give up all the existing C and C++ libs because they don't work anymore on android/iOS.
> Mmh it's not so good good because browser who don't support that mode won't execute js the same way, so it's breaking.
There are some differences, yes. Writing code in the subset that works in both non-strict and strict modes is easy, however. And old browsers aren't a big problem.
Strongly agreed, and I'd add another benefit that I've found to be even more important: nearly everything that comes back when you search for "WebGL" will be relevant. That's entirely different from the situation when you look for OpenGL information: old OpenGL is very different from newer OpenGL which is pretty similar—though not entirely—to OpenGL ES 2.x (which is quite different from OpenGL ES 1.x), etc.
I started a prototype of a guide like this. I think it's probably the best way to teach OpenGL. Besides not messing with compilers and linkers (a huge advantage) you can have interactive demos right there in the guide, which is pretty cool. As well as explanatory demos like http://acko.net/files/fullfrontal/fullfrontal/webglmath/onli... In addition, I think WebGL will raise exceptions on errors, unlike C OpenGL, which is really really nice when you're trying to learn it.
One thing that I think is missing is having a code description of how things work. If you can present shaders as for loops over the input vertices or pixels, it might be more clear than just a bunch of diagrams. I had to write my own rasterizer in order to get a decent idea of how it worked.
Another that might be missing is the state possessed by OpenGL. The linked guide calls it a state machine but there's no state machine diagram or anything. Just having a list of the most common OpenGL state and a way to print it all out might be nice. I've had a lot of bugs (like not setting glViewport or having the wrong GL_RENDERBUFFER bound) that would probably be easier if I could see the current OpenGL state or even know that GL_RENDERBUFFER wasn't changed by GL_FRAMEBUFFER.
I've actually been writing a guide to WebGL via Gamma (a bit like React.js for WebGL, written in ClojureScript), and was able to take it a bit further.
* Live editing tutorials with the code directly embedded [0]
* Hot-reloadable WebGL code [1]
* Hot-reloadable WebGL code in multiple browsers [2]
* Inspector tools that are able to detect common errors and explain them [3]
The live-editing aspects really helps recover from black-screen-syndrome much faster, and keeps the experience from being more overwhelming than it has to be.
Unfortunately, almost everything that's written for WebGL on the web right now is actually written for Three.js. Three.js is great, but it does make it a bit frustrating trying to understand the basic WebGL state/code underneath when first learning.
I'm up to 32 lessons so far (e.g. textures, specular maps, camera, WebSockets, WebRTC/udp), and definitely hoping to be able to explore more and more holistic topics. If anyone has suggestions for topics they'd like to see covered, happy to take a look!
That's the plan. Gamma's still in super-high flux as I use it for a production-grade app (along with Om/Datomic, some fun tech). Once things settle down, I expect ClojureScript should be pretty close to self-hosted, so everyone should be able to visit the page, see the code, edit it live, and see it output/working immediately, all in the browser.
It is taught using three.js which is a very very easy to use wrapper library around webgl. If you don't have a graphics background you can still make very pretty things with it.
I recently put together Glitter (https://github.com/Polytonic/Glitter) which is a basic OpenGL boilerplate that runs on every platform. The only dependency is cmake, so getting started with OpenGL is as simple as generating an IDE project file or makefile and pressing play. No messing with compilers or linkers required. :)
I've spent a significant amount of time learning both OpenGL and WebGL, and I have to say, there is significant value in starting with OpenGL first. For starters, the GLSL compiler is much friendlier. There are also merits to understanding the state-machine from a "C" perspective.
This is definitely the best way to start. Getting a windowing library operating properly is a struggle in itself, and can be very demotivating. OpenGL is complicated enough without dealing with such thing. When I was researching it a lot back in 2010/2011, the answers were "don't use GLUT or SDL" since they were both not being updated at the time, so then the question was "what do I use?" and there didn't seem to be a good answer in C++ space. It looks like SDL is being updated again now though.
> Getting a windowing library operating properly is a struggle in itself,
What's so difficult about linking against a lib/including some headers and pasting the code snippets? The only part I really had problems with was figuring out that I needed glew, and why it wouldn't work on osx with the core profile .
Because most of the code snippets available online that one might paste are wrong and if you don't learn the fundamentals, you won't understand how and why they are wrong. But if you do understand the fundamentals, you won't need to paste a snippet.
I haven't looked recently, but at one point I did a survey of rotation matrix examples online and the vast majority of them were wrong, with subtle typographic errors in a sign on a term here, or a cosine swapped with a sine operation there. I've seen "game rendering loop"s that leak memory every frame (in C++) or allocate every frame and eventually cause GC (Java, C#, JavaScript). I've seen OpenGL initialization snippets that didn't account for pixel density of the display properly and ended up rendering at too low of a resolution.
No, don't paste snippets of anything you find online. It's likely to be really bad.
Because that's another huge framework in itself, that you would have to learn. When you are going to learn one thing, you don't make a detour learning another thing for a few months.
Pretty good is not good enough for production type stuff yet. Did some testing with an older Mac Mini (Core2Duo) running OS X 10.6.8 and some of my simple WebGL tests would hard crash the operating system.
WebGL is still far away from widespread distribution, I hope it will get there in couple of years.
I've read many parts of this tutorial, it's very good and explain thoroughly how opengl works. It's both simple, short, doesn't go into too much detail, but provide the essentials you need to know.
The most attractive aspect of this website is that it's oriented towards opengl 3.3 core profile, so it's really up to date, but now I admit I don't understand how vulkan will change that.
The thing about NeHe that people seem to forget is that it was always complete garbage. It was just the "only" OpenGL tutorial that included readily copy-pasta'able code. Didn't matter that code was a smorgasboard of bad habits.
I think that applies to C code in general unfortunately, it took me a while to realize that C could actually be a very nice language to write in, but only after reading some of the source of Plan9, OpenBSD, redis, etc. Code you find in C tutorials is usually horrible.
I had a quick look, and the only visual studio specific part I could see was building GLEW/GLFW from source, which is done using cmake. you just replace the setup of the headers/libs/paths with whatever platform you're using.
Yes! This looks nice. I tried learning OpenGL some time ago but the resources were so mixed up and low quality that I gave up after few attempts. I might try now again because I remember it was really fun to make my own code generated 3d cube world (:
