4 ms·

> Using modern OpenGL to introduce all the standard concepts ... is much better than trying to teach them Vulkan ... and obviously better than teaching OpenGL A

> Using modern OpenGL to introduce all the standard concepts ... is much better than trying to teach them Vulkan ... and obviously better than teaching OpenGL API's that are decades old. I disagree on teaching old APIs. This is a pet peeve of mine, and I thought the author of a software rasterizer would agree with me. GPU APIs are some of the only APIs where you have to pay to upgrade. Sure, Vulkan has been "out" for 4 years. But I haven't bought any hardware that supports Vulkan. My last purchase was a used laptop with an iGPU. I buy hardware as a last resort when I absolutely need it, I especially don't buy hardware for the APIs when my old hardware has enough GFLOPS. I like that programming is a cheap hobby. I don't see the point in anteing up every few years. Per-core CPU power has plateaued, and I can add more storage to old systems easily. I just don't want to buy new hardware until I see the GPU space settle down for a few years. And when will that happen? Vulkan 2? Vulkan 3? How many more perfectly functional TFLOPS of GPU chips will be branded e-waste before the APIs are stable? I don't like the implication among some gamedevs that your programming skill depends on how much tribute you've paid to NVidia. I don't make bad games because I use GLES 2, I make bad games because I'm a bad gamedev. GLES 2 is a sweet spot in the tradeoff between compatibility and features. It dates to about 2007, so even a kid with a cheap used Android phone could theoretically write GLES 2 code for it. It doesn't have geometry shaders, but with vertex and fragment shaders you can still learn things like environment mapping, gamma-correct per-pixel lighting, hardware skinning, post-processing effects, etc. It just works, almost everywhere, and I don't see the point in writing off old hardware as trash before the end of its natural life.

vidarh 5y ago
I'm not so sure you disagree that much with the author as you think. The API's they're arguing against teaching are OpenGL 1 and 2. OpenGL 2.0 dates to 2004. OpenGL 1.0 dates to 1992. OpenGL 3.0 was released in 2008. OpenGL ES 2.0 was released in 2007. This rasteriser is modeled on OpenGL 3.x. So your recommendation and what they consider [the start of] "modern OpenGL" are about a year apart.
- flohofwoe 5y ago
  IMHO the OpenGL 1.x API style still has a place in many areas where rendering performance doesn't matter much. The matrix stack and begin/end functions are a very convenient way to get some 2D or 3D triangles and lines on screen (vs having to deal with buffers and shaders).
  - deleted 5y ago
    [deleted]
  - robertwinkler 5y ago
    I say the same thing about 3.3. See my comments with Jasper. I actually consider dealing with buffers and shaders to be far nicer and clearer than dealing with the old 1.x style API but I suppose for someone already intimately familiar with it that might not be the case. I understand if someone already has an existing codebase that uses the old stuff, but if you were starting a project from scratch it really isn't that hard to use 3.3+. And once you do it once, you never have to think about the setup process again, you already have your helper functions for loading shaders and other things. You don't even have to write your own, there are so many helper libraries out there, and things like GLM to give you every math related thing you'd ever need.
- robertwinkler 5y ago
  You're right. I consider 3.3 core and newer to be "Modern OpenGL". And the biggest reason I say 3.x is I know I will never support the geometry shader (or transform feedback though that came earlier).
pcwalton 5y ago
Vertex skinning is a pain in GLES 2 because of uniform size limits, since there are no UBOs. You can only have so many bones before you overflow those limits and then basically the only option I can see is to start packing your bone matrices into a texture (and since it's GLES 2 it has to be RGBA 8-bit), which is pretty awful. GLES 2 also has no unbounded loops in shaders, which makes some postprocessing effects like blurs a big pain to write (you need a separate shader for every blur radius). Granted, most drivers don't enforce this, since it's so obnoxious.
- flohofwoe 5y ago
  TBH, UBOs are quite useless in GLES3/WebGL2 (the guaranteed size is too small, and dynamically updating without sync issues isn't trivial because the under-the-hood details seems to be different in each GL implementation). If you really need to render lots of skinned characters, you'd use a single texture anyway for uploading the joint data of all characters (e.g. this demo renders hundreds of independently animated characters in a single drawcall in WebGL1): https://floooh.github.io/sokol-html5/ozz-skin-sapp.html https://floooh.github.io/sokol-html5/ozz-skin-sapp.html
- asiachick 5y ago
  Why is putting bone matrices in a texture awful? Seems great to me.
  - pcwalton 5y ago
    Because you're packing unbounded floating point values into an 8-bit RGBA unorm texture. Yes, it can be done. Dealing with the issues is annoying, though.

vidarh 5y ago

I'm not so sure you disagree that much with the author as you think. The API's they're arguing against teaching are OpenGL 1 and 2. OpenGL 2.0 dates to 2004. OpenGL 1.0 dates to 1992. OpenGL 3.0 was released in 2008. OpenGL ES 2.0 was released in 2007. This rasteriser is modeled on OpenGL 3.x. So your recommendation and what they consider [the start of] "modern OpenGL" are about a year apart.

flohofwoe 5y ago
IMHO the OpenGL 1.x API style still has a place in many areas where rendering performance doesn't matter much. The matrix stack and begin/end functions are a very convenient way to get some 2D or 3D triangles and lines on screen (vs having to deal with buffers and shaders).
- deleted 5y ago
  [deleted]
- robertwinkler 5y ago
  I say the same thing about 3.3. See my comments with Jasper. I actually consider dealing with buffers and shaders to be far nicer and clearer than dealing with the old 1.x style API but I suppose for someone already intimately familiar with it that might not be the case. I understand if someone already has an existing codebase that uses the old stuff, but if you were starting a project from scratch it really isn't that hard to use 3.3+. And once you do it once, you never have to think about the setup process again, you already have your helper functions for loading shaders and other things. You don't even have to write your own, there are so many helper libraries out there, and things like GLM to give you every math related thing you'd ever need.
robertwinkler 5y ago
You're right. I consider 3.3 core and newer to be "Modern OpenGL". And the biggest reason I say 3.x is I know I will never support the geometry shader (or transform feedback though that came earlier).

pcwalton 5y ago

Vertex skinning is a pain in GLES 2 because of uniform size limits, since there are no UBOs. You can only have so many bones before you overflow those limits and then basically the only option I can see is to start packing your bone matrices into a texture (and since it's GLES 2 it has to be RGBA 8-bit), which is pretty awful. GLES 2 also has no unbounded loops in shaders, which makes some postprocessing effects like blurs a big pain to write (you need a separate shader for every blur radius). Granted, most drivers don't enforce this, since it's so obnoxious.

flohofwoe 5y ago
TBH, UBOs are quite useless in GLES3/WebGL2 (the guaranteed size is too small, and dynamically updating without sync issues isn't trivial because the under-the-hood details seems to be different in each GL implementation). If you really need to render lots of skinned characters, you'd use a single texture anyway for uploading the joint data of all characters (e.g. this demo renders hundreds of independently animated characters in a single drawcall in WebGL1): https://floooh.github.io/sokol-html5/ozz-skin-sapp.html https://floooh.github.io/sokol-html5/ozz-skin-sapp.html
asiachick 5y ago
Why is putting bone matrices in a texture awful? Seems great to me.
- pcwalton 5y ago
  Because you're packing unbounded floating point values into an 8-bit RGBA unorm texture. Yes, it can be done. Dealing with the issues is annoying, though.