Frickin' shaders with frickin' laser beams • Hacker News Board

Re: Frickin' shaders with frickin' laser beams

#11

Post by junon » Mon, Dec 13, 2021, 1:59 AM UTC

contravariant wrote: post #6

tlackemann wrote: post #5

Earlier quoted context omitted.

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…

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

Re: Frickin' shaders with frickin' laser beams

#12

Post by trissylegs » Mon, Dec 13, 2021, 2:26 AM UTC

tlackemann wrote: post #5

junon wrote: post #2

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…

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...

Re: Frickin' shaders with frickin' laser beams

#13

Post by GuB-42 » Mon, Dec 13, 2021, 2:43 AM UTC

wodenokoto wrote: post #3

While 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.

Re: Frickin' shaders with frickin' laser beams

#14

Post by yardshop » Mon, Dec 13, 2021, 2:57 AM UTC

wodenokoto wrote: post #3

While 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!

Very 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!

Re: Frickin' shaders with frickin' laser beams

#15

Post by muti » Mon, Dec 13, 2021, 3:54 AM UTC

yardshop wrote: post #14

wodenokoto wrote: post #3

While 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!

Very 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

Re: Frickin' shaders with frickin' laser beams

#16

Post by bschwindHN » Mon, Dec 13, 2021, 4:47 AM UTC

vanderZwan wrote: post #7

> 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 i…

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.

https://threejs.org/examples/

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.

Re: Frickin' shaders with frickin' laser beams

#17

Post by ladberg » Mon, Dec 13, 2021, 5:19 AM UTC

junon wrote: post #11

contravariant wrote: post #6

Earlier quoted context omitted.

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:

    if (pixelIndex % 2) {
        longFunctionA();
    } else {
        longFunctionB();
    }

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.

* Core might not be the exact right term, Nvidia calls them SMs and other GPU vendors have different names.

Re: Frickin' shaders with frickin' laser beams

#18

Post by chrismorgan » Mon, Dec 13, 2021, 5:24 AM UTC

GuB-42 wrote: post #13

wodenokoto wrote: post #3

While 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…

And the page works fine without JavaScript (with an image fallback for the pipes).

Re: Frickin' shaders with frickin' laser beams

#19

Post by raphlinus » Mon, Dec 13, 2021, 5:25 AM UTC

aappleby wrote: post #10

"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 e…

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.

Re: Frickin' shaders with frickin' laser beams

#20

Post by pdkl95 » Mon, Dec 13, 2021, 5:29 AM UTC

wodenokoto wrote: post #3

While 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!

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 -d