Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming SDF animations of Rick and Morty

danielchasehooper.com

Post reply on HN
Print view View original

31–40 of 42 posts

Re: Programming SDF animations of Rick and Morty

#31

Post by gamedever »

jms55 wrote: post #4
anotherhue wrote: post #2

This was a very well structured into to GLSL. Can anyone comment on what it would be like in Vulkan or WebGPU/WebGL?

Pretty much the same. Both Vulkan and WebGL can use GLSL directly (well, GLSL -> SPIR-V for Vulkan). WebGPU technically can't if you run it in a browser, but native WebGPU implementations can take GLSL, you can transpile, and finally you could just write WGSL as it's basically the same as GLSL, just with more Rust-inspired syntax rather than C-inspired.

Technically WebGPU and Metal support GLSL exactly as Vulkan supports it. You transpile. there is no difference except maybe you're used to that step with Vulkan and not with the others

Re: Programming SDF animations of Rick and Morty

#33

Post by jms55 »

gamedever wrote: post #31
jms55 wrote: post #4

Earlier quoted context omitted.

Pretty much the same. Both Vulkan and WebGL can use GLSL directly (well, GLSL -> SPIR-V for Vulkan). WebGPU technically can't if you run it in a browser, but native WebGPU implementations can take GLSL, you can transpile, and finally you could just write WGSL as it's basically the same as GLSL, just with more Rust-inspired syntax rather than C-inspired.

Technically WebGPU and Metal support GLSL exactly as Vulkan supports it. You transpile. there is no difference except maybe you're used to that step with Vulkan and not with the others

Ehh from the user's perspective sure, but under the hood it's different.

Vulkan you're doing GLSL -> SPIR-V

WebGPU you're doing GLSL -> WGSL -> (HLSL->DXIL) / (MSL->IR) / SPIR-V / GLSL (for the compact backend)

Then the driver takes GLSL/DXIL/Metal IR/SPIR-V/etc and produces it's own bytecode. Different copies of LLVM are involved a few different times in different places. It's a complex and frankly fairly crappy pipeline.

Re: Programming SDF animations of Rick and Morty

#35

Post by nonethewiser »

joenot443 wrote: post #5

This is awesome. Shader devs are next level; it’s a type of tight, repetitive iteration which is super different from the webby, protocoly, applicationy development that many of us are used to. There’s something really satisfying about changing a float, pressing shift-enter, and then immediately seeing a result. Well done!

> Shader devs are next level; it’s a type of tight, repetitive iteration which is super different from the webby, protocoly, applicationy development that many of us are used to. There’s something really satisfying about changing a float, pressing shift-enter, and then immediately seeing a result.

Is working with the javascript canvas or abstractions on it like p5.js similar to what you're describing? Im not sure if you're talking about graphics programming (some familiarity with) or more specifically working with GPU shaders (no familiarity).

Re: Programming SDF animations of Rick and Morty

#37

Post by Townley »

Another application of GLSL/SDL: you can make custom shader materials for yourself in ThreeJS using the ShaderMaterial. You write the GLSL code in a string within the material and it’ll be applied to the mesh the material is attached to

Gives you the ability to make some cool looking effects like fresnel without post-processing filters

Re: Programming SDF animations of Rick and Morty

#38

Post by vekatimest »

nonethewiser wrote: post #35
joenot443 wrote: post #5

This is awesome. Shader devs are next level; it’s a type of tight, repetitive iteration which is super different from the webby, protocoly, applicationy development that many of us are used to. There’s something really satisfying about changing a float, pressing shift-enter, and then immediately seeing a result. Well done!

> Shader devs are next level; it’s a type of tight, repetitive iteration which is super different from the webby, protocoly, applicationy development that many of us are used to. There’s something really satisfying about changing a float, pressing shift-enter, and then immediately seeing a result. Is working with the javascript canvas or abstractions on it like p5.js similar to what you're describing? Im not sure if…

Looping over a canvas's framebuffer is a similar experience, just obviously a lot less performant. You also get easy access to the rest of your code's state/memory compared to a GPU shader, which can't have its own persistent state and needs variables explicitly allocated and passed into it.
Post reply on HN