7 ms·

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 mes

by bla2 11y ago

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

novaleaf 11y ago
is this tutorial applicable to WebGL? if not, do you have another tutorial recommendation?
chejazi 11y ago
WebGL has pretty good browser support - most recently Safari on iOS 8. http://caniuse.com/#feat=webgl http://caniuse.com/#feat=webgl
- Narishma 11y ago
  Still doesn't work on my laptop in Firefox, and only works on Windows in Chrome.
  - jahewson 11y ago
    Maybe your graphics driver is blacklisted? https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drive...
- inDigiNeous 11y ago
  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.
glhaynes 11y ago
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.
rawnlq 11y ago
For people looking for resources to get started, I recently went through: https://www.udacity.com/course/interactive-3d-graphics--cs291 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.
Klinky 11y ago
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.
- santaclaus 11y ago
  Why not Qt5?
  - vetinari 11y ago
    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.
- slavik81 11y ago
  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.
  - bjwbell 11y ago
    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.
- maccard 11y ago
  > 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 .
nulltype 11y ago
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/online.html 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.
- sgrove 11y ago
  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 https://www.youtube.com/watch?v=Q5vh1Xj-xM4 [1] https://www.youtube.com/watch?v=rboZswsKwaw https://www.youtube.com/watch?v=rboZswsKwaw [2] https://www.youtube.com/watch?v=mKsL9ZRfXWw https://www.youtube.com/watch?v=mKsL9ZRfXWw [3] https://www.youtube.com/watch?v=Gbpe3hEYKgg https://www.youtube.com/watch?v=Gbpe3hEYKgg
jokoon 11y ago
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.
- greggman 11y ago
  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 http://twgljs.org
  - kevingadd 11y ago
    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.
- TazeTSchnitzel 11y ago
  > If only it was not awful javascript. JavaScript, for all its flaws, is far less painful to use than C for this.
  - jokoon 11y ago
    The javascript flaws make it painful enough for me.
    - TazeTSchnitzel 11y ago
      Have you tried strict mode?
      - jokoon 11y ago
        no, what is it ?
Polytonic 11y ago
I recently put together Glitter (https://github.com/Polytonic/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.

by bla2 11y ago

novaleaf 11y ago

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

chejazi 11y ago

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

Narishma 11y ago
Still doesn't work on my laptop in Firefox, and only works on Windows in Chrome.
- jahewson 11y ago
  Maybe your graphics driver is blacklisted? https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drive...
inDigiNeous 11y ago
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.

glhaynes 11y ago

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.

rawnlq 11y ago

For people looking for resources to get started, I recently went through: https://www.udacity.com/course/interactive-3d-graphics--cs291 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.

Klinky 11y ago

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.

santaclaus 11y ago
Why not Qt5?
- vetinari 11y ago
  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.
slavik81 11y ago
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.
- bjwbell 11y ago
  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.
maccard 11y ago
> 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 .

nulltype 11y ago

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/online.html 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.

sgrove 11y ago
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 https://www.youtube.com/watch?v=Q5vh1Xj-xM4 [1] https://www.youtube.com/watch?v=rboZswsKwaw https://www.youtube.com/watch?v=rboZswsKwaw [2] https://www.youtube.com/watch?v=mKsL9ZRfXWw https://www.youtube.com/watch?v=mKsL9ZRfXWw [3] https://www.youtube.com/watch?v=Gbpe3hEYKgg https://www.youtube.com/watch?v=Gbpe3hEYKgg

jokoon 11y ago

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.

greggman 11y ago
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 http://twgljs.org
- kevingadd 11y ago
  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.
TazeTSchnitzel 11y ago
> If only it was not awful javascript. JavaScript, for all its flaws, is far less painful to use than C for this.
- jokoon 11y ago
  The javascript flaws make it painful enough for me.
  - TazeTSchnitzel 11y ago
    Have you tried strict mode?
    - jokoon 11y ago
      no, what is it ?

Polytonic 11y ago

I recently put together Glitter (https://github.com/Polytonic/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.