Welcome to OpenGL | Hacker News Reader

Welcome to OpenGL

learnopengl.com

170 pointsfelipellrocha50 comments

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).

WebGL has pretty good browser support - most recently Safari on iOS 8. http://caniuse.com/#feat=webgl

Still doesn't work on my laptop in Firefox, and only works on Windows in Chrome.

Maybe your graphics driver is blacklisted? https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drive...

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.

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.

For people looking for resources to get started, I recently went through: https://www.udacity.com/course/interactive-3d-graphics--cs29....

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.

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.

Why not Qt5?

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.

I don't know about then, but now there's a lot of choices. FreeGLUT, SDL, GLFW, SFML...

It doesn't seem to matter all that much which one you choose, either.

Each of them has advantages and disadvantages.

Want to change the pointer using GLFW to one of the standard X11 pointers like the busy hour glass. Good luck, it can't be done as far as I know.

> 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.

> didn't account for pixel density of the display

You can easily tank the framerate if you account for this. At best, it should be an option in the video settings (if you're going to have them).

I situation you will be quite a lot more prepared to handle if you study the fundamentals and not just copy-pasta so-called "boilerplate" code.

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!

[0] https://www.youtube.com/watch?v=Q5vh1Xj-xM4

[1] https://www.youtube.com/watch?v=rboZswsKwaw

[2] https://www.youtube.com/watch?v=mKsL9ZRfXWw

[3] https://www.youtube.com/watch?v=Gbpe3hEYKgg

That's pretty amazing! Is the guide available as a webpage?

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.

If only it was not awful javascript.

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++

Just one example: http://twgljs.org

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.

> If only it was not awful javascript.

JavaScript, for all its flaws, is far less painful to use than C for this.

The javascript flaws make it painful enough for me.

Have you tried strict mode?

no, what is it ?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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.

There are many languages that compile to JavaScript (TypeScript, Dart, CoffeeScript, ...). You don't have to use JavaScript.

They all end with script

is this tutorial applicable to WebGL? if not, do you have another tutorial recommendation?

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.

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.

If I'm not mistaken, one can still use GLSL with Vulkan. So at least that part won't change much :)

Isn't the purpose of vulkan to have an API that can do both what opengl and opencl do ?

Yes, also better multithreading support and lower overhead (like AMD's Mantle which Vulkan is derived from).

I am going to dump a list of related resources that some people might find interesting:

https://en.wikibooks.org/wiki/OpenGL_Programming

https://open.gl/

http://www.videotutorialsrock.com/

http://www.lighthouse3d.com/tutorials/

http://www.lighthouse3d.com/tutorials/glsl-core-tutorial/#

https://web.archive.org/web/20150309070928/http://www.arcsyn...

http://www.learnopengles.com/

https://www.npmjs.com/package/shader-school

http://www.ntu.edu.sg/home/ehchua/programming/opengl/cg_basi...

http://nullprogram.com/blog/2015/06/06/

https://github.com/zuck/opengl-examples

https://github.com/progschj/OpenGL-Examples

https://github.com/g-truc/ogl-samples

https://github.com/apitrace/apitrace

https://en.wikipedia.org/wiki/Portal:Computer_graphics

http://webglfundamentals.org/

https://blog.inovex.de/android-graphics-pipeline-from-button...

http://www.tomdalling.com/blog/category/modern-opengl/

https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-...

http://docs.gl/ - Convenient reference for OpenGL APIs

Also, if you're interested in OpenGL with Go (and IMO Go is excellent to use with OpenGL), look at:

https://github.com/avelino/awesome-go#opengl

https://github.com/go-gl/examples

Also http://prideout.net/ has some very nice tutorials on advanced OpenGL topics (tesselation for example).

i guess Nehe is no longer a thing... :)

Good old Nehe O7

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.

Smorgasbord :)

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.

It would have been nice if it was not just for visual studio.

(I like the features of visual studio but i am never going back to windows.)

http://opengl-tutorial.org/ is pretty fantastic cross-platform modern OpenGL (GL3+) set of tutorials.

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 (:

Reply on news.ycombinator.com