21–30 of 36 posts
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.
Earlier quoted context omitted.
Traditionally, lighting was calculated per vertex, not per pixel, and the results of those calculations were simply interpolated across the surface of the triangle. A "shader" is not the most general term they could have used for a GPU program, but you very well can "shade" a vertex. Edit: Is this seriously being downvoted? "How do you "shade" a vertex? That implies color, when in fact vertex "shading" is really abou…
Actually, the per-vertex color is passed into the pixel shader, which then decides what to do with it. The vertex shader itself has nothing to do with color except calculating an initial value and passing it to the pixel shader. The pixel shader can be set up to interpret that value as anything. It could make it a grayscale color, it could invert it, it could use only one of the four channels, etc. There used to be n…
Similarly, if you look at early, pre-shader PC graphics cards, like the Voodoo, these cards (kinda like the Play Station) had nothing resembling a vertex shader, and had no knowledge of lighting calculations. They required the host CPU (acting as our "vertex shader") to provide them with completely lit and transformed vertices that they could then rasterize by naively interpolating and combining whatever color and texture coordinate values the host program had supplied to them.
Given this history, I contest the idea that it's clearly the pixel shader's responsibility to deal with all color and lighting calculations, and the vertex shader's responsibility is merely to geometrically transform vertices in space. I still agree that "shader" is a stupid and confusing term (I was learning about this stuff for the first time not long ago, and realizing that "shaders" were just GPU programs was an "aha! moment" for me too), I'm just disagreeing with the first paragraph of your original post.
^ it could do other stuff, like transform matrices to implement a basic matrix stack, but that run-on sentence was already running on long enough...
self promotion: Here's some more. http://greggman.github.io/webgl-fundamentals/ In particular http://greggman.github.io/webgl-fundamentals/webgl/lessons/w...
"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
(Sorry, also jumping on the self-promotion bandwagon.)
Earlier quoted context omitted.
Actually, the per-vertex color is passed into the pixel shader, which then decides what to do with it. The vertex shader itself has nothing to do with color except calculating an initial value and passing it to the pixel shader. The pixel shader can be set up to interpret that value as anything. It could make it a grayscale color, it could invert it, it could use only one of the four channels, etc. There used to be n…
If you go back to what is arguably the earliest hardware that at all resembled the modern 3D pipeline (it predates DirectX, and the DirectX pipeline was greatly inspired by it, according to some article I read on here a while back by one of the guys responsible for the DirectX project), the original Play Station, it mostly consisted of two parts: a "geometry engine" embedded in the CPU which acted like a cross betwee…
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?
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…
Thank you. I have never understood the concept of a -shader; I just knew they were useful and somehow caused neat effects. Even having pasted some shader code into a program once (for a barrel distortion for my rift), I never thought much about them, likely because of the opacity of the name. Just ... magic.
Your description has just made the entire concept click. I'm now actually interested in learning about them, because it's such a simple, sensible idea. Thanks.
side-note: I wish the world had more one-sentence intuitive sum-ups of jargon-laden concepts, even if they are a little 'leaky' as abstractions. Just to give people disconnected from the topic a place to start thinking about it.
FragColor =
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?