It's also arguably not a good set of tutorial unless you want to know how to solve puzzles. Shader programming for games or most purposes do not use the techniques taught in those articles. Those articles are all about what happens on shadertoy. not what happens in something like UE5, Unity, Tensorflow, Google Maps, Photoshop, etc...
I don't know a good place to recommend to use more common techniques. A few though would be
Of course if you enjoy the kinds of techniques Book of Shaders teaches then knock yourself out. I've written a few hundred "puzzle shaders". I just know I'm solving a puzzle which can be super fun and I might learn stuff that's relevant elsewhere but at least I'm fully aware that most of what I'm doing is not really related to how GPUs in the majority of situations.
Very annoying when looking for shader tutorials on Google too. This shouldn’t be the recommended result. It’s a cool intro that leaves you without enough knowledge to “know what you don’t know”
> In shader-land we don’t have too many resources for debugging besides assigning strong colors to variables and trying to make sense of them. You will discover that sometimes coding in GLSL is very similar to putting ships inside bottles. Is equally hard, beautiful and gratifying.
Really? Is there no emulation environment? This DX (development experience) seems ripe for disruption.
Step-through shader debugging has been available since DirectX 9 or earlier. Microsoft shipped a debugger called PIX and a reference shader rasterizer that PIX would use to generate a reference image and let you step through how the shader should behave. I used it extensively.
Reference rasterizers also exist for D3D11 (Windows ships with one called WARP and it's fast enough to actually use for many workloads). I think there might be one for D3D12 as well but I'm not sure.
The dark ages 'printf with colors' stuff they describe is somewhat unique to GLSL and is just a smaller example of how the entire OpenGL ecosystem was horrible for debugging and not well designed. These days people can use Vulkan or D3D11 if they want an ecosystem that was designed intentionally and has good tooling (D3D12 is more comparable to Vulkan but is honestly not worth the trouble for most people yet). For a taste of what good modern graphics debugging looks like, run a modern game in Renderdoc and you can take a snapshot and then pick a random pixel on-screen and step-through debug the shader.
Naturally, game consoles have even better tooling. The PS4 SDK let you step through the actual low level instructions running on the GPU (I'm not sure if they were simulating execution or not though...)
Unfortunately in what concerns the 3D Web, hardly anything changed.
The easiest way is to consider it as a target platform and do everything native during development and deploy to Web as last step.
From the last WebGL + WebGPU meeting, the answer given to the state of GPU debugging, it seems nothing better than SpectorJS is expected in years to come.
A bit sad when browser vendors don't see it as a priority, no wonder Indies rather go mobile native instead, or nowadays streaming, better APIs and tooling out of the box.
Although I have not done this myself, I feel like I would be able to get RenderDoc working in a web environment. RenderDoc has good support for OGL. Maybe there's a big barrier in the way but it would be surmountable - just not sure how long it would take.
Book of shaders is a good intro, and a nice complement to Inigo Quilez's https://iquilezles.org/ tutorials. While it has not been updated in a while, Patricio is responsive on GitHub :)
Yep, amazing how someone can love something so much, then fall deeply out of love of it. Sometimes I wish I had a savant-level of dedication to something.
