Frickin' shaders with frickin' laser beams
acko.netWhile I hate tons of javascript as much as the next HN'er, do yourself a favor and scroll _up_, enjoy the view and press play. So awesome!
This gets a pass because:
- It looks awesome
- It doesn't hijack scrolling, it reacts to it, but scrolling down scrolls down, without pausing or going left and right or any kind of weirdness
- It is a large page, but not that large. In fact the two screenshots are the biggest thing on the page, the entire animation (more like a demo) on top is only 168 kB (+ the streaming music if you press play).
- If you don't care about all the fluff, you just have a blog post, you actually need to do something (scroll up) of you want to see it.
- The page is usable with and without an ad blocker. No annoyances like popups.
And the page works fine without JavaScript (with an image fallback for the pipes).
Also, after scrolling up, there is a 'settings' button (gear icon). Along with various options (including alternative shaders!), at the top there are 8 empty circles that are worth investigating...
I'm trying to avoid spoilers, so I'm obfuscating more specific hints:
# A good first step (very mild spoiler) echo Q2hlY2sgdGhlIGNvbnNvbGUhCg== | base64 -d # A direct hint about where to look echo RmluZCB0aGUgaGlkZGVuIGFjaGlldmVtZW50cygpCg== | base64 -d # A very spoilery JS statement that has side effects echo YWNoaWV2ZW1lbnQoJ2NodHInKQo= | base64 -dVery nice! Even the play button has a groovy effect if you hover over it!
I used to spend an inordinate amount of time watching the 3D Pipes screensaver, wishing there was a mode that would travel along the pipes after they are drawn. This is like that but mostly its own cool thing.
Very cool tune too!
As well as screensavers, the visualizer in winamp was a great time sink for me with effects like [1] which bears a striking resemblance to the acko intro.
Not much surprise then that they were made by the same person [2]
1. https://www.youtube.com/watch?v=Bhm7uFv4ZOQ 2. https://acko.net/blog/avs
The screenshots are from one of my favorite games called The Talos Principle. Curious, is the author of the site associated with it? That game is custom built, looks incredible even on cheaper hardware (e.g. it looked beautiful on my 2015 MBP when I first played it). Crazy stuff.
Croteam did wonders with that engine, truly a beautiful looking game inside and out.
Shaders are one of those topics that you can easily get lost in. It was one of my more recent "you don't know what you don't know" topics. The idea that your code will run one time for each pixel on your screen, 60-144x a second (!), is mind-boggling. It's still hard for me to wrap my head around it sometimes and when I finally write something that compiles it feels like magic every time.
It gets even weirder when you realize it's not just running your code for each pixel it's running the exact same instructions in parallel for large square blocks of pixels, which makes branching incredibly expensive.
Only as expensive as the slowest pixel in the batch :D
That's not exactly true, it can be slower than the slowest individual pixel. It's not just running the same code for each pixel in parallel across many cores, a single core* actually runs pixels at once and therefore has to have the same program counter on all of those pixels. If two pixels diverge then the core has to alternate between the different PCs and toggle each lane on and off depending on which pixel is currently executing.
That means if you had a shader like:
It would actually take twice as long to run compared to every pixel calling the same function. Each core is executing a batch of pixels (a warp) that is evenly split between two completely different sections of code, so it has to alternate between each until they both finish.if (pixelIndex % 2) { longFunctionA(); } else { longFunctionB(); }* Core might not be the exact right term, Nvidia calls them SMs and other GPU vendors have different names.
With deferred rendering it's possibly running multiple sharers per pixel on the screen. A good example is the excellent Doom Graphics study shows how Doom 2016 is doing this. https://www.adriancourreges.com/blog/2016/09/09/doom-2016-gr...
The Talos Principle is really one of the best puzzle games I've played. It scratched the same itch for me that Portal did.
> The key thing is that I don't intend to make thousands of draw calls this way either. I just want to make a couple dozen of exactly the draw calls I need, preferably today, not next week. It's a radically different use case from what game engines need, which is what the current industry APIs are really mostly tailored for.
Whenever I try to learn WebGL (or similar technology) I give up after a while. In my head I imagine it as if the entire automotive industry was only aimed at F1 race cars, and people who want to do practical day-to-day things with cars only had F1 tech to work with, including the cost and complexity.
If you just want to put some 3D models on the screen, you could use something like ThreeJS. They have tons of examples and each one has a link to its source code.
If you prefer to do it more "from scratch", it's not terribly difficult to get some textured triangles on the screen using WebGL. There are an incredible amount of resources on OpenGL and WebGL out there. Many focus on getting started by drawing a single, flat-shaded triangle. From there, you can add on more code as needed to get different results - a moving camera, some basic lighting, texturing, etc.
Why not learn Unity then?
Because I'm not interested in making games. Recommending Unity is like saying "well if F1 is too high-tech for you try NASCAR" - it sort of helps but it's honestly missing the point.
Can't believe this doesn't have more upvotes, seems like it could be a pretty groundbreaking project to advance the state of the art of GPU programming.
Having done a decent amount of games development, and a little bit of shader coding, the pain points fixed by the approach in the article are significant. Really impressive stuff.
I didn't even realize it was going to be TypeScript until much later in the article too, that was the cherry on top :)
Enjoyed looking at the code, might want to try this system out when WebGPU starts to be more relevant. The importing of .glsl symbols somehow into typescript would be perfect for playing around with effects.
Many times it would be better to have a simple way to express ideas, not having to deal with the most performant systems, which might take a lot more figuring out or issues with debugging your shaders.
The idea of writing shaders in something akin to Typescript sounds a bit like a dream.
What about in (Common) Lisp? https://github.com/cbaggers/cepl
In case you are reading this on mobile and have no clue where to find the amazing animations in action: watch the site in desktop mode and scroll up.
"In my case, I want to construct and call any shader I want at run-time. Arbitrary composition is the entire point. This implies that when I want to go make a GPU call, I need to generate and link a new program, based on the specific types and access patterns of values being passed in."
For toy apps, sure. For professional apps or games, abso-frickin-lutely not. Shader compilation jank is still an annoying issue in even recent games, and even having the ability_ to define arbitrary shaders at any point is such a huge footgun that I'd never let it past code review.
I agree with you that dynamically instantiating shader permutations is bad news. That said, I think the author is probably onto something regarding linking and closures. The existing "binding model" for shaders is incredibly tedious and low-level (not to mention frustratingly not-quite-portable), and I think it's likely that there's a better way to do it.
Seems like you'd just compute combinations at compile time. The point of the article is not that things should be done at runtime, the point of the article is that the entire system can be made easier to use by putting more smarts in front. Those smarts can happen at runtime or compile time.
So what does one do in professional apps? Make sure all the shaders are compiled ahead of time? How does that help?