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.
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!
If you're interested in shaders and WebGL I recommend using the http://regl.party/ framework. It's a functional react-like wrapper on WebGL. The developer experience focuses on writing raw GLSL shader code.
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.
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
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/ if you've never head of it before. thank me later.
Shaders really are a lot of fun - WebGL isn't ideal, though. If you want to use the same thing in an actual application, I like to recommend Anton's OpenGL 4 Tutorials for quickly getting up and running with OGL4.2-4.3. It's not Vulkan, but personally I'm the sort to leave new APIs to cook for a little while.
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.
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.
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/ (Warning: it might bog down your browser if you have a crummy GPU.)
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.
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.
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.
Thanks, I didn't know that. I've written exactly one shader in my life and it was a transliteration from python. https://www.shadertoy.com/view/MdSXWc (And yeah we have integer modulus now lol)
Yeah, that's fair. I suppose I'm just looking for a very up-front half-sentence about what we're talking about. Computer graphics shaders. Maybe this link isn't meant to go to anyone who isn't already aware of what they're clicking on.
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.
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.
As stated, the driver contains a shader compiler. Personally, I like to see examples, so here's a snippet of code that would compile a WebGL shader:
var gl = canvas.getContext('webgl');
var vShaderSource = document.getElementById('vShader');
var vShader = gl.createShader(gl.VERTEX_SHADER);
gl.shaderSource(vShader, vShaderSource);
gl.compileShader(vShaderSource);
"vShader" is the id of a <script> tag of type "x-shader/x-vertex". Get a WebGL context, get the shader source, create a shader object, bind the source to the shader, then compile the source.
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).
Ah yes, you are right, WebGL shaders are translated first to GLSL or HLSL with a lib like 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).
No need for shame, we are all learning things! From MDN,
>WebGL (Web Graphics Library) is a JavaScript API for rendering interactive 3D and 2D graphics within any compatible web browser without the use of plug-ins.
"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 =)
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?)
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