7 ms·

Actually disagreeing with the author here: As someone who did a bit of OpenGL/GLSL in their spare time building a game engine, I think it's not that arcane. You

by rf15 9y ago

Actually disagreeing with the author here: As someone who did a bit of OpenGL/GLSL in their spare time building a game engine, I think it's not that arcane. You will have to come across the basic rendering pipeline pretty quickly if you look around a bit and don't just drone along with the tutorials, and from then on out it's pretty obvious what you load all those buffers for and how the shaders work in which order throughout the pipeline. (that being said, early openGL with separate state machine calls for each vertex were a little weird, and the current implementation is much closer to the underlying functionality)

ucarion 9y ago
For a beginner, it's a frustrating process. OpenGL's primary way of letting you know you messed up is by giving you a blank screen. This is much alleviated when you use a wrapper around OpenGL (e.g. Rust's `gfx`), but most people start with raw OpenGL.
- vvanders 9y ago
  That doesn't change with Vulkan, screw up a transform/shader math/vertex format and you'll also end up with a blank screen. Ironically there's a bunch more debuggers that work with OpenGL as opposed to Vulkan(or know how to debug you're way out of a blank screen by tweaking shaders/api calls to eliminate things).
  - and0 9y ago
    The DirectX graphics debugger in Visual Studio is a godsend. It lets you analyze ever call and check every buffer for any "snapshot" of a frame you take. Very easy to identify things like misaligned data, etc, that would be impossible to find otherwise. (This feature broke on my desktop, though, and I still can't fix it for the life of me, but I'm past that point in my project development anyway.)
    - vvanders 9y ago
      Yup, most mobile GPU vendors have similar things for Android and they're incredibly useful for debugging and profiling.
      - hrydgard 9y ago
        There's also RenderDoc available for Windows and Linux and maybe more, it's not great with OpenGL but excellent for debugging Vulkan and D3D11.
        mellinoe 9y ago
        I know it doesn't work with OpenGL ES, but RenderDoc works well on regular OpenGL apps, from my experience.
and0 9y ago
I started a DirectX (so, HLSL, basically identical from my understanding) and C++ project about a year ago. I hadn't worked with either, but managed to get a little window up and running within a weekend. That was mostly thanks to some templates out on the web. The reason I think it deserves to be called "arcane" is that, to even reach an RGB triangle (the shader equivalent of "Hello World"), you have to have dozen different things working all at once: - Writing / compiling the shaders (vertex and pixel/fragment, at least) - Loading the shaders - Describing the vertex data - Creating vertex data - Describing constant buffers - Creating constant buffers for vertex + world/view/perspective - Filling all the buffers with data - Giving the right data for view / perspective matrices (the camera, basically) - Calling the rendering of a mesh - Getting the output to draw on the screen - + a ton of other drawing descriptions I don't even remember, like raster descriptions For all of those tasks there is an insane amount of boilerplate that needs to be written. This is okay in itself, since it's all stuff that's worth tweaking for various use cases, but it creates a pretty insane barrier to entry. Not everyone needs to learn all the quirks of setting up vertex buffer descriptions right up front. I personally wasn't going to read a huge DirectX bible just to see how to get started. It's a problem very much deserving of a copy+paste solution, with some clear instructions on how to tweak for individual needs, but most tutorials (MSDN or otherwise) concentrated on specific features or were in a series building on an already opinionated codebase / pipeline. And if any part of it doesn't work, and you'll be second guessing yourself and asking a ton of questions with every line of code, you have no real way of knowing what went wrong. However, once I had a pipeline set up (and then started organizing it in a way that it managed itself and could host various shader types) I started having a lot of fun. I'm working on a 3D NES emulator [http://n3s.io http://n3s.io] and felt super inventive when I found a way to get the models to render using the NES palette.
- deleted 9y ago
  [deleted]
- aaron-lebo 9y ago
  You kind of have to do that stuff, though. There's no getting around understanding linear algebra and feeding vertices into the GPU. It's kind of like the bare minimum you need to swim. Yeah you gotta learn it and there's some funky techniques, but you gotta tread water somehow, yeah? It is a lot to learn at once, but no more than web dev where you are learning html and databases and HTTP and god knows what else at once. And like you said once you grok it, it's pretty easy. Graphics programming terrified me for the longest time because people acted like it was dark magic and hard. Figuring this stuff out slowly but surely it shocks me how little there is to it and I wish someone would have told me sooner. I've gotten rendering a cube down to an art (gotta start somewhere). You're talking ~100 lines of JS and double that of C++ but no more than that in any decent language. And that's a cube (or multiple) and a basic camera. A library like regl shows how simple this stuff can get without lots of boilerplate. https://github.com/regl-project/regl/blob/gh-pages/example/basic.js https://github.com/regl-project/regl/blob/gh-pages/example/b... Boom a triangle in 40 lines, but the underlying process of vertices, buffers, shaders, etc is apparent. Cool stuff. Those asking about Vulkan - Vulkan only increases the boilerplate by design.
munchbunny 9y ago
One of the biggest barriers (in my experience) with people getting into graphics is understanding the underlying mathematics and algorithms. You can't really skip having a strong conceptual grasp of how the matrix transforms, texture sampling, perspective projections, etc. work. Once you understand that stuff, everything becomes much more straightforward. You still have a lot of "paperwork" to do because you have to set up the whole pipeline to render anything, but at least then you can see the whole picture.
- maxxxxx 9y ago
  "One of the biggest barriers (in my experience) with people getting into graphics is understanding the underlying mathematics and algorithms. You can't really skip having a strong conceptual grasp of how the matrix transforms, texture sampling, perspective projections, etc. work." That was my biggest problem when I did some OpenGL work a few years ago. It takes a while to understand what OpenGL really is and what it isn't.

by rf15 9y ago

ucarion 9y ago

For a beginner, it's a frustrating process. OpenGL's primary way of letting you know you messed up is by giving you a blank screen. This is much alleviated when you use a wrapper around OpenGL (e.g. Rust's `gfx`), but most people start with raw OpenGL.

vvanders 9y ago
That doesn't change with Vulkan, screw up a transform/shader math/vertex format and you'll also end up with a blank screen. Ironically there's a bunch more debuggers that work with OpenGL as opposed to Vulkan(or know how to debug you're way out of a blank screen by tweaking shaders/api calls to eliminate things).
- and0 9y ago
  The DirectX graphics debugger in Visual Studio is a godsend. It lets you analyze ever call and check every buffer for any "snapshot" of a frame you take. Very easy to identify things like misaligned data, etc, that would be impossible to find otherwise. (This feature broke on my desktop, though, and I still can't fix it for the life of me, but I'm past that point in my project development anyway.)
  - vvanders 9y ago
    Yup, most mobile GPU vendors have similar things for Android and they're incredibly useful for debugging and profiling.
    - hrydgard 9y ago
      There's also RenderDoc available for Windows and Linux and maybe more, it's not great with OpenGL but excellent for debugging Vulkan and D3D11.
      - mellinoe 9y ago
        I know it doesn't work with OpenGL ES, but RenderDoc works well on regular OpenGL apps, from my experience.

and0 9y ago

I started a DirectX (so, HLSL, basically identical from my understanding) and C++ project about a year ago. I hadn't worked with either, but managed to get a little window up and running within a weekend. That was mostly thanks to some templates out on the web. The reason I think it deserves to be called "arcane" is that, to even reach an RGB triangle (the shader equivalent of "Hello World"), you have to have dozen different things working all at once: - Writing / compiling the shaders (vertex and pixel/fragment, at least) - Loading the shaders - Describing the vertex data - Creating vertex data - Describing constant buffers - Creating constant buffers for vertex + world/view/perspective - Filling all the buffers with data - Giving the right data for view / perspective matrices (the camera, basically) - Calling the rendering of a mesh - Getting the output to draw on the screen - + a ton of other drawing descriptions I don't even remember, like raster descriptions For all of those tasks there is an insane amount of boilerplate that needs to be written. This is okay in itself, since it's all stuff that's worth tweaking for various use cases, but it creates a pretty insane barrier to entry. Not everyone needs to learn all the quirks of setting up vertex buffer descriptions right up front. I personally wasn't going to read a huge DirectX bible just to see how to get started. It's a problem very much deserving of a copy+paste solution, with some clear instructions on how to tweak for individual needs, but most tutorials (MSDN or otherwise) concentrated on specific features or were in a series building on an already opinionated codebase / pipeline. And if any part of it doesn't work, and you'll be second guessing yourself and asking a ton of questions with every line of code, you have no real way of knowing what went wrong. However, once I had a pipeline set up (and then started organizing it in a way that it managed itself and could host various shader types) I started having a lot of fun. I'm working on a 3D NES emulator [http://n3s.io http://n3s.io] and felt super inventive when I found a way to get the models to render using the NES palette.

deleted 9y ago
[deleted]
aaron-lebo 9y ago
You kind of have to do that stuff, though. There's no getting around understanding linear algebra and feeding vertices into the GPU. It's kind of like the bare minimum you need to swim. Yeah you gotta learn it and there's some funky techniques, but you gotta tread water somehow, yeah? It is a lot to learn at once, but no more than web dev where you are learning html and databases and HTTP and god knows what else at once. And like you said once you grok it, it's pretty easy. Graphics programming terrified me for the longest time because people acted like it was dark magic and hard. Figuring this stuff out slowly but surely it shocks me how little there is to it and I wish someone would have told me sooner. I've gotten rendering a cube down to an art (gotta start somewhere). You're talking ~100 lines of JS and double that of C++ but no more than that in any decent language. And that's a cube (or multiple) and a basic camera. A library like regl shows how simple this stuff can get without lots of boilerplate. https://github.com/regl-project/regl/blob/gh-pages/example/basic.js https://github.com/regl-project/regl/blob/gh-pages/example/b... Boom a triangle in 40 lines, but the underlying process of vertices, buffers, shaders, etc is apparent. Cool stuff. Those asking about Vulkan - Vulkan only increases the boilerplate by design.

munchbunny 9y ago

One of the biggest barriers (in my experience) with people getting into graphics is understanding the underlying mathematics and algorithms. You can't really skip having a strong conceptual grasp of how the matrix transforms, texture sampling, perspective projections, etc. work. Once you understand that stuff, everything becomes much more straightforward. You still have a lot of "paperwork" to do because you have to set up the whole pipeline to render anything, but at least then you can see the whole picture.

maxxxxx 9y ago
"One of the biggest barriers (in my experience) with people getting into graphics is understanding the underlying mathematics and algorithms. You can't really skip having a strong conceptual grasp of how the matrix transforms, texture sampling, perspective projections, etc. work." That was my biggest problem when I did some OpenGL work a few years ago. It takes a while to understand what OpenGL really is and what it isn't.