
Primer: Shaders - hughsk
http://notes.underscorediscovery.com/shaders-a-primer/
======
sillysaurus3
Part of the confusion is the confusing terminology. "Shader" is a bad name.
How do you "shade" a vertex? That implies color, when in fact vertex "shading"
is really about deforming the position of vertices. It has nothing to do with
color!

"Vertex program" is a better term.

That brings us to "pixel shader." That's actually a good name in order for
beginners to learn the concept, but it's imprecise. OpenGL insists on calling
it a "fragment program" because with certain forms of antialiasing, there are
multiple "fragments" per pixel. "Program" is also a better name than "shader"
because there are things you can do per-pixel other than change the color. For
example you could change the depth written to the Z-buffer, or you could cause
the pixel to be skipped based on some criteria, like whether the texture color
is pink.

Anyway, it's just a tiny program that executes either per-vertex or per-pixel.
For example you could write a vertex program which moves each vertex in a
sinewave pattern based on time. Or you could write a fragment program to
change the color of each pixel from red to green and back based on time.

Then there are more advanced/recent concepts like a "geometry program," which
lets you generate triangles based on vertices or edges.

Sometimes I wonder if it's overly complicated, or if the problem domain is
just complicated. It took me years as a kid to finally grok this, but once I
learned it, it turned out to be very simple. Honestly it wasn't until I got up
enough courage to sit down with the OpenGL specs and read through them that
everything clicked. They're dry reading but not difficult.

~~~
pyalot2
The reason it's not called vertex program is because the pipeline is defined
in terms of stages (vertex -> tessellation control -> tessellation evaluation
-> geometry -> rasterizer -> fragment). Together they are a program. When
talking about this structure the choice that OpenGL made is:

"A shader program consists of a vertex shader (VS), tessellation control
shader (TS control), tessellation evaluation shader (TS eval), geometry shader
(GS) and fragment shader (FS)."

You could instead say this, but it would be confusing:

A shader program consists of a vertex program, tessellation control program,
tessellation evaluation program, geometry program and fragment program.

And it would even get more confusing if you drop the first shader:

"A program consists of a vertex program, tessellation control program,
tessellation evaluation program, geometry program and fragment program."

So for the sake of it being easy to talk about, a (shader) program is the
whole thing, whenever somebody talks about a "program" it's the whole
assemblage. And when somebody talks about a shader, it means one of the
programs tied to a stage.

~~~
sillysaurus3
Yeah, this has the side effect of making it almost impossible for newcomers to
have any clue what the heck is going on until they have several months of
(painful) experience trying to figure out each piece.

It doesn't have to be this complicated. Humans just made it that way. I'm just
trying to make sure everyone understands that there's nothing mysterious or
even especially interesting about these terms. It's complicated like an
internal combustion engine is complicated, not like math.

~~~
nightski
So you are proposing that the difference in calling it a "program" vs. a
"shader" increases the complexity of learning the concept by several months?

~~~
sillysaurus3
Sure, it did for me. I think mental models are important, and that it's kind
of dopey to call something by a confusing name. (I'm looking at you, physics!)
But on the other hand, I'm not very smart, and I had to spend most of my time
on gradeschool instead of learning shaders. It was also before wonderful
resources like stackoverflow/HN/reddit/etc, so there weren't a lot of people
to help clarify my mental model.

As I've gotten older it's become easier to think abstractly and accept that
names sometimes have nothing to do with what things are. But when you're first
starting out, it's natural to want to visualize everything you learn as what
it sounds like.

~~~
lexis
If shaders are hard, it's mostly because they require a full understanding of
3D math, the complete graphic pipeline, texture sampling, image manipulation
techniques and how it all comes together before you can actually start doing
anything useful; so the learning curve has a slope of 'wat' to almost all
newcomers. If anything, naming is just a nuisance.

~~~
sillysaurus3
_they require a full understanding of 3D math, the complete graphic pipeline,
texture sampling, image manipulation techniques and how it all comes together
before you can actually start doing anything useful_

Hm, not really. I learned more from messing with working demos and prototypes
than studying theory. But YMMV.

It's absolutely true that the whole pipeline is very intimidating for
newcomers, though.

I love that phrase... "the learning curve has a slope of 'wat'."

------
ceautery
Nice, thanks a lot. Great animations.

"Shader" was a term I was confused about at first when I was learning WebGL.
In fact, in the WebGL world, it seems like one is expected to come from an
OpenGL background and be familiar with whatever popular 3rd party libraries
are en vogue. I never found a thorough guide that didn't presume one of those
two things, so I built one:

[https://curtisautery.appspot.com/5898536285634560](https://curtisautery.appspot.com/5898536285634560)

(Sorry, also jumping on the self-promotion bandwagon.)

------
neals
To me, the thing with shaders always is: I need them at some stage in a
project. I have used them before, but too long ago to remember, so I need to
look up most it. I work with it a for a few weeks. That part of the project is
done and I move on.

A year later, a new project comes along. It requires shaders. I don't remember
how to use then and have to look it up again...

Repeat.

------
greggman
self promotion: Here's some more.

[http://greggman.github.io/webgl-
fundamentals/](http://greggman.github.io/webgl-fundamentals/)

In particular

[http://greggman.github.io/webgl-
fundamentals/webgl/lessons/w...](http://greggman.github.io/webgl-
fundamentals/webgl/lessons/webgl-how-it-works.html)

~~~
ceautery
Hey, I found these when I was untangling WebGL, and found them pretty useful.
Thanks for making them.

------
fotcorn
What shader languages are used in cross-platform games? PS3 uses Cg, PS4 PSSL,
Xbox & Windows use HLSL and OpenGL on Mac/Linux/Smartphones/Tablets use GLSL.
Are there converters from one to the other language? How do big engines like
Unreal oder CryEngine handle this?

~~~
subb
Either have an abstraction layer (another language or a user interface) or a
translator.

------
Jemaclus
As someone who is not well-versed in graphics or graphics programming, this
was a very well-explained primer. I very thoroughly enjoyed it, and learned
something in the process!

------
fescue
This guide has helped me unbend my mind about shaders:
[http://pixelshaders.com/](http://pixelshaders.com/)

------
svantana
While I appreciate the effort, I think this primer is lacking what most other
shader tutorials also lack: any information on how to actually do something
useful. Shaders are used because they are faster than the cpu. So why isn't
everything done with shaders? Because of limitations. So what are those? Most
GPU tutorials only include examples of the form

FragColor = <some algebraic expression containing x & y>

That's nice, but hardly useful. To do anything of worth, I would need data
from the CPU. How do I do that? What are the most common bottlenecks? What are
some ways around the limitation of working with one fragment at a time? Those
are the sort of questions I would like to see answered in a primer. A sort of
"GPU introduction for competent CPU devs" \- any recommendations?

~~~
mattdesl
Bottlenecks and multi-sample output are complex subjects, and also uncommon
for a beginner to deal with.

Nevertheless, gonna just pimp my own tutorials since they also cover practical
implentations, like blurs for desktop and mobile, normal mapping for 2D games,
vignettes, etc. [https://github.com/mattdesl/lwjgl-
basics/wiki/Shaders](https://github.com/mattdesl/lwjgl-basics/wiki/Shaders)

------
mattdesl
Nice intro. Shaders definitely seem a lot more elusive than they really are.

Also gonna jump on the bandwagon with my own tutorials, using Java/LibGDX and
mostly focusing on 2D applications.

[https://github.com/mattdesl/lwjgl-
basics/wiki/Shaders](https://github.com/mattdesl/lwjgl-basics/wiki/Shaders)

