Personally I wouldn't teach OpenGL ES 3.0 or any OpenGL because its state machine (https://webgl2fundamentals.org/webgl/lessons/resources/webgl...) and horrible error system means tracking down bugs is hard. Instead I'd teach WebGPU as it's portable and has great error messaging.
I'm sure people will objected but I'd argue WebGPU is easier to understand, has better errors, has no state machine, works C++, Rust, JS/TS and other languages, and closer to modern GPU programming if you want to move to Metal or D3D12 or Vulkan later.
Further, OpenGL (and ES) are a nightmare of bugs and incompatibilities students might run into that WebGPU fixes.
That said, the article mentions Apple platforms where you can use ANGLE if you happened to have students stuck there.
show comments
hollowonepl
I agree with Adam Sawicki that it's not that relevant any more but also I do believe it's valuable lesson to tech students where the modernity comes from.
I just don't see personally sense to focus on it longer than just 1mo of intro, tutorial, get through simple example, show limitations, carry on to Vulkan/WGPU with background story that there is also DX12 and Metal that follow similar principles.
proc0
Nice breakdown. I've been wondering why it's so complicated to program on the GPU compared to the CPU. Is it a language paradigm issue or maybe a hardware design limitation? I always think of this when looking at the graphic APIs, espeically Vulkan.
show comments
yunnpp
I've learned more graphics writing software rasterizers and ray tracers than using any APIs. If the goal is to teach GPU rendering specifically, then OpenGL is indeed more amenable to teaching than the others. But if the goal is to teach graphics and rendering concepts, then OpenGL et al are just miserable and counter-productive.
show comments
avaer
GLES isn't a bad way to teach graphics but I wish there was a middle ground between it and VK.
The worst part of GL is the mysterious global state you will never understand without studying the spec. The world could use an API that's basically GL but without global hidden singleton (per thread!) BS behind the scenes.
show comments
snvzz
The linked webpage refuses keyboard navigation e.g. cursors, pageup/down and home/end seem to do nothing.
Awful.
show comments
gulugawa
Sounds like a great way to make sure students understand fundamental concepts.
modeless
TL;DR because WebGL 2 is basically equivalent to OpenGL ES 3.0, making it the most portable GPU API in the world by far, running on everything from laptops and phones to smart fridges and car head units.
Web browsers have also done a lot of behind-the-scenes work on compatibility. The behavior of WebGL 2 is much, much more consistent across platforms than native OpenGL [ES] ever was.
Personally I wouldn't teach OpenGL ES 3.0 or any OpenGL because its state machine (https://webgl2fundamentals.org/webgl/lessons/resources/webgl...) and horrible error system means tracking down bugs is hard. Instead I'd teach WebGPU as it's portable and has great error messaging.
I'm sure people will objected but I'd argue WebGPU is easier to understand, has better errors, has no state machine, works C++, Rust, JS/TS and other languages, and closer to modern GPU programming if you want to move to Metal or D3D12 or Vulkan later.
Further, OpenGL (and ES) are a nightmare of bugs and incompatibilities students might run into that WebGPU fixes.
That said, the article mentions Apple platforms where you can use ANGLE if you happened to have students stuck there.
I agree with Adam Sawicki that it's not that relevant any more but also I do believe it's valuable lesson to tech students where the modernity comes from.
I just don't see personally sense to focus on it longer than just 1mo of intro, tutorial, get through simple example, show limitations, carry on to Vulkan/WGPU with background story that there is also DX12 and Metal that follow similar principles.
Nice breakdown. I've been wondering why it's so complicated to program on the GPU compared to the CPU. Is it a language paradigm issue or maybe a hardware design limitation? I always think of this when looking at the graphic APIs, espeically Vulkan.
I've learned more graphics writing software rasterizers and ray tracers than using any APIs. If the goal is to teach GPU rendering specifically, then OpenGL is indeed more amenable to teaching than the others. But if the goal is to teach graphics and rendering concepts, then OpenGL et al are just miserable and counter-productive.
GLES isn't a bad way to teach graphics but I wish there was a middle ground between it and VK.
The worst part of GL is the mysterious global state you will never understand without studying the spec. The world could use an API that's basically GL but without global hidden singleton (per thread!) BS behind the scenes.
The linked webpage refuses keyboard navigation e.g. cursors, pageup/down and home/end seem to do nothing.
Awful.
Sounds like a great way to make sure students understand fundamental concepts.
TL;DR because WebGL 2 is basically equivalent to OpenGL ES 3.0, making it the most portable GPU API in the world by far, running on everything from laptops and phones to smart fridges and car head units.
Web browsers have also done a lot of behind-the-scenes work on compatibility. The behavior of WebGL 2 is much, much more consistent across platforms than native OpenGL [ES] ever was.