
The Book of Shaders - blaze33
https://thebookofshaders.com
======
davidwparker
The Book of Shaders is a great resource.

Shameless self promotion: if you're interested in general WebGL, I have a
Youtube channel with over 100 WebGL videos. I publish a couple times a week.

I haven't started diving into doing cool shader things yet (beyond some light
stuff with lighting, fog, textures, and a few other minor things). It's on my
list to do though.

Channel:
[https://www.youtube.com/user/iamdavidwparker](https://www.youtube.com/user/iamdavidwparker)

~~~
Fifer82
Thanks! I found a ton of old Flash Experiments on an old disk and looking to
port them. WebGL isn't the easiest thing when you are new and many resources
seem somewhat dated. Subscribed!

------
Vekz
If you're interested in shaders and WebGL I recommend using the
[http://regl.party/](http://regl.party/) framework. It's a functional react-
like wrapper on WebGL. The developer experience focuses on writing raw GLSL
shader code.

------
adamnemecek
I've been writing these a bunch as of late and to be honest it's some of the
most exciting and rewarding types of programming around. It really stretches
out your imagination and also math.

Shader code tends to be extremely terse. 1000 lines of shader code is like a
lot.

Like what can yoh really do with a 1000 loc rails app.

~~~
dualogy
Agree, I always enjoyed hacking on shaders. And checking out other's shaders
(and further tweaking them) is also inspiring educational and most gratifying.
ShaderToy is a great site for that, but there's many more "shader communities"
/ gfx coding forums etc, great fun

~~~
adamnemecek
can you name a couple of good ones? i'm aware of pouet, never got too into it.
everyone reading this pls check out if
[https://www.shadertoy.com/](https://www.shadertoy.com/) if you've never head
of it before. thank me later.

------
aidos
I started reading this last night and I'm really enjoying it.

As I posted on the WebGL Voxel Engine thread [1] yesterday, I've been looking
to get more into this subject and had found it a little unapproachable. This
renderer [2] in 500 loc was also recommended and is a really readable intro
for background on the subject.

[1]
[https://news.ycombinator.com/item?id=15595137](https://news.ycombinator.com/item?id=15595137)

[2]
[https://github.com/ssloy/tinyrenderer/wiki/](https://github.com/ssloy/tinyrenderer/wiki/)

~~~
swah
This book seems to be in progress though.

------
Waterluvian
This looks great for someone like me who has no idea what shaders are, but it
really needs to start with, "...Fragment Shaders, those things that do X with
computer graphics."

Written by people who know what the topic is already, so I think they miss
that I went into this not knowing if they were talking about computers or some
art form or ink and pen style or whatnot.

~~~
sp332
A fragment shader a.k.a. pixel shader is a program that runs once for each
pixel [edit: per frame!]. It's at the end of the graphics pipeline so the
geometry and texture of a scene is already available as an input. So it can
either interpret the scene and decide how to render the output, or it can even
ignore the scene and draw something completely original. Lots of examples at
[https://www.shadertoy.com/](https://www.shadertoy.com/) (Warning: it might
bog down your browser if you have a crummy GPU.)

~~~
leggomylibro
Well, it actually can run way more than once per pixel; it runs once per texel
per thing that is rendered, where a texel is a 'fragment' of the displayed
model which is the size of a pixel on the screen.

So if you have a bunch of things occluding each other, they can all get
rendered on top of each other even if only the closest is actually displayed.

Sometimes people try to avoid that by not drawing stuff that is occluded, or
drawing in order of depth, or discarding fragments if the depth buffer has
already drawn over a location with a nearer texel, or that sort of thing. But
it's always a PITA to calculate/sort that sort of thing in realtime.

~~~
reificator
Look, teaching is the art of lying about the monster under the bed until the
other person is ready to defeat it.

Once per pixel is fine when you're teaching the hello world of shaders.

~~~
leggomylibro
Good point, sorry, that was pedantic.

But I've actually kind of been thinking about that, too. Think about how much
'magic code' most 'hello world' tutorials have that you're told to just
ignore. That can also be off-putting when there's too much of it.

I wonder if there's a happy medium for introducing the basic concepts, like
starting with microcontroller assembly instead of 'std::cout << "hello,
world";'.

Then you won't have to explain things like '#include' because your students
will already know that it just means 'pretend I copy/pasted file X here' from
when they learned how to make an LED blink.

Anyways, I guess this particular resource does look like it struck a pretty
happy middle ground for beginners. I just hope they don't get discouraged
trying to branch out with self-teaching; there are a lot of byzantine
'gotcha's with graphics APIs and parallel stuff.

~~~
pfranz
I was thinking about this the other day, too. Clash Royale recently added this
Quests thing. Since I've been playing for awhile I know that it's separate
from the main game and basically a bonus. If I was first starting to play it
would be yet another thing to learn and it would be hard to know how it fits
in with the rest of the game's objectives. I think of those crazy 10-way slot
machines in Vegas. I have no idea whats going on (either by design or I'm not
their mark...I mean target).

I think the big thing with introducing new things is keep it simple enough
that they can riff on it. If you introduce too many things and something
breaks, it's hard to get back to "good" and eventually you give up.

Python is a simple language, but I see a lot of online classes giving full-on
VMs because the yak shaving involved in getting set up with a consistent
environment wastes the first week or two of class.

------
AndrewStephens
I used _The Book of Shaders_ when creating my WebGL cross fading project[1],
it is one of the more helpful guides (on any subject) I have found on the web.

The book is incomplete but I look forward to future updates.

[1] [https://sheep.horse/2017/9/crossfading_photos_with_webgl_-
_b...](https://sheep.horse/2017/9/crossfading_photos_with_webgl_-
_boston_bridge_proj.html)

------
pvg
Bunch of previous threads:

[https://hn.algolia.com/?query=%22the%20book%20of%20shaders%2...](https://hn.algolia.com/?query=%22the%20book%20of%20shaders%22&sort=byPopularity&prefix=false&page=0&dateRange=all&type=story)

------
CobrastanJorji
I'm ashamed to admit I was like 4 chapters into this before I realized that
the code samples were live.

I'm also still somewhat confused as to how the live code samples are achieved.
Are they being compiled client side somehow? I don't know very much about
WebGL.

~~~
coffeeaddicted
The compiler is in the graphic card drivers. You pass on shader source-code to
it in text-form.

~~~
fulafel
Kind of. The browser WebGL implementation compiles them, producing shaders
suitable the native driver shader compiler (conversion from OpenGL to D3D,
rewrite texture/buffer access for bounds checking as necessary, etc).

~~~
coffeeaddicted
Ah yes, you are right, WebGL shaders are translated first to GLSL or HLSL with
a lib like ANGLE
([https://github.com/google/angle](https://github.com/google/angle)). And that
source is then send on to the drivers which compile it again to assembler for
the graphic card. And there again are some differences between GLSL/HLSL it
seems. If I remember right in GLSL the drivers do the work while in HLSL some
DLL from MS produces another intermediate format (which I just found out seems
to be even open source:
[https://github.com/Microsoft/DirectXShaderCompiler](https://github.com/Microsoft/DirectXShaderCompiler)).

------
dang
Discussed in 2016:
[https://news.ycombinator.com/item?id=11457322](https://news.ycombinator.com/item?id=11457322)

------
roywiggins
I wrote a little hack on top of the Book of Shaders editor to let you use
texture and float uniforms:

[http://roy.red/editor/](http://roy.red/editor/)

You can give floats a range and default value with a comment:

    
    
        uniform float u_float; //0;.5;1

------
bootcat
I think this project is similar to
[http://www.craftinginterpreters.com/](http://www.craftinginterpreters.com/)

------
Zee2
It looks like it's still incomplete, the sections on textures/3d graphics
aren't complete yet. Looking forward to reading up on these topics.

~~~
rounce
Yup, still waiting on those since the last time it was posted on HN...

------
shmerl
Isn't using the term shader somewhat incorrect today? It basically means any
GPU program, so it's not limited to shading by far.

~~~
dualogy
"Naming things", one of the 2 hard problems in computing. In other words, not
worth scratching your head over, ever. "Historical accidents" in terminology
just such as this one abound all over the tech world. What you say
specifically about "the term shader" has been true at least ever since the
first consumer GPU offered a programmable vertex pipeline and their marketers
chose the term "vertex shaders". How long ago was that, nearly 2 decades I
reckon?

Could've been worse. Since Java was so big back then, too, we're lucky they
didn't come up with eg. "Rendlets". At least "shader" is freakin' aesthetic =)

~~~
iainmerrick
Not important to your point, but for historical flavor--

I'm pretty sure the term "shader" was introduced by Pixar, from way back
before _Toy Story_ when they were doing little demos and short movies. They
were building very modern-looking graphics pipelines in software way before
the first GPUs (I think Nvidia coined that term?)

~~~
Synaesthesia
The original nVidia GeForce 256 was termed a “GPU”. It did transform and
lighting on the GPU I remember.

------
sdee21
I also recommend you the [http://regl.party/](http://regl.party/) framework if
you're interested in Shaders

