Hacker News Reader

Comment by mouldysammich | Hacker News Reader

> I'm really rooting for WebGPU as the "cross-platform 3D-API for the rest of us" (where "rest of us" is everybody who isn't a highly specialized rendering engineer in an AAA-game engine team).

I'm feeling the same way, I'm interested in getting into doing a little graphics programming as a beginner, but the whole thing does feel impenetrable.

View on HN

Might I shamelessly plug my sokol_gfx.h library (assuming your language of choice is C or C++). These are WASM samples written in C or C++, a link to the source code is in each sample:

https://floooh.github.io/sokol-html5/

A complete Hello Triangle fits in a single source file of about 80 lines, and the API structure of sokol-gfx is close enough to modern 3D-APIs that it also serves as a useful starting point if you want to move on to Metal, D3D12 or Vulkan (or even WebGPU) later.

I don't think getting into OpenGL is actually that hard. There are wrapper libraries, e.g. for Java, and tons of tutorials.

The hardest part for beginners is probably wrapping their head around the concept of the rendering pipeline, with it's various stages. Once this is settled, it becomes much clearer what the various shaders do and how they interact with each other. So I'd higly recommend spending some time to understand rendering pipelines first.

Absolutely this. I wish I had spent more time learning about the rendering pipeline before jumping into trying out so much as a "Hello Triangle" tutorial.

It's also worth getting familiar with terminology early on, because common terms in the context of graphics programming have different meanings to their common usage. e.g. I've found it helpful to think of a "vertex" first and foremost as an element of an array, which is processed SIMD-style by the "vertex shader". In most cases it is the co-ordinates of a polygon vertex, but usually with other data bundled in the element as well such as texture co-ordinates. The term "shader" seems to be used for any program that runs on the GPU, regardless of whether it does shading of any kind.

Unless you're in CUDA, then it's a "kernel." But in OpenCL it's still a "compute shader"?

Oy vey

I agree. I recently started exploring OpenGL and found it pretty approachable. If someone is looking for a resource to help learn OpenGL, I found https://learnopengl.com/ extremely helpful.

OpenGL isn't hard, but it's API is outdated and full of surprises. Error reporting is bad (glGetError), debug context works somewhat better (error callbacks), but I had errors that reproduce on debug context only. C API is very weakly typed, so it's easy to pass GL_RGBA to a function which expects GL_RGBA8. But the worst part of OpenGL is the state machine. OpenGL is the only graphical API still remaining that has the concept of state machine, and it causes a lot of trouble when rendering. You basically have to abstract the entire state machine on your side of code, or defensively back out all state changes that you do. Modern APIs are more stateless, and state object is passed along with the drawcall, more or less, without affecting any other drawcalls in the commandbuffer.

Legacy OpenGL is a pain not because of the state machine, but the many ways of doing things, some of which are slow. The weird function names don't help either.

WebGL is better than that because it is only the useful, fast subset, and provides some objects too. Plus JavaScript is easier to work with than C, too.

Anyway modern APIs are not stateless, having an object that contains the state is the same. In the end, it is still all about bind this, bind that, do this, do that.

Yes, it's overly complex for beginners.

I wanted to play with Nvidia's real-time raytracing. They have a nice tutorial to show a triangle.

https://developer.nvidia.com/rtx/raytracing/dxr/DX12-Raytrac...

Reply on news.ycombinator.com