I’m not a fan of the minified glsl that guys like this produce but I do get a chuckle when variable declarations spell out damnit. The frustrations are real.
That aside, i love the work, I just hate having to mentally grok the d and c style variables. As if number of chars minimum is the goal. Number of instructions yes, but we can do better than d and t.
If there was some absolute measure of program 'interestingness'/'readability', programs found on shadertoy would no doubt have an asymptotically high score.
My theory is that graphics programmers, at some point, stop having to care very much about what the textual representation of their program actually looks like. Because graphics programming is so hard, once you get to the point of understanding what you're doing, and typing in the shader, it becomes self-explanatory; you don't actually need variable names, what you need is understanding.
Inigo Quilez (author of shadertoy, and graphics programming legend) is one of the most talented graphics programmers alive, and produces some of the least readable code I've ever seen.
Just my 2c on why this is so common in graphics, specifically
As a graphics programmer this doesn't ring true to me.
Using more readable names definitely helps during development. I think the cause of this is twofold.
First, there's a lot of equations used in graphics programming where the canonical names of variables are single letters. If you know the formula a single letter is a good name and it is expected that others reading it also understand it - if you didn't you'd have to read up on the formula anyway.
But beyond that I also think it's a bit of misguided pride. Thinking it's cool to have as minimal inscrutable shader code as possible because that's trendy. It's very common for shaders to be developed with reasonable names and good layout then rewritten before publishing like it was an IOCCC entry.
> First, there's a lot of equations used in graphics programming where the canonical names of variables are single letters. If you know the formula a single letter is a good name and it is expected that others reading it also understand it - if you didn't you'd have to read up on the formula anyway.
That's what I was getting at in my comment. A lot of the shader code I encounter is pretty math-y.
The rest I'm not too sure about .. I don't come across a lot of shaders that are code-golf-y trying to optimize for least number of bytes, but, then again, the article did just that .. so .. :shrug:
I am a graphics programmer. It still enrages me to see those variables but (but) I understand that most of the time, it’s that way in the math. So the math variable becomes the shader variable name. Ugh.
I love me a good float lut = lut_equation(uv, lutTex) * lut_factor.r
For my tastes this is excessive (especially since the formatting is non-existent), but you do pay a cost for longer variable names. There's only so much you can grok when reading a passage, and long names hinder any higher-level understanding of what that passage actually does, requiring you to resort to carefully thinking about the problem rather than any shortcuts and insights your powerful visual cortex might provide.
These demos remind me of TweetCarts, little PICO-8 (Lua) programs designed to fit inside tweets [1]. A bunch were archived on Mastadon [2], and it appears they live on as "Postcarts" on the forum [3].
Since you had to record and upload the GIFs yourself (which to be fair was easy with PICO-8), I spent a month or so writing a Twitter bot to automatically respond to the Lua programs with a GIF of them running [4]. I was extremely proud of my shoddy little bot (that used Python, bash scripts, and a LXD container inside another LXD container, IIRC). Crazy coincidence: I released it just hours before someone else was to release their Twitter bot that did the same thing [5], despite this niche being unfilled for years and neither of us knowing of each other. His was better architected, and we kept in touch for a while.
Thanks for putting this together. Shaders are something I wish I had the time to dive deep into, but since I'm making a game, my time is very limited for the time being. i.e. I only learn what I need to.
Only critique is.. if you're sharing to teach, your compact/one line [460] char GLSL code is a poor delivery mechanism.
> Only critique is.. if you're sharing to teach, your compact/one line [460] char GLSL code is a poor delivery mechanism.
Understandable. Though, the demos are here to illustrate "what you can do with the trick I'm sharing". It's like, I'm teaching you how to do watercolor, and illustrate it with some paintings you won't be able to perform just with that knowledge. They're meant to inspire you to create. You're not looking at a tutorial, you're looking at art.
For once instead of being shoved a ready-made solution there's a short explanation of the core idea with a live example, but instead of a fully documented shadertoy it's like the answer is ROT13'd which makes me itch for implementing a solution myself.
Nice looking demos, I hope to some day manage to get results close to what you have.
I started playing around with GLSL recently and the closest I have come to describing working with it is that it is like creating poetry using math. Getting started was much easier than I expected, getting good results is so far as hard as expected
Thank you for the kind words, and you're on point with "poetry using math".
I started 2-3 months ago or so doing this stuff, so don't be too intimidated to start. Especially with the two articles (Red Alp and this one), it should make it more accessible, hopefully :)
Awesome stuff. Moonlight and Archipelago are particularly beautiful. I work in shaders fairly regularly (mainly Metal-based), and it still amazes me how so little code can produce seemingly infinite universes.
I just finished reading this article and I'm really impressed. The author has learned a lot in a very short while. And is able to explain parts of it quite well.
This is the kind of stuff I always feel I should be able to do, yet it never happened. Seeing others just do it and share their learnings is such a joy.
Making things harder on yourself by imposing artificial limitations like the 512 character limit mentioned by the author seems to be an effective skill growth hack.
its interesting that the inverse distance formula works for the glow effect, but the photon explnation is incorrect, you dont "see" photons that are intersecting the ray path, you only see the photons reaching your eye , the intensity for a pixel should count photons arrivng the camera from the direction of the ray path
I'm oddly fascinated with GLSL shaders recently because I've been trying out a terminal which supports shaders. I have currently applied a retro terminal shader and love using terminal this way.
What's a good way to get started learning to build/customize shaders with GLSL? I have an engineering math background but I was never the best at math. And GLSL syntax looks a bit tedious to be honest, but I'd love to dive in.
> And GLSL syntax looks a bit tedious to be honest, but I'd love to dive in.
With the vectorization everywhere, it's surprisingly convenient given how simple the syntax is. I personally just miss some sinpi/cospi/etc, and/or a PI and TAU constant.
That's also a good test for chatbots: give it a picture and ask it to write a shadertoy demo that make this picture a 3d animation. So far the results are meh.
I’m not a fan of the minified glsl that guys like this produce but I do get a chuckle when variable declarations spell out damnit. The frustrations are real.
That aside, i love the work, I just hate having to mentally grok the d and c style variables. As if number of chars minimum is the goal. Number of instructions yes, but we can do better than d and t.
Moonlight is beautiful.
If there was some absolute measure of program 'interestingness'/'readability', programs found on shadertoy would no doubt have an asymptotically high score.
My theory is that graphics programmers, at some point, stop having to care very much about what the textual representation of their program actually looks like. Because graphics programming is so hard, once you get to the point of understanding what you're doing, and typing in the shader, it becomes self-explanatory; you don't actually need variable names, what you need is understanding.
Inigo Quilez (author of shadertoy, and graphics programming legend) is one of the most talented graphics programmers alive, and produces some of the least readable code I've ever seen.
Just my 2c on why this is so common in graphics, specifically
As a graphics programmer this doesn't ring true to me.
Using more readable names definitely helps during development. I think the cause of this is twofold.
First, there's a lot of equations used in graphics programming where the canonical names of variables are single letters. If you know the formula a single letter is a good name and it is expected that others reading it also understand it - if you didn't you'd have to read up on the formula anyway.
But beyond that I also think it's a bit of misguided pride. Thinking it's cool to have as minimal inscrutable shader code as possible because that's trendy. It's very common for shaders to be developed with reasonable names and good layout then rewritten before publishing like it was an IOCCC entry.
> First, there's a lot of equations used in graphics programming where the canonical names of variables are single letters. If you know the formula a single letter is a good name and it is expected that others reading it also understand it - if you didn't you'd have to read up on the formula anyway.
That's what I was getting at in my comment. A lot of the shader code I encounter is pretty math-y.
The rest I'm not too sure about .. I don't come across a lot of shaders that are code-golf-y trying to optimize for least number of bytes, but, then again, the article did just that .. so .. :shrug:
It probably helps someone be more prolific when they can't understand what they did last week.
I am a graphics programmer. It still enrages me to see those variables but (but) I understand that most of the time, it’s that way in the math. So the math variable becomes the shader variable name. Ugh. I love me a good float lut = lut_equation(uv, lutTex) * lut_factor.r
Fair enough :)
> number of chars minimum not the goal
For my tastes this is excessive (especially since the formatting is non-existent), but you do pay a cost for longer variable names. There's only so much you can grok when reading a passage, and long names hinder any higher-level understanding of what that passage actually does, requiring you to resort to carefully thinking about the problem rather than any shortcuts and insights your powerful visual cortex might provide.
These demos remind me of TweetCarts, little PICO-8 (Lua) programs designed to fit inside tweets [1]. A bunch were archived on Mastadon [2], and it appears they live on as "Postcarts" on the forum [3].
Since you had to record and upload the GIFs yourself (which to be fair was easy with PICO-8), I spent a month or so writing a Twitter bot to automatically respond to the Lua programs with a GIF of them running [4]. I was extremely proud of my shoddy little bot (that used Python, bash scripts, and a LXD container inside another LXD container, IIRC). Crazy coincidence: I released it just hours before someone else was to release their Twitter bot that did the same thing [5], despite this niche being unfilled for years and neither of us knowing of each other. His was better architected, and we kept in touch for a while.
1. https://twitter.com/search?q=%23tweetcart
2. https://mastodon.gamedev.place/@Pico8TweetCarts
3. https://www.lexaloffle.com/bbs/superblog.php?mode=gifs&cat=0...
4. https://x.com/auto_tweetcart
5. https://x.com/tweetcartrunner
Thanks for putting this together. Shaders are something I wish I had the time to dive deep into, but since I'm making a game, my time is very limited for the time being. i.e. I only learn what I need to.
Only critique is.. if you're sharing to teach, your compact/one line [460] char GLSL code is a poor delivery mechanism.
> Thanks for putting this together.
I'm glad it reaches an audience :)
> Only critique is.. if you're sharing to teach, your compact/one line [460] char GLSL code is a poor delivery mechanism.
Understandable. Though, the demos are here to illustrate "what you can do with the trick I'm sharing". It's like, I'm teaching you how to do watercolor, and illustrate it with some paintings you won't be able to perform just with that knowledge. They're meant to inspire you to create. You're not looking at a tutorial, you're looking at art.
That brought out a nice, hearty chuckle. At least you're owning your style.
I don't know, I kind of liked it.
For once instead of being shoved a ready-made solution there's a short explanation of the core idea with a live example, but instead of a fully documented shadertoy it's like the answer is ROT13'd which makes me itch for implementing a solution myself.
Nice looking demos, I hope to some day manage to get results close to what you have.
I started playing around with GLSL recently and the closest I have come to describing working with it is that it is like creating poetry using math. Getting started was much easier than I expected, getting good results is so far as hard as expected
Thank you for the kind words, and you're on point with "poetry using math".
I started 2-3 months ago or so doing this stuff, so don't be too intimidated to start. Especially with the two articles (Red Alp and this one), it should make it more accessible, hopefully :)
Awesome stuff. Moonlight and Archipelago are particularly beautiful. I work in shaders fairly regularly (mainly Metal-based), and it still amazes me how so little code can produce seemingly infinite universes.
I just finished reading this article and I'm really impressed. The author has learned a lot in a very short while. And is able to explain parts of it quite well.
This is the kind of stuff I always feel I should be able to do, yet it never happened. Seeing others just do it and share their learnings is such a joy.
The comic at the end made me chuckle more than it probably should have. :D
Making things harder on yourself by imposing artificial limitations like the 512 character limit mentioned by the author seems to be an effective skill growth hack.
its interesting that the inverse distance formula works for the glow effect, but the photon explnation is incorrect, you dont "see" photons that are intersecting the ray path, you only see the photons reaching your eye , the intensity for a pixel should count photons arrivng the camera from the direction of the ray path
I'm oddly fascinated with GLSL shaders recently because I've been trying out a terminal which supports shaders. I have currently applied a retro terminal shader and love using terminal this way.
What's a good way to get started learning to build/customize shaders with GLSL? I have an engineering math background but I was never the best at math. And GLSL syntax looks a bit tedious to be honest, but I'd love to dive in.
> What's a good way to get started learning to build/customize shaders with GLSL?
I gave some directions and resources in a comment here, it might help you: https://www.reddit.com/r/GraphicsProgramming/comments/1pgqis...
> And GLSL syntax looks a bit tedious to be honest, but I'd love to dive in.
With the vectorization everywhere, it's surprisingly convenient given how simple the syntax is. I personally just miss some sinpi/cospi/etc, and/or a PI and TAU constant.
https://www.shadertoy.com/ is a goldmine for learning shaders
The page almost crashed my phone... Archived version: https://archive.ph/9s9ys
This is really cool and inspirational! Looking forward to studying this closer!
That's also a good test for chatbots: give it a picture and ask it to write a shadertoy demo that make this picture a 3d animation. So far the results are meh.