Painting with math: A gentle study of raymarching | Hacker News Reader

Painting with math: A gentle study of raymarching

blog.maximeheckel.com

119 pointsibobev19 comments

For anyone interested in playing around with SDFs, my friend and I made this open source library to make working with them more efficient, and you can write shaders using javascript https://github.com/shader-park/shader-park-core

Why would you write a shader using javascript and not the dedicated shading language built into every web browser?

GLSL is great! But it is very limited in many aspects. Js enables us to create a more ergonomic APIs for SDFs similar to processing/p5. You can easily mix the glsl and js code, and it also allows you to directly implement transformations on SDF functions, like revolving or extruding a 2D SDF into a 3D one with a transformation function:

https://shaderpark.com/sculpture/-NeEtQ1JEccER6MjPQzq

It's not meant to be a replacement for glsl, just to open up some cool new possibilities!

To be clear you are talking about generating SDF data in javascript, you aren't actually writing shaders in javascript like you said earlier.

It’s not obvious in that previous example, but you can also write shaders in js, in addition to the built in abstractions for SDFs.

https://shaderpark.com/sculpture/-Nc57ho13qXl3G7fQ2wy

There are some limitations but again the point is just to explore new possibilities!

The first question was why anyone would write a shader in javascript, then it turned out it wasn't actually shaders written in javascript. Now you're telling me you can again, but the question is still why.

The first example was a js shader too but because it also included glsl it could have been easy to miss that. So the second example just emphasizes that better. Regarding why, see my first answer or feel free to browse the thousands of other examples on the site!

Why do you keep calling these shaders? Javascript isn't running on the GPU and it isn't doing any rendering. If making SDF data is called a shader, all scene setup is not and geometry creation would be the same.

Maybe another example will be helpful :)

https://shaderpark.com/sculpture/-M_TY8dwxuyliltrFjP2

No SDFs involved in this one.

Again, just passing around a javascript function doesn't mean it's a shader. Javascript isn't running the GPU and javascript isn't doing any rendering.

Shaderpark does a bit more than "pass around" javascript functions, it transpiles them to glsl. Believe it or not, web browsers themselves only transpile webgl shaders to other high level shader languages: hlsl on windows, msl on macos/ios, and glsl or sprir-v on linux. The os then compiles these to bytecode, and the driver finally compiles them to machine code which is sent to the GPU. So a webgl glsl shader isn't "running the gpu" or "doing rendering" any more than a js shader. They're both just high level languages at the top of a compilation chain ultimately targeting the GPU.

This comes back to the original question, why compile javascript to glsl? I don't think you ever answered that. There are severe limitations in shading languages that javascript doesn't have and shading languages are made to deal with. Where is the benefit?

Have another look at the first example I shared. One major limitation of glsl is a lack of functional programming. In that example, we pass functions to other functions, and iterate over arrays of functions, neither of which are possible in glsl. This is used to implement generic transformations of SDFs. If you did the same with just glsl it would be much longer, harder to read, and there would be duplicated code.

You can even use recursion (with limitations of course)!

https://shaderpark.com/sculpture/-N8ntgGcPiXK5igOagRW

At the same time, many more people know javascript than shader languages, so this makes it easier for beginners to get their hands dirty and can be a gateway to gpu programming. So there are benefits for both novices and advanced users! There are pitfalls to this approach too of course and it certainly isn't a replacement for glsl, but the purpose is simply to explore new possibilities :)

Definitely bookmarked the article.

I've been watching a playlist which is making shader programming click for me: https://www.youtube.com/watch?v=u5HAYVHsasc&list=PLGmrMu-Iwb... "The Art of Code" channel, "ShaderToy Tutorials" playlist. I think if you know some geometry/trigonometry, once you wrap your head around writing a function that maps any pixel to a color (and how you add or multiply colors, and think in vectors), it starts to get fun. If you want a recommendation, I'd start with videos 30 and 37 in the playlist for a cool demo, then the 1st 4 videos (note: the video quality improves in later videos), then 10 and 11, then RayMarching starts in 22-24 and 29. (Many other videos in that channel are great for shader programming techniques, too.)

Good to see high quality articles gaining traction.

If the article looks too verbose, be sure to check out, as the author cites, Inigo Quilez's videos

Painting a Landscape with Maths - https://www.youtube.com/watch?v=BFld4EBO2RE

Painting a Character with Maths - https://www.youtube.com/watch?v=8--5LwHRhjk

Bonus:

Painting with Maths in Google Sheets - https://www.youtube.com/watch?v=JnCkF62gkOY

I had to look at that headline three times before it stopped reading "Painting with Meth". Seemed a very non-HN topic!

Fascinating stuff!

How does performance compare with rasterization if you do not do any light bounces?

Nice article. A lot of this looks very familiar from some demoscene videos.

Reply on news.ycombinator.com