31–40 of 72 posts
This is neat! I've gone down the SDF rabbit hole a bit, recently. I'm glad you added some links to iq's site; he's got great stuff. I feel compelled to link to his "happy bouncing" shader, which is phenomenal IMO: https://www.shadertoy.com/view/3lsSzf (with associated 6 hour (!) youtube video on its creation) That's a juicy ~500 lines of code (:
The article is quite nice. However, it glosses over the primary problem with shaders. A shader is a pain in the ass that most programs and applications don't want. 3D stuff likes triangles and the GPUs are happy to slot into that abstraction. Shaders are useful to interpolate over those triangles. Triangles are mostly garbage for everybody else. 2D rendering wants paths. Font rendering wants paths or pixmaps. GUI's w…
What part of a pixel/fragment shader does not map very well to pixmaps?
You can work around the limitations in vertex or fragment shaders, but, in many cases, you're having to unwind a lot of what the vertex and fragment processing does.
On of my favorite examples is drawing a screen/pixel-space rectangle and then drawing a border of the rectangle in a different color and specifying the number of pixels that border should be wide. Oof. You have to specify 4 triangles, make sure they don't overlap, specify them in a particular vertex order or annotate them with extra data so you only draw one of the three edges, make sure that you only draw each pixel just once or your blending goes all to crap, etc. Whereas, you can divide the rectangle into chunks, send each chunk through the compute pipeline, and it's stupidly straightforward.
Or, if you want simpler, just draw a line n pixels wide. If you don't have an explicit extension to do this, it's really a pain.
2D graphics simply wants very different graphic and computational primitives compared to 3D.
Very nice, I've tried looking at a couple other tutorials in the past but they always assume more prior knowledge than I have. This really hits the sweet spot for me. Would love to see tutorials on more topics. In particular, a very basic lighting model but with a detailed breakdown on how normals and dot product work together. Yes, there's plenty of info out there, but I think your teaching style would still make it…
The article is quite nice. However, it glosses over the primary problem with shaders. A shader is a pain in the ass that most programs and applications don't want. 3D stuff likes triangles and the GPUs are happy to slot into that abstraction. Shaders are useful to interpolate over those triangles. Triangles are mostly garbage for everybody else. 2D rendering wants paths. Font rendering wants paths or pixmaps. GUI's w…
Edit: upon a reread, I don't really understand what your problem is with gpus. You can ignore the vertex processing pipeline entirely, drawing just a single fullscreen quad (or use a compute shader); the gpu will handle this with aplomb, and this is the sort of thing the linked article is talking about too.
I finally found the courage to write and expose myself to the internet. I've always wanted to learn shaders so I thought it would be nice to document my learning and share it with others.
“their parallel nature makes them memoryless and stateless. This translates to: “You can’t store or share data between pixels or shader executions.”” This kind of constraint is so liberating for me for some reason. It just narrows the space a lot I guess. I also kind of love not having imports and libraries as that also really simplifies things.
if you like this kind of a thing, erlang is a kind of thing you would like :o)
I finally found the courage to write and expose myself to the internet. I've always wanted to learn shaders so I thought it would be nice to document my learning and share it with others.
If you want to see what the Masters can do with shaders, let me introduce you to Inigo Quilez and his shader art: https://www.youtube.com/watch?v=BFld4EBO2RE
EDIT: I did not notice you are the author of this article. It's very well done, and I've been looking for more approachable and interactive tutorials on the arts of shader coding.
Earlier quoted context omitted.
What part of a pixel/fragment shader does not map very well to pixmaps?
Only interpolating based on the edge? Needing to carefully map float coordinates so you don't wind up with fractional pixels mapping incorrectly? Inability to look at pixels to each side to compute something? You can work around the limitations in vertex or fragment shaders, but, in many cases, you're having to unwind a lot of what the vertex and fragment processing does. On of my favorite examples is drawing a scree…
The fractional pixel mappings do get you - but I think I recall an integer mode somewhere in GLSL 3.2.
Your example steps outside the shader boundary, though. If you try to use triangles to draw pixmap, of course you'll have trouble. That's why pixel shaders are the right tool for the job.
The only disadvantage they have is that the pixmaps are immutable within a single pass, so you can't (easily) draw the border together with the inner rectangle in one pass. But if you're used to functional programming, you won't even notice this.
I agree that shaders are not the right thing when you need mutability, as you seem to, but working with 2D graphics doesn't necessarily require mutability.
I finally found the courage to write and expose myself to the internet. I've always wanted to learn shaders so I thought it would be nice to document my learning and share it with others.
Also your website is very sleek, minimal and your projects are tasteful.
I finally found the courage to write and expose myself to the internet. I've always wanted to learn shaders so I thought it would be nice to document my learning and share it with others.
This article is super fun. Thanks! I was curious if you’ve learned WGSL, the shader language for WebGPU? I’m struggling to wrap my head around what’s similar and different.. a fun and interactive guide like you’ve done here with GLSL would be amazing.